Build error on macOS 13: `ld: Undefined symbols: _yaz_log`

[barracuda156]

  libtool: link: /usr/bin/clang++  -o .libs/mod_proxy_helsinki.so -bundle  .libs/mod_helsinki.o   -L/opt/local/lib -ldl  -Os -stdlib=libc++ -arch x86_64 -Wl,-headerpad_max_install_names -Wl,-syslibroot -Wl,/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk -arch x86_64  
  libtool: link: ar cr .libs/mod_proxy_sample.a  mod_sample.o
  libtool: link: ranlib .libs/mod_proxy_sample.a
  ld: Undefined symbols:
    _yaz_log, referenced from:
        my_authenticate(void*, char const*, void*, char const*, char const*, char const*, char const*) in mod_helsinki.o
        my_authenticate(void*, char const*, void*, char const*, char const*, char const*, char const*) in mod_helsinki.o
        my_authenticate(void*, char const*, void*, char const*, char const*, char const*, char const*) in mod_helsinki.o
        my_authenticate(void*, char const*, void*, char const*, char const*, char const*, char const*) in mod_helsinki.o
        my_authenticate(void*, char const*, void*, char const*, char const*, char const*, char const*) in mod_helsinki.o
        my_authenticate(void*, char const*, void*, char const*, char const*, char const*, char const*) in mod_helsinki.o
        my_authenticate(void*, char const*, void*, char const*, char const*, char const*, char const*) in mod_helsinki.o
        my_authenticate(void*, char const*, void*, char const*, char const*, char const*, char const*) in mod_helsinki.o
        ...
  clang: error: linker command failed with exit code 1 (use -v to see invocation)
  make[1]: *** [mod_proxy_helsinki.la] Error 1

It builds fine with an old gcc-4.2 on 10.6, but fails with modern clang on 13. What is going wrong here?

[ryandesign]

This is the macOS ≥ 11 libtool bug. libtool 2.4.6 and earlier do not recognize macOS versions greater than 10, as a result of which they fail to add the -undefined dynamic_lookup flag that tells the linker that it's ok that yaz's yaz_log symbol is undefined at link time because it will be defined at runtime. The solution is for yazproxy to release a new version where libtool 2.4.7 or later was used to build the configure script. Until then, the workaround is for the user to rebuild the configure script using autoreconf -fvi after having installed libtool 2.4.7 or later, or apply this patch to the configure script.

[barracuda156]

@ryandesign I am not 100% sure, but I think 10.5 and 10.6 can/should use -undefined dynamic_lookup, at least normally, including on powerpc.

Or is there a specific reason here to use -undefined suppress?

[ryandesign]

You're right, when finding an existing patch in MacPorts that I could copy for yazproxy, I inadvertently selected one that had not fixed this problem: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44605#20 I should really go through all copies of this patch in MacPorts to make sure they're using the fixed version (even though it makes no difference for MacPorts, since MacPorts always sets MACOSX_DEPLOYMENT_TARGET). The correct version of the patch is in libtool 2.4.7 so regenerating the configure script with that version (or later) is still the solution for the yazproxy developers.