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

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: pipcet@gmail.com, 46256@debbugs.gnu.org, andrewjmoreton@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/>