29.0.50; MacOS ld warning from native compilation

  • Done
  • quality assurance status badge
Details
6 participants
  • Andrea Corallo
  • Eli Zaretskii
  • Gerd Möllmann
  • Gregory Heytings
  • Lars Ingebrigtsen
  • Stefan Kangas
Owner
unassigned
Submitted by
Gerd Möllmann
Severity
minor
G
G
Gerd Möllmann wrote on 16 Sep 2022 07:48
(address . bug-gnu-emacs@gnu.org)
m25yhnna3g.fsf@Mini.fritz.box
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.
L
L
Lars Ingebrigtsen wrote on 16 Sep 2022 12:51
(name . Gerd Möllmann)(address . gerd.moellmann@gmail.com)(address . 57849@debbugs.gnu.org)
871qsbwq0u.fsf@gnus.org
Gerd Möllmann <gerd.moellmann@gmail.com> writes:

Toggle quote (2 lines)
> I cannot find anything at all about the warning on the web.

There's:


But er where's the actual link to the patch? Confusing interface.
G
G
Gerd Möllmann wrote on 16 Sep 2022 14:34
(name . Lars Ingebrigtsen)(address . larsi@gnus.org)(address . 57849@debbugs.gnu.org)
m2sfkrlcq6.fsf@Mini.fritz.box
Lars Ingebrigtsen <larsi@gnus.org> writes:

Toggle quote (10 lines)
> Gerd Möllmann <gerd.moellmann@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
L
L
Lars Ingebrigtsen wrote on 16 Sep 2022 14:39
(name . Gerd Möllmann)(address . gerd.moellmann@gmail.com)(address . 57849@debbugs.gnu.org)
87h7178pcz.fsf@gnus.org
Gerd Möllmann <gerd.moellmann@gmail.com> writes:

Toggle quote (7 lines)
> 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...
G
G
Gregory Heytings wrote on 16 Sep 2022 14:44
(name . Lars Ingebrigtsen)(address . larsi@gnus.org)
84acc36e7ec1e6784956@heytings.org
Toggle quote (9 lines)
>> 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:

See another similar discussion here:

Apparently the solution is to use the -bundle_loader option.
G
G
Gerd Möllmann wrote on 16 Sep 2022 14:44
(name . Lars Ingebrigtsen)(address . larsi@gnus.org)(address . 57849@debbugs.gnu.org)
e5db81a9-afe4-e1a0-dfa7-95881f67db7f@gmail.com
On 22-09-16 14:39 , Lars Ingebrigtsen wrote:
Toggle quote (12 lines)
> Gerd Möllmann <gerd.moellmann@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.
G
G
Gerd Möllmann wrote on 16 Sep 2022 14:50
(name . Gregory Heytings)(address . gregory@heytings.org)
m2o7vflbzc.fsf@Mini.fritz.box
Gregory Heytings <gregory@heytings.org> writes:

Toggle quote (17 lines)
>>> 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...
G
G
Gerd Möllmann wrote on 16 Sep 2022 15:05
(name . Gregory Heytings)(address . gregory@heytings.org)
5ebd8fe9-5c98-b485-3618-1f6e398b6ed2@gmail.com
And trying libgccjit HEAD fails...

/opt/homebrew/opt/ > brew install libgccjit --HEAD
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
G
G
Gerd Möllmann wrote on 16 Sep 2022 15:39
(name . Gregory Heytings)(address . gregory@heytings.org)
9120e297-52f4-0d74-8814-27e03ef14eb8@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

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.
E
E
Eli Zaretskii wrote on 16 Sep 2022 15:52
(name . Gerd Möllmann)(address . gerd.moellmann@gmail.com)
83v8pn2zpy.fsf@gnu.org
Toggle quote (15 lines)
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 57849@debbugs.gnu.org
> Date: Fri, 16 Sep 2022 15:39:02 +0200
> From: Gerd Möllmann <gerd.moellmann@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.
G
G
Gerd Möllmann wrote on 16 Sep 2022 16:01
(name . Eli Zaretskii)(address . eliz@gnu.org)
m2edwbxvso.fsf@Mini.fritz.box
Eli Zaretskii <eliz@gnu.org> writes:

