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

Previous Next

Full log

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

From: Andrea Corallo <akrl <at> sdf.org>
To: Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 46256 <at> debbugs.gnu.org
Subject: Re: bug#46256: [feature/native-comp] AOT eln files ignored if run
 from build tree
Date: Sat, 06 Mar 2021 18:37:14 +0000

Andy Moreton <andrewjmoreton <at> gmail.com> writes:

> On Sat 06 Mar 2021, Eli Zaretskii wrote:
>
>>> From: Andy Moreton <andrewjmoreton <at> 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

Previous Next

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