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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 46256 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com, akrl <at> sdf.org
Subject: bug#46256: [feature/native-comp] AOT eln files ignored if run from build tree
Date: Mon, 08 Mar 2021 16:39:35 +0200

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Mon, 8 Mar 2021 13:52:49 +0000
> Cc: Andrea Corallo <akrl <at> sdf.org>, 46256 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
> 
> > > Wait, I thought this was on Windows?
> >
> > Yes, and...?
> 
> No dlclose() on Windows.

Why does this matter in this case?  (And I do have dlclose in a
standard library that comes with MinGW, btw.  Not that it's relevant.)

> FreeLibrary() is documented to behave differently from dlclose()

It is?  In what way?

> and I don't have a Windows system to test whether it's actually
> different in practice.

Well, how about explaining the details in terms that are simple enough
that I could understand and do the testing?  Until now, you and Andrea
have been talking Chinese as far as I'm concerned.  Please be aware
that I don't know half the details you two do about native-comp
internals, and will never be able to know that: too many other things
on my plate and too little time.  Can you perhaps explain the issue
without alluding to CU_1, CU_2, Fnative_elisp_load etc., and without
assuming that their interactions are common knowledge?

> > Why would any of the above assumptions be violated?
> 
> I have several suspicions, including "because the second compilation
> unit referring to the same handle hasn't been collected". Because that
> is definitely a bug, and one we should fix, and then we can debug this
> issue more if and when it reappears.

More Chinese.

Previous Next

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