Re: FYI: MacOS linking of Lua extensions written in C

[William Ahern <william@...>]

On Wed, Oct 19, 2022 at 05:36:31PM -0700, Gé Weijers wrote:
> Hi,
> 
> When linking a dynamically loadable C extension for use with Lua on MacOS
> you used to have to specify the magic flags
> "-bundle -undefined dynamic_lookup". The dynamic linker would then look in
> the main program binary for undefined symbols.
> This now produces a warning message. Example:
> 
> clang -I/Users/ge/lua-tools/src -dynamic -pedantic -std=gnu99 -O2 -Wall
> -DVERSION=\"test\" -c date.c -o .obj/date.o
> clang -bundle -undefined dynamic_lookup .obj/date.o -o _date.so
> ld: warning: -undefined dynamic_lookup may not work with chained fixups

For anyone as confused as I was, this warning is only printed when targeting
macOS 12.0 and above (e.g. -mmacosx-version-min=12.0

> Documentation is sparse, but you now have to link the dynamic library
> against the binary that contains the lua interpreter in the following way:
> 
> clang -bundle -bundle_loader /Users/ge/lua-tools/src/lua .obj/date.o -o
> _date.so
> 
> 
> The flags are "-bundle -bundle_loader <path-to-program>"

Unfortunately a loader program or library with the symbols might not exist
at all, let alone the particular one that actually would load the bundle.

For example, I have a build that compiles fat binaries, both a static
application binary with Lua embedded (both the interpreter and all the
modules, so no Lua symbols exported), and a standalone module for
testing+development intended to be usable by a vanilla Lua interpreter. But
I don't think it's common for most pre-packaged Lua interpreters to be
compiled as fat binaries (`-arch arm64 -arch x86_64`), so either x86_64 or
arm64 symbols would be missing from the loader. Indeed, that's exactly what
happens:

  $ cc -o lucky.so [...] -arch arm64 -arch x86_64 -mmacosx-version-min=12.0 \
    [...] -bundle -bundle_loader /opt/local/bin/lua
  ld: can't link with a main executable file '/opt/local/bin/lua' for
  architecture arm64

I guess I should try rebuilding my entire application, targeting 12.0, to
see if the chained fixups issue must be immediately resolved or can be
ignored for the time being. But my main development machine is macOS 12.6
on x86_64, and my second is macOS 11.7 on M1, and at least when running
binaries and modules targetting the 10.15 SDK I haven't seen any problems.