GNU bug report logs - #57849
29.0.50; MacOS ld warning from native compilation

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 57849 in the body.
You can then email your comments to 57849 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; MacOS ld warning from native compilation
Date: Fri, 16 Sep 2022 07:48:19 +0200

In GNU Emacs 29.0.50 (build 1, aarch64-apple-darwin21.6.0, NS
 appkit-2113.60 Version 12.6 (Build 21G115)) of 2022-09-15 built on
 Mini.fritz.box
Repository revision: 70e4388c59a030f0c1bec9bfcf3e94cc6d80dd1f
Repository branch: master
Windowing system distributor 'Apple', version 10.3.2113
System Description:  macOS 12.6

Configured using:
 'configure --cache-file /Users/gerd/tmp/config.cache.master
 --with-native-compilation'

After upgrading to Xcode 14.0 (14A309) tonight, native compilation
now emits lots of warnings

ld: warning: -undefined dynamic_lookup may not work with chained fixups

~/emacs/master/src/ > ld -v
@(#)PROGRAM:ld  PROJECT:ld64-819.6
BUILD 14:58:44 Aug  5 2022
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
LTO support using: LLVM version 14.0.0, (clang-1400.0.29.102) (static support for 29, runtime is 29)
TAPI support using: Apple TAPI version 14.0.0 (tapi-1400.0.11)

I cannot find anything at all about the warning on the web.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 57849 <at> debbugs.gnu.org
Subject: Re: bug#57849: 29.0.50; MacOS ld warning from native compilation
Date: Fri, 16 Sep 2022 12:51:45 +0200

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> I cannot find anything at all about the warning on the web.

There's:

https://githublab.com/profile/kateinoigakukun

But er where's the actual link to the patch?  Confusing interface.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 57849 <at> debbugs.gnu.org
Subject: Re: bug#57849: 29.0.50; MacOS ld warning from native compilation
Date: Fri, 16 Sep 2022 14:34:25 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> I cannot find anything at all about the warning on the web.
>
> There's:
>
> https://githublab.com/profile/kateinoigakukun
>
> But er where's the actual link to the patch?  Confusing interface.

Maybe it's a libgccjit thing?  It seems to pass that to ld.

/opt/homebrew/opt/ > strings /opt/homebrew/Cellar/libgccjit/12.2.0/lib/gcc/current/libgccjit.0.dylib|grep dynamic_lookup
-Wl,-undefined,dynamic_lookup

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 57849 <at> debbugs.gnu.org
Subject: Re: bug#57849: 29.0.50; MacOS ld warning from native compilation
Date: Fri, 16 Sep 2022 14:39:56 +0200

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> Maybe it's a libgccjit thing?  It seems to pass that to ld.
>
> /opt/homebrew/opt/ > strings
> /opt/homebrew/Cellar/libgccjit/12.2.0/lib/gcc/current/libgccjit.0.dylib|grep
> dynamic_lookup
> -Wl,-undefined,dynamic_lookup

They mention "-bundle_loader", but since I can't find the link to the
actual patch, I'm not sure what, if anything, they're talking about...

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 57849 <at> debbugs.gnu.org
Subject: Re: bug#57849: 29.0.50; MacOS ld warning from native compilation
Date: Fri, 16 Sep 2022 12:44:02 +0000

>> I cannot find anything at all about the warning on the web.
>
> There's:
>
> https://githublab.com/profile/kateinoigakukun
>
> But er where's the actual link to the patch?  Confusing interface.
>

There's no patch AFAICS, but the discussion is here: 
https://githublab.com/repository/issues/chef/ffi-yajl/114

See another similar discussion here: 
https://github.com/ruby/ruby/pull/6193

Apparently the solution is to use the -bundle_loader option.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 57849 <at> debbugs.gnu.org
Subject: Re: bug#57849: 29.0.50; MacOS ld warning from native compilation
Date: Fri, 16 Sep 2022 14:44:12 +0200

On 22-09-16 14:39 , Lars Ingebrigtsen wrote:
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> 
>> Maybe it's a libgccjit thing?  It seems to pass that to ld.
>>
>> /opt/homebrew/opt/ > strings
>> /opt/homebrew/Cellar/libgccjit/12.2.0/lib/gcc/current/libgccjit.0.dylib|grep
>> dynamic_lookup
>> -Wl,-undefined,dynamic_lookup
> 
> They mention "-bundle_loader", but since I can't find the link to the
> actual patch, I'm not sure what, if anything, they're talking about...

Yeah, that's my problem, too :-)

The ld man page says

   Options when creating a bundle
     -bundle_loader executable
             This specifies the executable that will be loading the bundle
             output file being linked.  Undefined symbols from the 
bundle are
             checked against the specified executable like it was one 
of the
             dynamic libraries the bundle was linked with.

That doesn't look like the right thing.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 57849 <at> debbugs.gnu.org
Subject: Re: bug#57849: 29.0.50; MacOS ld warning from native compilation
Date: Fri, 16 Sep 2022 14:50:31 +0200

Gregory Heytings <gregory <at> heytings.org> writes:

>>> I cannot find anything at all about the warning on the web.
>>
>> There's:
>>
>> https://githublab.com/profile/kateinoigakukun
>>
>> But er where's the actual link to the patch?  Confusing interface.
>>
>
> There's no patch AFAICS, but the discussion is here:
> https://githublab.com/repository/issues/chef/ffi-yajl/114
>
> See another similar discussion here:
> https://github.com/ruby/ruby/pull/6193
>
> Apparently the solution is to use the -bundle_loader option.

He writes

   On the other hand, -undefined dynamic_lookup is already deprecated on
   all darwin platforms except for macOS,

Aha, that's interesting.

   so it's good time to get rid of
   the option. ld64 also provides -bundle_loader <executable> option,
   which allows to resolve symbols defined in the executable symtab while
   linking. It behaves almost the same with -undefined dynamic_lookup,
   but it makes the following changes:

   Require that unresolved symbols among input objects must be defined
   in the executable.

I'm not sure this is true for elns.  What if a function in a.eln calls a
function F in b.eln?  In that case, F wouldn't be defined in the
executable.

   Lazy symbol binding will lookup only the symtab of the bundle loader
   executable. (-undefined dynamic_lookup lookups all symtab as flat
   namespace)

Not sure what he's saying...

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 57849 <at> debbugs.gnu.org
Subject: Re: bug#57849: 29.0.50; MacOS ld warning from native compilation
Date: Fri, 16 Sep 2022 15:05:39 +0200

And trying libgccjit HEAD fails...

/opt/homebrew/opt/ > brew install libgccjit --HEAD
==> Cloning https://gcc.gnu.org/git/gcc.git
Cloning into '/Users/gerd/Library/Caches/Homebrew/libgccjit--git'...
Updating files: 100% (117196/117196), done.
==> Checking out branch master
Already on 'master'
Your branch is up to date with 'origin/master'.
==> ../configure --prefix=/opt/homebrew/Cellar/libgccjit/HEAD-39dc665 
--libdir=/opt/homebrew/Cellar/libgccjit/HEAD-3
==> make
Last 15 lines from /Users/gerd/Library/Logs/Homebrew/libgccjit/02.make:
checking for struct tms... yes
checking for clock_t... yes
checking for F_SETLKW... yes
checking for O_CLOEXEC... yes
checking for fcntl.h... (cached) yes
checking whether O_NONBLOCK is declared... yes
checking for AF_UNIX... yes
checking for AF_INET6... yes
checking for _LK_LOCK... no
checking if mkdir takes one argument... no
/private/tmp/libgccjit-20220916-39022-19zntmh/gcc/configure: line 12693: 
test: =: unary operator expected
*** Configuration aarch64-apple-darwin21 not supported
make[2]: *** [configure-stage1-gcc] Error 1
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 57849 <at> debbugs.gnu.org
Subject: Re: bug#57849: 29.0.50; MacOS ld warning from native compilation
Date: Fri, 16 Sep 2022 15:39:02 +0200

And trying to pass "-Wl,-w", with "-w" being an ld options to suppress 
warnings, doesn't work either (not that it would be a good idea...)

(let ((native-comp-compiler-options '("-Wl,-w")))
  (native-compile "/Users/gerd/emacs/crash.el"))

Compiling 
/Users/gerd/.emacs.d/eln-cache/29_0_50-72ec8db5/crash-e892b236-cea0f727.eln...
libgccjit.so: error: command-line option '-Wl,-w' is valid for the 
driver but not for

For what it doesn't say, but I guess it means for libgccjit.so :-). 
"gcc -Wl,w some.c" works just fine.

So, I guess we're hosed.  Unless someone has another idea.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: gregory <at> heytings.org, larsi <at> gnus.org, 57849 <at> debbugs.gnu.org
Subject: Re: bug#57849: 29.0.50; MacOS ld warning from native compilation
Date: Fri, 16 Sep 2022 16:52:41 +0300

> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 57849 <at> debbugs.gnu.org
> Date: Fri, 16 Sep 2022 15:39:02 +0200
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> 
> And trying to pass "-Wl,-w", with "-w" being an ld options to suppress 
> warnings, doesn't work either (not that it would be a good idea...)
> 
> (let ((native-comp-compiler-options '("-Wl,-w")))
>    (native-compile "/Users/gerd/emacs/crash.el"))
> 
> Compiling 
> /Users/gerd/.emacs.d/eln-cache/29_0_50-72ec8db5/crash-e892b236-cea0f727.eln...
> libgccjit.so: error: command-line option '-Wl,-w' is valid for the 
> driver but not for

There's also native-comp-driver-options; did you try that?

native-comp-compiler-options are for the compiler, i.e. cc1.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gregory <at> heytings.org, larsi <at> gnus.org, 57849 <at> debbugs.gnu.org
Subject: Re: bug#57849: 29.0.50; MacOS ld warning from native compilation
Date: Fri, 16 Sep 2022 16:01:43 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 57849 <at> debbugs.gnu.org
>> Date: Fri, 16 Sep 2022 15:39:02 +0200
>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> 
>> And trying to pass "-Wl,-w", with "-w" being an ld options to suppress 
>> warnings, doesn't work either (not that it would be a good idea...)
>> 
>> (let ((native-comp-compiler-options '("-Wl,-w")))
>>    (native-compile "/Users/gerd/emacs/crash.el"))
>> 
>> Compiling 
>> /Users/gerd/.emacs.d/eln-cache/29_0_50-72ec8db5/crash-e892b236-cea0f727.eln...
>> libgccjit.so: error: command-line option '-Wl,-w' is valid for the 
>> driver but not for
>
> There's also native-comp-driver-options; did you try that?
>
> native-comp-compiler-options are for the compiler, i.e. cc1.

Thanks, that works!

(let ((native-comp-driver-options '("-Wl,-w")))
  (native-compile "/Users/gerd/emacs/crash.el"))
"/Users/gerd/.emacs.d/eln-cache/29_0_50-72ec8db5/crash-e892b236-cea0f727.eln"

Now I guess the question is how to proceed with this... Or maybe wait
for libgccjit to do something?

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

From: Andrea Corallo <akrl <at> sdf.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Gregory Heytings <gregory <at> heytings.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 57849 <at> debbugs.gnu.org
Subject: Re: bug#57849: 29.0.50; MacOS ld warning from native compilation
Date: Fri, 16 Sep 2022 21:53:46 +0000

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> Gregory Heytings <gregory <at> heytings.org> writes:
>
>>>> I cannot find anything at all about the warning on the web.
>>>
>>> There's:
>>>
>>> https://githublab.com/profile/kateinoigakukun
>>>
>>> But er where's the actual link to the patch?  Confusing interface.
>>>
>>
>> There's no patch AFAICS, but the discussion is here:
>> https://githublab.com/repository/issues/chef/ffi-yajl/114
>>
>> See another similar discussion here:
>> https://github.com/ruby/ruby/pull/6193
>>
>> Apparently the solution is to use the -bundle_loader option.
>
> He writes
>
>    On the other hand, -undefined dynamic_lookup is already deprecated on
>    all darwin platforms except for macOS,
>
> Aha, that's interesting.
>
>    so it's good time to get rid of
>    the option. ld64 also provides -bundle_loader <executable> option,
>    which allows to resolve symbols defined in the executable symtab while
>    linking. It behaves almost the same with -undefined dynamic_lookup,
>    but it makes the following changes:
>
>    Require that unresolved symbols among input objects must be defined
>    in the executable.
>
> I'm not sure this is true for elns.  What if a function in a.eln calls a
> function F in b.eln?

This is never the case. Functions in .eln files either call functions in
Emacs core or either call functions in the same .eln file.

  Andrea

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: Gregory Heytings <gregory <at> heytings.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 57849 <at> debbugs.gnu.org
Subject: Re: bug#57849: 29.0.50; MacOS ld warning from native compilation
Date: Sat, 17 Sep 2022 06:45:25 +0200

Andrea Corallo <akrl <at> sdf.org> writes:

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

>> I'm not sure this is true for elns.  What if a function in a.eln calls a
>> function F in b.eln?
>
> This is never the case. Functions in .eln files either call functions in
> Emacs core or either call functions in the same .eln file.

Thanks, good to know.

I'll give it a spin with -bundle... later today.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: Gregory Heytings <gregory <at> heytings.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 57849 <at> debbugs.gnu.org
Subject: Re: bug#57849: 29.0.50; MacOS ld warning from native compilation
Date: Sat, 17 Sep 2022 09:16:20 +0200

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> Andrea Corallo <akrl <at> sdf.org> writes:
>
>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>>> I'm not sure this is true for elns.  What if a function in a.eln calls a
>>> function F in b.eln?
>>
>> This is never the case. Functions in .eln files either call functions in
>> Emacs core or either call functions in the same .eln file.
>
> Thanks, good to know.
>
> I'll give it a spin with -bundle... later today.

That failed miserably.  What I tried:

(1) See with which options elns are compiled/linked.

(let ((native-comp-driver-options '("-v")))
  (native-compile "/Users/gerd/emacs/crash.el"))

gives an output ending with

 /opt/homebrew/Cellar/gcc/12.2.0/bin/../libexec/gcc/aarch64-apple-darwin21/12/collect2 -syslibroot /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/ -dynamic -arch arm64 -macosx_version_min 12.0.0 -o /var/folders/1d/k_6t25f94sl83szqbf8gpkrh0000gn/T//libgccjit-YMST3m/fake.so -L/opt/homebrew/Cellar/gcc/12.2.0/bin/../lib/gcc/current/gcc/aarch64-apple-darwin21/12 -L/opt/homebrew/Cellar/gcc/12.2.0/bin/../lib/gcc/current/gcc -L/opt/homebrew/Cellar/gcc/12.2.0/bin/../lib/gcc/current/gcc/aarch64-apple-darwin21/12/../../.. /var/folders/1d/k_6t25f94sl83szqbf8gpkrh0000gn/T//ccbfcNDH.o -undefined dynamic_lookup -dylib -dylib_install_name crash-e892b236-cea0f727.eln -lemutls_w -lgcc -lSystem -lgcc -no_compact_unwind -rpath @loader_path -rpath /opt/homebrew/Cellar/gcc/12.2.0/lib/gcc/current/gcc/aarch64-apple-darwin21/12 -rpath /opt/homebrew/Cellar/gcc/12.2.0/lib/gcc/current/gcc -rpath /opt/homebrew/Cellar/gcc/12.2.0/lib/gcc/current
ld: warning: -undefined dynamic_lookup may not work with chained fixups

That is, it builds a shared object (-dynamic).

(2) -bundle_loader requires -bundle.  Ld gives an error if
-bundle_loader is used without -bundle.  A "bundle" in Mach-O, which is
what MacOS is using instead of ELF, say, is something different than a
shared library.  Example:

gcc -v -o eln.dylib -twolevel_namespace -undefined dynamic_lookup -dylib -bundle_loader hansi eln.c
ld: -bundle_loader can only be used with -bundle

(3) Tried to add -bundle like this

(let ((native-comp-driver-options '("-v" "-bundle")))
  (native-compile "/Users/gerd/emacs/crash.el"))

but it fails

Compiling /Users/gerd/.emacs.d/eln-cache/29_0_50-72ec8db5/crash-e892b236-cea0f727.eln...
Using built-in specs.
aarch64-apple-darwin21-gcc-12: error: -bundle not allowed with -dynamiclib
COLLECT_GCC=aarch64-apple-darwin21-gcc-12

I odn't know how to remove the -dynamic from (1).

As an aside, -bundler_loader actually requires an argument <executable>,
which would be Emacs in our case.  What that means for Emacs' build
process is unclear to me, but it doesn't feel good.

So, I declare this a complete failure.

Anyone with an idea what else to try?  Otherwise my proposal is to
either add something to etc/PROBLEMS describing how to add "-Wl,-w", or
add that option by default on Darwin.

I didn't check if emacs-28 has the same problem, but I don't see why it
wouldn't.

If we add -Wl by default, an open question is if -w is supported on all
all versions of MacOS that Emacs supports, which I can't find a definite
answer to.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: gregory <at> heytings.org, larsi <at> gnus.org, 57849 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#57849: 29.0.50; MacOS ld warning from native compilation
Date: Sat, 17 Sep 2022 10:31:55 +0300

> Cc: Gregory Heytings <gregory <at> heytings.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
>  57849 <at> debbugs.gnu.org
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Date: Sat, 17 Sep 2022 09:16:20 +0200
> 
> That failed miserably.  What I tried:
> 
> (1) See with which options elns are compiled/linked.
> 
> (let ((native-comp-driver-options '("-v")))
>   (native-compile "/Users/gerd/emacs/crash.el"))
> 
> gives an output ending with
> 
>  /opt/homebrew/Cellar/gcc/12.2.0/bin/../libexec/gcc/aarch64-apple-darwin21/12/collect2 -syslibroot /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/ -dynamic -arch arm64 -macosx_version_min 12.0.0 -o /var/folders/1d/k_6t25f94sl83szqbf8gpkrh0000gn/T//libgccjit-YMST3m/fake.so -L/opt/homebrew/Cellar/gcc/12.2.0/bin/../lib/gcc/current/gcc/aarch64-apple-darwin21/12 -L/opt/homebrew/Cellar/gcc/12.2.0/bin/../lib/gcc/current/gcc -L/opt/homebrew/Cellar/gcc/12.2.0/bin/../lib/gcc/current/gcc/aarch64-apple-darwin21/12/../../.. /var/folders/1d/k_6t25f94sl83szqbf8gpkrh0000gn/T//ccbfcNDH.o -undefined dynamic_lookup -dylib -dylib_install_name crash-e892b236-cea0f727.eln -lemutls_w -lgcc -lSystem -lgcc -no_compact_unwind -rpath @loader_path -rpath /opt/homebrew/Cellar/gcc/12.2.0/lib/gcc/current/gcc/aarch64-apple-darwin21/12 -rpath /opt/homebrew/Cellar/gcc/12.2.0/lib/gcc/current/gcc -rpath /opt/homebrew/Cellar/gcc/12.2.0/lib/gcc/current
> ld: warning: -undefined dynamic_lookup may not work with chained fixups
> 
> That is, it builds a shared object (-dynamic).
> 
> (2) -bundle_loader requires -bundle.  Ld gives an error if
> -bundle_loader is used without -bundle.  A "bundle" in Mach-O, which is
> what MacOS is using instead of ELF, say, is something different than a
> shared library.  Example:
> 
> gcc -v -o eln.dylib -twolevel_namespace -undefined dynamic_lookup -dylib -bundle_loader hansi eln.c
> ld: -bundle_loader can only be used with -bundle
> 
> (3) Tried to add -bundle like this
> 
> (let ((native-comp-driver-options '("-v" "-bundle")))
>   (native-compile "/Users/gerd/emacs/crash.el"))
> 
> but it fails
> 
> Compiling /Users/gerd/.emacs.d/eln-cache/29_0_50-72ec8db5/crash-e892b236-cea0f727.eln...
> Using built-in specs.
> aarch64-apple-darwin21-gcc-12: error: -bundle not allowed with -dynamiclib
> COLLECT_GCC=aarch64-apple-darwin21-gcc-12
> 
> I odn't know how to remove the -dynamic from (1).
> 
> As an aside, -bundler_loader actually requires an argument <executable>,
> which would be Emacs in our case.  What that means for Emacs' build
> process is unclear to me, but it doesn't feel good.
> 
> So, I declare this a complete failure.
> 
> Anyone with an idea what else to try?

Is this somehow an Emacs-specific problem, or is this a general
problem with libgccjit on those versions of macOS?  If the latter, I
think this should be taken up with the libgccjit developers first, and
we should then do as they say, if that makes sense.

> Otherwise my proposal is to
> either add something to etc/PROBLEMS describing how to add "-Wl,-w", or
> add that option by default on Darwin.

If what the libgccjit developers say doesn't fit our needs, or if this
is an Emacs-specific problem, thgen yes, using -Wl,-w is probably the
way to go.

> I didn't check if emacs-28 has the same problem, but I don't see why it
> wouldn't.

It's okay to make that change on the emacs-28 branch, if someone can
verify that it works on that branch.

> If we add -Wl by default, an open question is if -w is supported on all
> all versions of MacOS that Emacs supports, which I can't find a definite
> answer to.

I think -w is such an old option that it'd be unthinkable for it not
to be supported.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gregory <at> heytings.org, larsi <at> gnus.org, 57849 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#57849: 29.0.50; MacOS ld warning from native compilation
Date: Sat, 17 Sep 2022 10:17:00 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Is this somehow an Emacs-specific problem, or is this a general
> problem with libgccjit on those versions of macOS?

I think it's a general problem with macOS 12.6/Xcode 14, but I'm not sure.
The link Gregory and/or Lars posted concerned Ruvy, IIRC.

> If the latter, I
> think this should be taken up with the libgccjit developers first, and
> we should then do as they say, if that makes sense.

Maybe Andrea can say more.  I don't know libgccjit and the native
compiler well enough.

>> Otherwise my proposal is to
>> either add something to etc/PROBLEMS describing how to add "-Wl,-w", or
>> add that option by default on Darwin.
>
> If what the libgccjit developers say doesn't fit our needs, or if this
> is an Emacs-specific problem, thgen yes, using -Wl,-w is probably the
> way to go.
>
>> I didn't check if emacs-28 has the same problem, but I don't see why it
>> wouldn't.
>
> It's okay to make that change on the emacs-28 branch, if someone can
> verify that it works on that branch.

I've tried this in emacs-28, which seems to work, with a caveat

@@ -178,14 +178,15 @@ native-comp-compiler-options
   :type '(repeat string)
   :version "28.1")
 
-(defcustom native-comp-driver-options nil
+(defcustom native-comp-driver-options (when (eq system-type 'darwin)
+                                        '("-Wl,-w"))
   "Options passed verbatim to the native compiler's back-end driver.
 Note that not all options are meaningful; typically only the options
 affecting the assembler and linker are likely to be useful.
 
 Passing these options is only available in libgccjit version 9
 and above."
-  :type '(repeat string)                ; FIXME is this right?
+  :type '(repeat string)
   :version "28.1")
 
 (defcustom comp-libgccjit-reproducer nil

The caveat being that I see, after starting that Emacs, in the log
buffer

uncompressing time-date.el.gz...done
ld: library not found for -lemutls_w
libgccjit.so: error: error invoking gcc driver
/Users/gerd/emacs/emacs-28/nextstep/Emacs.app/Contents/Resources/lisp/emacs-lisp/comp.el.gz: Error: Internal native compiler error failed to compile

The build was from git clean -xdf.  Don't know what's going on there.
Maybe it's not related to my change.  I'll try without the change later
today.

>
>> If we add -Wl by default, an open question is if -w is supported on all
>> all versions of MacOS that Emacs supports, which I can't find a definite
>> answer to.
>
> I think -w is such an old option that it'd be unthinkable for it not
> to be supported.

That's likely, yes.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gregory <at> heytings.org, larsi <at> gnus.org, 57849 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#57849: 29.0.50; MacOS ld warning from native compilation
Date: Sat, 17 Sep 2022 10:57:39 +0200

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> uncompressing time-date.el.gz...done
> ld: library not found for -lemutls_w
> libgccjit.so: error: error invoking gcc driver
> /Users/gerd/emacs/emacs-28/nextstep/Emacs.app/Contents/Resources/lisp/emacs-lisp/comp.el.gz: Error: Internal native compiler error failed to compile
>

This is not my day...

I can't reproduce the error above anymore, with or without the change in
compl.el.  It would be good if someone else could double-check.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gregory <at> heytings.org, larsi <at> gnus.org, 57849 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#57849: 29.0.50; MacOS ld warning from native compilation
Date: Mon, 19 Sep 2022 07:19:58 +0200

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> uncompressing time-date.el.gz...done
>> ld: library not found for -lemutls_w
>> libgccjit.so: error: error invoking gcc driver
>> /Users/gerd/emacs/emacs-28/nextstep/Emacs.app/Contents/Resources/lisp/emacs-lisp/comp.el.gz:
>> Error: Internal native compiler error failed to compile
>>
>
> This is not my day...
>
> I can't reproduce the error above anymore, with or without the change in
> compl.el.  It would be good if someone else could double-check.

I've now tested this with a script over night, and the error did not
re-appear in almost 200 runs.

So I've now pushed this to emacs-28.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gregory <at> heytings.org, larsi <at> gnus.org, 57849 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#57849: 29.0.50; MacOS ld warning from native compilation
Date: Sat, 18 May 2024 08:30:08 +0200

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>
>>> uncompressing time-date.el.gz...done
>>> ld: library not found for -lemutls_w
>>> libgccjit.so: error: error invoking gcc driver
>>> /Users/gerd/emacs/emacs-28/nextstep/Emacs.app/Contents/Resources/lisp/emacs-lisp/comp.el.gz:
>>> Error: Internal native compiler error failed to compile
>>>
>>
>> This is not my day...
>>
>> I can't reproduce the error above anymore, with or without the change in
>> compl.el.  It would be good if someone else could double-check.
>
> I've now tested this with a script over night, and the error did not
> re-appear in almost 200 runs.
>
> So I've now pushed this to emacs-28.

No further remarks, so I'm closing this as fixed.

Previous Next

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