Toggle quote (19 lines)
>> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 57849@debbugs.gnu.org
>> Date: Fri, 16 Sep 2022 15:39:02 +0200
>> From: Gerd Möllmann <gerd.moellmann@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?
A
A
Andrea Corallo wrote on 16 Sep 2022 23:53
(name . Gerd Möllmann)(address . gerd.moellmann@gmail.com)
xjfo7vfasut.fsf@ma.sdf.org
Gerd Möllmann <gerd.moellmann@gmail.com> writes:

Toggle quote (38 lines)
> Gregory Heytings <gregory@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
G
G
Gerd Möllmann wrote on 17 Sep 2022 06:45
(name . Andrea Corallo)(address . akrl@sdf.org)
m2a66yy5ga.fsf@Mini.fritz.box
Andrea Corallo <akrl@sdf.org> writes:

Toggle quote (8 lines)
> Gerd Möllmann <gerd.moellmann@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.
G
G
Gerd Möllmann wrote on 17 Sep 2022 09:16
(name . Andrea Corallo)(address . akrl@sdf.org)
m235cqxygr.fsf@Mini.fritz.box
Gerd Möllmann <gerd.moellmann@gmail.com> writes:

Toggle quote (14 lines)
> Andrea Corallo <akrl@sdf.org> writes:
>
>> Gerd Möllmann <gerd.moellmann@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.
E
E
Eli Zaretskii wrote on 17 Sep 2022 09:31
(name . Gerd Möllmann)(address . gerd.moellmann@gmail.com)
83wna21mok.fsf@gnu.org
Toggle quote (49 lines)
> Cc: Gregory Heytings <gregory@heytings.org>, Lars Ingebrigtsen <larsi@gnus.org>,
> 57849@debbugs.gnu.org
> From: Gerd Möllmann <gerd.moellmann@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.

Toggle quote (4 lines)
> 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.

Toggle quote (3 lines)
> 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.

Toggle quote (4 lines)
> 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.
G
G
Gerd Möllmann wrote on 17 Sep 2022 10:17
(name . Eli Zaretskii)(address . eliz@gnu.org)
m2y1uiwh37.fsf@Mini.fritz.box
Eli Zaretskii <eliz@gnu.org> writes:

Toggle quote (3 lines)
> 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.

Toggle quote (4 lines)
> 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.

Toggle quote (14 lines)
>> 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.

Toggle quote (8 lines)
>
>> 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.
G
G
Gerd Möllmann wrote on 17 Sep 2022 10:57
(name . Eli Zaretskii)(address . eliz@gnu.org)
m2illmxtrw.fsf@Mini.fritz.box
Gerd Möllmann <gerd.moellmann@gmail.com> writes:

Toggle quote (6 lines)
> 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.
G
G
Gerd Möllmann wrote on 19 Sep 2022 07:19
(name . Eli Zaretskii)(address . eliz@gnu.org)
m2pmfs3pq9.fsf@Mini.fritz.box
Gerd Möllmann <gerd.moellmann@gmail.com> writes:

Toggle quote (14 lines)
> Gerd Möllmann <gerd.moellmann@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.
S
S
Stefan Kangas wrote on 13 Oct 2022 15:47
control message for bug #57849
(address . control@debbugs.gnu.org)
CADwFkm=zW8=mY4NOX10-+JTV7x_3k=SrqXgA0opa4L5dUKACiQ@mail.gmail.com
severity 57849 minor
quit
G
G
Gerd Möllmann wrote on 18 May 08:30 +0200
Re: bug#57849: 29.0.50; MacOS ld warning from native compilation
(name . Eli Zaretskii)(address . eliz@gnu.org)
m2ed9zpr7z.fsf@pro2.fritz.box
Gerd Möllmann <gerd.moellmann@gmail.com> writes:

Toggle quote (21 lines)
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Gerd Möllmann <gerd.moellmann@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.
G
G
Gerd Möllmann wrote on 18 May 08:30 +0200
control message for bug #57849
(address . control@debbugs.gnu.org)
m2cypjpr7p.fsf@pro2.fritz.box
close 57849 30.1
quit
?
Your comment

This issue is archived.

To comment on this conversation send an email to 57849@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 57849
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch