GNU bug report logs - #47558
28.0.50; dlopen 'image not found' gccemacs native-lisp macos

Previous Next

Full log

View this message in rfc822 format

From: Andrea Corallo <akrl <at> sdf.org>
To: Alan Third <alan <at> idiocy.org>
Cc: bryan.m.obrien <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, 47558 <at> debbugs.gnu.org
Subject: bug#47558: 28.0.50; dlopen 'image not found' gccemacs native-lisp macos
Date: Tue, 06 Apr 2021 14:51:46 +0000

Alan Third <alan <at> idiocy.org> writes:

> On Tue, Apr 06, 2021 at 07:56:46AM +0000, Andrea Corallo wrote:
>> Alan Third <alan <at> idiocy.org> writes:
>> > emacs:
>> > dlopen(/Users/alan/src/emacs/native/nextstep/Emacs.app/Contents/MacOS/../native-lisp/28.0.50-24e3df15/window-0d1b8b93-513ac8ca.eln,
>> > 1): image not found
>> 
>> Hi Alan,
>> 
>> Okay the value of ELN_DESTDIR is used during dump to inform Emacs where
>> the eln will be located (src/Makefile.in:570) so redumping is necessary.
>> Have you tried redumping or rebuilding from scratch?
>
> Yes, I've tried 'make bootstrap' to no avail.

could you share the output of like "make bootstrap V=1"? (go parallel if
you like)

> FWIW, as I mentioned earlier in this thread, which you may not have
> seen, NS provides a method for detecting which paths to use if running
> in the self contained bundle, which Emacs already uses for finding the
> lisp path, exec path, etc. Would it be worth extending this to work
> with the eln files?

I think talking about preloaded files we'll want to to stick to the
relative path to the binary as it should work on every system, but this
might information be useful in the future for the filename hashing.

Thanks

  Andrea

Previous Next

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