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

Previous Next

Full log

Message #493 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 13:58:31 +0000

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

>> From: Andrea Corallo <akrl <at> sdf.org>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 46256 <at> debbugs.gnu.org,
>>         andrewjmoreton <at> gmail.com
>> Date: Tue, 09 Mar 2021 08:32:46 +0000
>> 
>> The original code was written in the assumption that dlclose (as
>> FreeLibrary) can't fail unloading a shared when the internal refcount
>> goes to zero.  As this is not the case
>
> 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?

Thanks

  Andrea

Previous Next

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