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

Previous Next

Full log

View this message in rfc822 format

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: 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

Previous Next

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