GNU bug report logs - #67260
[PATCH emacs-team 0/2] Think ahead when compiling

Previous Next

Full log

View this message in rfc822 format

From: Suhail <suhail <at> bayesians.ca>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Cc: cox.katherine.e+guix <at> gmail.com, 67260 <at> debbugs.gnu.org, Suhail <suhail <at> bayesians.ca>, andrew <at> trop.in
Subject: [bug#67260] [PATCH v6 1/7] gnu: emacs: Wrap EMACSNATIVELOADPATH.
Date: Sat, 27 Jan 2024 17:15:49 +0000

Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:

> Would you care to debug this a bit more and report your findings?

The locations in question are in the store and hence write-protected.
What's a "safe" way to debug this?

>> Packages such as ox-html are available from two locations in the
>> native-comp-eln-load-path.  In one location they are symlinked, but
>> (presumably because org is a builtin package) it is also available
>> from another location in the native-comp-eln-load-path and in the
>> latter location it's not symlinked in.  I believe this difference is
>> why for some packages natively-compiled versions are loaded (e.g.
>> org, ox-html, etc) whereas for others it's not the case.
> Well, as pointed out in the deleted code, dlopen has a "one shared
> library per file name" limitation.  I don't think we're hit by that
> thanks to unique hashes in the store directory, but I might be wrong
> about that.  Maybe we have to do java-style FQDNs instead.

Perhaps.  I'd wondered, more simply, if symlinked .eln files were ever
being loaded.  In the limited testing I did, I didn't find such an
instance.  For what it's worth, only one of the entries in
native-comp-eln-load-path seems to have symlinked entries (namely,
~/.guix-profile/lib/emacs/native-site-lisp).

>> In addition, I believe there's another issue.  Some packages' names
>> are getting  truncated.  For instance, instead of uniquify.eln, I
>> observe niquify.eln.  In this case, the .eln isn't symlinked
>> (presumably because it's a builtin), but due to the name being messed
>> up (perhaps too aggressive a truncation of hashes?) the natively
>> compiled version is not available:
> I am not truncating any hashes, I'm not even computing them in the
> first place.  The functions I'm modifying are publicly callable, namely
> comp-el-to-eln-rel-filename for the relative file names, and
> comp-el-to-eln-filename for the absolute ones.
>
> There could be an off-by-one error hidden in the stripping of the
> BOGUS_DIRS, however.  Let's investigate that.

Were you thinking out loud, or are there specific steps you'd like me to
help with?

> Note, that you can map transform1, saving some typing overhead, and
> since you are transforming all of your packages you could compose that
> with specification->package.

Appreciate the tips, but I should clarify that the manifest file in
question was generated by way of guix shell --export-manifest.  I'd
omitted the header.

-- 
Suhail

This email is not an offer capable of acceptance, does not evidence an
intention to enter into an agreement, has no operative effect until a
definitive agreement is signed in writing by both parties, and that no
party should act in reliance on the email or any representations of the
sender until a definitive agreement is signed in writing by both
parties.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.