GNU bug report logs - #46256
[feature/native-comp] AOT eln files ignored if run from build tree

Previous Next

Full log

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

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 46256 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com, pipcet <at> gmail.com
Subject: Re: bug#46256: [feature/native-comp] AOT eln files ignored if run
 from build tree
Date: Tue, 09 Mar 2021 17:10:48 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Andrea Corallo <akrl <at> sdf.org>
>> Cc: pipcet <at> gmail.com, 46256 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
>> Date: Tue, 09 Mar 2021 13:58:31 +0000
>> 
>> > I think it _is_ the case, but the problem might be that the refcount
>> > is not zero, and therefore the shared library is not actually unloaded
>> > and unmapped.  (I say "might be" because I still don't see the
>> > scenario where this could happen, and I'm not sure if it does happen
>> > the solution should be as suggested -- it could be that it's better to
>> > not load the .eln the second time, i.e. make 'load' behave like
>> > 'require').
>> 
>> That was my understanding (as I don't see why dlclose should fail) but
>> reading the man page:
>> 
>> "On success, dlclose() returns 0; on error, it returns a nonzero value."
>> 
>> So my understanding now is that it can fail.  Am I wrong?
>
> I don't know.  Posix says no errors are defined for dlclose, so maybe
> look at the glibc sources to see what happens on GNU/Linux?

To a quick look into GLIBC AFAIU dlclose can return non zero values.

Also looking at [1] it says:

"If handle does not refer to an open symbol table handle or if the
symbol table handle could not be closed, dlclose() shall return a
non-zero value."

So yeah, don't know if this is a real case (never seen it in practice)
but I think is good to be robust against in principal.

Thanks

  Andrea

[1] <https://pubs.opengroup.org/onlinepubs/9699919799/>

Previous Next

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