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

Previous Next

Full log

Message #167 received at 67260 <at> debbugs.gnu.org (full text, mbox):

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

Am Samstag, dem 27.01.2024 um 17:15 +0000 schrieb Suhail:
> 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).
You could try stepping through loading a natively-compiled, but
symlinked library, either with the emacs debugger or gdb.  I sadly
don't have more hints to give; you probably know more about this bug
than I do.

Alternatively, you could try union-building emacs + your libraries and
resolving those symlinks as you do.  This should give us a clear hint
that it's the symlinks and not something else that goes wrong.

In addition, you might want to verify that comp-el-to-*-filename
matches the files you want to load.  We could try resolving symlinks in
there with realpath as well.

> > > 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?
That last sentence is me thinking loud for a solution that I'll try for
v8.

Cheers

Previous Next

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