bug#57849: 29.0.50; MacOS ld warning from native compilation

[Andrea Corallo <akrl@sdf.org>]

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

> 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