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

Previous Next

Full log

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

From: Alan Third <alan <at> idiocy.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: bryan.m.obrien <at> gmail.com, schwab <at> linux-m68k.org, 47558 <at> debbugs.gnu.org,
 akrl <at> sdf.org
Subject: Re: bug#47558: 28.0.50; dlopen 'image not found' gccemacs
 native-lisp macos
Date: Wed, 7 Apr 2021 13:31:51 +0100

On Wed, Apr 07, 2021 at 02:50:03PM +0300, Eli Zaretskii wrote:
> > Date: Wed, 7 Apr 2021 11:48:23 +0100
> > From: Alan Third <alan <at> idiocy.org>
> > Cc: Andrea Corallo <akrl <at> sdf.org>, Eli Zaretskii <eliz <at> gnu.org>,
> > 	bryan.m.obrien <at> gmail.com, 47558 <at> debbugs.gnu.org
> > 
> > > Why do you need that in the first place?  The compiler should be looking
> > > there by default.
> > 
> > It may be because we have to build with clang, or it may be because of
> > how homebrew installs things. Or both. I'm not sure.
> 
> That alone is worth a bug report against clang, I think.

I think it's more likely to be Homebrew that's at fault, and I think
they view this kind of thing as a feature rather than a bug. I believe
the idea is for homebrew to interfere with the system as little as
possible.

Neither clang, nor (homebrew installed) gcc can find the libraries on
their own.

gcc:

breton:/Users/alan>gcc-10 -v -print-file-name=libgccjit.so
Using built-in specs.
COLLECT_GCC=gcc-10
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/10.2.0_4/libexec/gcc/x86_64-apple-darwin18/10.2.0/lto-wrapper
libgccjit.so

clang:

breton:/Users/alan>clang -v -print-file-name=libgccjit.so
Apple clang version 11.0.0 (clang-1100.0.33.17)
Target: x86_64-apple-darwin18.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
libgccjit.so


> >     breton:/Users/alan>gcc -print-file-name=libgccjit.so
> >     libgccjit.so
> > 
> > which isn't helpful, but again may be because gcc is actually clang.
> 
> The above means the compiler cannot find the file.  Does the file's
> name actually end in .so, or is it some .dynlib or some such?

Definitely .so:

breton:/Users/alan>ls `brew --prefix libgccjit`/lib/gcc/10/
libgccjit.so       libgccjit.so.0     libgccjit.so.0.0.1

> Does clang support the -v switch, whereby it emits details about the
> directories it searches and libraries it scans?  If so, can you run
> the link command with that switch and show the entire output?

Shown above, but there's also

breton:/Users/alan>clang -print-search-dirs
programs: =/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
libraries:
=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/11.0.0

This is relatively common with Homebrew. If you look in configure.ac
there are a few places where we have to modify PKG_CONFIG_PATH because
homebrew doesn't link in all the libraries it installs.

I'm also unsure how portable we need to be with this code since
homebrew is macOS specific and to my knowledge this problem only
arises with homebrew.

-- 
Alan Third

Previous Next

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