Ignore missing symbols when compiling a shared library.

[heibor]

Clang receives the option -undefined,dynamic_lookup to ignore missing symbols when compiling a library.
Is there a a similar option in Zig? Then I can have better scalability to compile a shared library.

[heibor]

Or it can be better to ignore some specific symbols.

[andrewrk]

You mean when linking against a shared library, not producing one, right?

[heibor]

-undefined dynamic_lookup which will mark all undefined symbols as having to be looked up at runtime.

Much more safe way to resolve it for specific symbols:

-Wl,-U,symbol_name, which only does so for the given symbol (note: you have to prepend an underscore to the symbol name)

Please refer to this.

[dsimunic]

I'd second this report. For example, it's impossible to build postgres extensions on macOS without passing either -undefined dynamic_lookup or -bundle -flat_namespace -undefined suppress to the linker.

The build fails and then one has to manually link the .o file into a .dylib.

zig build
warning: unexpected LLD stderr:
Undefined symbol: zig-cache/o/1eef5bd778e281276db3520369bc4da3/pgext.o: _pg_detoast_datum
Undefined symbol: zig-cache/o/1eef5bd778e281276db3520369bc4da3/pgext.o: _errmsg
Undefined symbol: zig-cache/o/1eef5bd778e281276db3520369bc4da3/pgext.o: _errfinish
Undefined symbol: zig-cache/o/1eef5bd778e281276db3520369bc4da3/pgext.o: _errstart
symbol(s) not found

A more complex extension could have dozens of symbols like that. One has to manually complete the linking step:

cc -shared -undefined dynamic_lookup -o zig-cache/lib/pgext.dylib zig-cache/o/1eef5bd778e281276db3520369bc4da3/pgext.o

Sadly, that fails in postgres for debug builds:

could not load library "zig-cache/lib/pgext.dylib": dlopen(zig-cache/lib/pgext.dylib, 10): Symbol not found: ___zig_probe_stack
  Referenced from: zig-cache/lib/pgext.dylib
  Expected in: flat namespace

Wondering if there's any workaround as of 0.7.1? (Note there there's no library to link against--the missing symbols are in the postgres executable itself).

[daurnimator]

Sadly, that fails in postgres for debug builds:

could not load library "zig-cache/lib/pgext.dylib": dlopen(zig-cache/lib/pgext.dylib, 10): Symbol not found: ___zig_probe_stack
  Referenced from: zig-cache/lib/pgext.dylib
  Expected in: flat namespace

Wondering if there's any workaround as of 0.7.1? (Note there there's no library to link against--the missing symbols are in the postgres executable itself).

You need to include the zig compiler rt. Pass -fcompiler-rt to your build-obj invocation.

[dsimunic]

Thanks. The question for workarounds was more general about the whole business of dynamic linking on mac. That last remark is a data point about the complexity of the thing--one would expect that just linking with dynamic_lookup flag would solve the problem, but obviously it doesn't completely.

[haberman]

You need to include the zig compiler rt. Pass -fcompiler-rt to your build-obj invocation.

This doesn't currently work on macho, see my report here. It fails with:

zig build-obj -fcompiler-rt -fPIC -DPYHEXVER=50857456 -I /Users/haberman/opt/anaconda3/include/python3.8 -I /usr/include pdfxt.zig
error: Embedding compiler-rt into macho objects is not yet implemented.

I created a proposal to fix this problem, see: Proposal: fix shared library linking on macOS.