Original issue: https://github.com/midipix-project/slibtool/issues/15 Opened by: @midipix
midipix commented on Feb 16, 2019:
Another thing to consider: the -undefined linker flag which instructs what to do when a shared library refers to symbols not resolved at link time. Example (here using GNU ar from MacPorts port:binutils as a temporary solution): ``` CD zfs-git/lib/libuutil/ rlibtool --verbose --ar=/opt/local/bin/gar --tag=CC --silent --mode=link ccache /opt/local/bin/clang-mp-5.0 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wno-tautological-constant-out-of-range-compare -D_GNU_SOURCE -D__EXTENSIONS__ -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DTEXT_DOMAIN=\"zfs-osx-user\" -O3 -march=native -g -mmacosx-version-min=10.9 -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -arch x86_64 -g -version-info 1:1:0 -L/opt/local/lib -Wl,-headerpad_max_install_names -O3 -march=native -g -mmacosx-version-min=10.9 -Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -arch x86_64 -o libuutil.la -rpath /opt/local/lib uu_alloc.lo uu_avl.lo uu_dprintf.lo uu_ident.lo uu_list.lo uu_misc.lo uu_open.lo uu_pname.lo uu_string.lo uu_strtoint.lo ../../lib/libavl/libavl.la ../../lib/libspl/libspl.la ../../lib/libefi/libefi.la /Volumes/Debian/Users/bertin/work/src/MacOSX/osxzfs/zfs-git/lib/libuutil /opt/local/bin/gar: BFD (GNU Binutils) 2.30 assertion fail archive.c:1859 <SNIP> ld: warning: option -noall_load is obsolete and being ignored ld: warning: option -noall_load is obsolete and being ignored ld: warning: option -noall_load is obsolete and being ignored Undefined symbols for architecture x86_64: "_CFDictionaryGetValueIfPresent", referenced from: _CFDictionaryValueIfPresentMatchesSubstring in libefi.a(rdwr_efi.o) _isDeviceMatchForKeyAndSubstr in libefi.a(rdwr_efi.o) ``` Adding -Wl,-undefined -Wl,dynamic_lookup (just after -Wall) fixes the issue. I'm attaching the libtool script for this project. libtool.txt Originally posted by @RJVB in #13 (comment)
Another thing to consider: the -undefined linker flag which instructs what to do when a shared library refers to symbols not resolved at link time. Example (here using GNU ar from MacPorts port:binutils as a temporary solution):
```
CD zfs-git/lib/libuutil/ rlibtool --verbose --ar=/opt/local/bin/gar --tag=CC --silent --mode=link ccache /opt/local/bin/clang-mp-5.0 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wno-tautological-constant-out-of-range-compare -D_GNU_SOURCE -D__EXTENSIONS__ -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DTEXT_DOMAIN=\"zfs-osx-user\" -O3 -march=native -g -mmacosx-version-min=10.9 -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -arch x86_64 -g -version-info 1:1:0 -L/opt/local/lib -Wl,-headerpad_max_install_names -O3 -march=native -g -mmacosx-version-min=10.9 -Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -arch x86_64 -o libuutil.la -rpath /opt/local/lib uu_alloc.lo uu_avl.lo uu_dprintf.lo uu_ident.lo uu_list.lo uu_misc.lo uu_open.lo uu_pname.lo uu_string.lo uu_strtoint.lo ../../lib/libavl/libavl.la ../../lib/libspl/libspl.la ../../lib/libefi/libefi.la /Volumes/Debian/Users/bertin/work/src/MacOSX/osxzfs/zfs-git/lib/libuutil /opt/local/bin/gar: BFD (GNU Binutils) 2.30 assertion fail archive.c:1859 <SNIP> ld: warning: option -noall_load is obsolete and being ignored ld: warning: option -noall_load is obsolete and being ignored ld: warning: option -noall_load is obsolete and being ignored Undefined symbols for architecture x86_64: "_CFDictionaryGetValueIfPresent", referenced from: _CFDictionaryValueIfPresentMatchesSubstring in libefi.a(rdwr_efi.o) _isDeviceMatchForKeyAndSubstr in libefi.a(rdwr_efi.o) ```
Adding -Wl,-undefined -Wl,dynamic_lookup (just after -Wall) fixes the issue. I'm attaching the libtool script for this project. libtool.txt
-Wl,-undefined -Wl,dynamic_lookup
Originally posted by @RJVB in #13 (comment)
Looking at the attached libtool.txt, it appears to me that rlibtool could detect which flags to use based on the scripts recorded allow_undefined_flag=... In pure (slibtool) mode, some other mechanism will have to be used, but that is probably a lower priority for now, and would also depend on whether modern tools targeting Mach-O (and most importantly clang's lld) behave in a backward-compatible way.
Looking at the attached libtool.txt, it appears to me that rlibtool could detect which flags to use based on the scripts recorded allow_undefined_flag=...
allow_undefined_flag=...
In pure (slibtool) mode, some other mechanism will have to be used, but that is probably a lower priority for now, and would also depend on whether modern tools targeting Mach-O (and most importantly clang's lld) behave in a backward-compatible way.
RJVB commented on Feb 17, 2019:
In pure (slibtool) mode, some other mechanism will have to be used, but that is probably a lower priority for now, and would also depend on whether modern tools targeting Mach-O (and most importantly clang's lld) behave in a backward-compatible way. Let me just repeat that I do use modern toolchains, including the compiler, linker and everything from what Apple call the cctools package.
@RJVB Is there something left to fix here or should this issue be closed?
In theory, one could argue that when targeting Darwin, and unless -no-undefined has been specified, -Wl,-undefined -Wl,dynamic_lookup should be automatically added. @RJVB, is that correct?
-no-undefined
Login to comment on this ticket.