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

[Andrea Corallo]

Andy Moreton <andrewjmoreton@gmail.com> writes:

> On Sat 06 Mar 2021, Eli Zaretskii wrote:
>
>>> From: Andy Moreton <andrewjmoreton@gmail.com>
>>> Date: Sat, 06 Mar 2021 12:15:27 +0000
>>> 
>>> > IIUC, we don't actually call dlclose() until we GC (and might not do
>>> > so even then, since GC is conservative).
>>> 
>>> In that case keeping the handles open is the real bug here, and it would
>>> be better to focus on how to ensure that resources are released corectly.
>>> 
>>> Is there a similar issue in the dynamic modules interface ?
>>
>> Which problem is that?  At least on MS-Windows, a DLL remains open for
>> as long as the program that loaded it keeps running.  How is the
>> situation discussed here different?
>
> Keeping the DLL loaded happens with build-time linking, but this
> discussion is about runtime-linking of shared libraries: dlopen, dlsym,
> dlclose (or for Windows: LoadLibary, GetProcAddress, FreeLibrary).
>
> We need to hear from Andrea to be sure of the precise details.
>
>     AndyM

Hi Andy,

Each eln file is 'dlclosed' if/when the compilation unit (CU) is garbage
collected.

The the CU is a Lisp object and every native compiled Lisp function
holds a reference to it, as a consequence the CU is GC'ed only when we
have no more native compiled Lisp function belonging to it live.

  Andrea