Re: How does one find out what file a library has been loaded from?

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: acm@muc.de, emacs-devel@gnu.org
>> Date: Tue, 02 Aug 2022 08:43:53 +0000
>> 
>> > Other than that only note I've is that (in 'maybe_swap_for_eln1') we do
>> > reject the .eln file if it's younger than the corresponding .elc one.  I
>> > think we should mimic this as well here no?
>> 
>> I do realize now this is probably not a real case as: if (in
>> 'maybe_swap_for_eln1') we reject the eln while loading because older
>> than the elc we give up entirely on loading native code, even if might
>> be available in another directory down in `native-comp-eln-load-path'.
>> So your code should be just fine in this respect.
>
> I'm not sure I understand: in what sense do we "give up entirely on
> loading native code"?  I don't see in maybe_swap_for_eln1 or in
> maybe_swap_for_eln anything that would mean something like that.  All
> I see is that we continue using the .elc file if the timestamp test
> fails.

Yes correct, that's what I meant, we give up for this specific .elc file
instead of keep on searching.

> So in that case, my changes would return the .eln file even
> though it was not actually loaded.

Ops that's correct, I miss-read your code sorry.

> We could document this corner use case, and say that we return the
> .eln file even if it's outdated, or we could add the timestamp test
> you suggested, and return the .elc file if the test fails.

I think would be nicer to have the timestamp test.

Still if the filesystem state changes the result could be incorrect, ex
one could even remove the .eln file and even if the definition is coming
from it we'd return the .elc.  Perhaps we should document this?

Thanks

  Andrea