ld.lld on MacOS question

Hopefully the right list … otherwise pointers appreciated (I’ve spent days trying to find a solution but could not find sufficient documentation, could not find a proper list of -flavor darwin commands)

I am setting up an environment for cross compiling shared libraries using LLVM. Overall this works perfectly for many unix like environments but MacOS is a pain in the ass despite that I am running on MacOS. (I’ve not tried windows yet.)

I seem to be able to compile with clang a proper mach object file for a hello function. However, when I link this function into a shared library I (surprisingly for a shared lib?) get undefined symbols like _printf, stub runtime: dyld_stub_binder, _main, etc. Using the flag

-undefined dynamic_lookup

I get no errors or warnings but then when I try to link the shared library to a main program I get the error:

ld: malformed dylib has MH_NO_REEXPORTED_DYLIBS flag
but no LC_REEXPORT_DYLIB load commands: ./libhello.dylib file ‘./libhello.dylib’

I’ve included the shell file that makes the hello shared lib and the command that I use to link the file.

Thanks for any help, this looks like an amazing solution if it can get to work on all supported platforms.

Kind regards,

Peter Kriens

$ /usr/local/Cellar/llvm/4.0.0_1/bin/clang
-target x86_64-apple-darwin16.5.0
hello.c x.c

$ file hello.o
hello.o: Mach-O 64-bit object x86_64

$ /usr/local/Cellar/llvm/4.0.0_1/bin/ld.lld \

-flavor darwin
-sdk_version 10.5.0
-arch x86_64
-undefined dynamic_lookup
-o libhello.dylib

$ file libhello.dylib
libhello.dylib: Mach-O 64-bit dynamically linked shared library x86_64

$ gcc x.c -L. -lhello
ld: malformed dylib has MH_NO_REEXPORTED_DYLIBS flag but no LC_REEXPORT_DYLIB load commands: ./libhello.dylib file ‘./libhello.dylib’

Cc’ing people who are working on macOS.

LLD work on Darwin is stalled out at the moment. Patches are welcome (and I’ll try to find time to review them), but I’d recommend ld64 for any real-world linking.

  • Lang.

Thanks for the answer. However, this means I need a different linker for MacOS as for Windows/Linux?

I guess it is a not a major thing but I was hoping to set up a cross compile env. where only the header files and shared libraries differed :frowning: I guess we’re not there yet … :slight_smile:

Kind regards,

Peter Kriens

Zig author here in the same boat. Looks like I’m going to have to disable cross compiling for MacOS and when compiling native for MacOS add a dependency on the system linker. Really looking forward to Mach-O support in LLD, because at that point my users will be able to cross compile for any OS out of the box.

Sounds like a fantastic goal, and enticingly close …

Kind regards,

Peter Kriens

Hi Guys,

As I left it, lld on Darwin could compile Clang / LLVM and the nightly test suite, so we were definitely making progress. There were still plenty of bug fixes to get through though. If anyone’s interested in contributing to MachO support in lld I’m happy to translate some of the radars into llvm.org bugs.


Lang - I think there has perhaps been a regression in that case, because I have an example of a trivial IR module that fails to be linked correctly: https://bugs.llvm.org/show_bug.cgi?id=32376

Kevin provided some clues about this but I was not able to find a fix.


Regarding your original question, I found something which may be a workaround.

Looking at the darwin ld code, it doesn’t throw if you use the -flat_namespace arg. So you could add -Wl,-flat_namespace to your clang args. This makes linking succeed for me.

That said, when I run the binary, I’m getting

dyld: Library not loaded: @rpath/libmathtest.1.dylib
Referenced from: /Users/andy/dev/zig/example/shared_library/zig-cache/test
Reason: image not found

But I suspect this may be a separate issue.