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

From: Andrea Corallo <[email-masked]>
Date: Tue, 09 Mar 2021 17:10:48 +0000

Eli Zaretskii <[email-masked]> writes:

>> From: Andrea Corallo <[email-masked]>
>> Cc: [email-masked], [email-masked], [email-masked]
>> 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/>