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

Previous Next

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