macOS build refers to `.so` file

[SMillerDev]

When trying to compile the latest version in Homebrew the following error pops up:

  libtool: compile:  clang -DHAVE_CONFIG_H -I. -Wall -Wextra -DGETDATA_MODULEDIR=\"/opt/homebrew/Cellar/libgetdata/0.11.0/lib/getdata\" -g -O2 -c spf.c -o spf.o >/dev/null 2>&1
  for m in libgetdatabzip2.la  libgetdatagzip.la    ; do \
        install_name_tool -change \
        /opt/homebrew/Cellar/libgetdata/0.11.0/lib/libgetdata.9.dylib \
        /private/tmp/libgetdata-20211223-69849-17909in/getdata-0.11.0/src/.libs/libgetdata.9.dylib \
        .libs/`basename $m .la`-0.11.0.so; \
        done
  libtool: compile:  clang -DHAVE_CONFIG_H -I. -Wall -Wextra -DGETDATA_MODULEDIR=\"/opt/homebrew/Cellar/libgetdata/0.11.0/lib/getdata\" -g -O2 -c string.c -o string.o >/dev/null 2>&1
  error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: can't open file: .libs/libgetdatabzip2-0.11.0.so (No such file or directory)

https://github.com/Homebrew/homebrew-core/runs/4619893127?check_suite_focus=true

can't open file: .libs/libgetdatabzip2-0.11.0.so (No such file or directory)

Since on macOS the convention would put this in .libs/libgetdatabzip2-0.11.0.dylb this is an understandable error, I just can't find where it is getting this filename.

If someone can point me in the general direction I'll happily submit a patch.

[ketiltrout]

This is a, let's say, quirk of libtool.

GetData's external encodings are built into libtool modules. Libtool modules are dynamically loaded libraries, but they aren't loaded in the same way as normal shared libraries (i.e. at program invocation by the dynamic linker-loader), so they aren't really normal dylibs under MacOS.

GetData loads these modules at runtime on demand when needed via the shim-library libltdl, which has its own, platform-independent way of finding the shared objects to load. The suffix of these libtool modules could be anything, so long as libltdl agreed with the choice. The "quirk" I referred to is that the libtool devs seem to have decided to use .so as the module suffix, regardless of platform.

In your bug report, I don't understand why the install_name_tool mangling (which should be at make check time) would be happening before the modules were built (which is part of the default make run), but the .so suffix is a red herring in this case.

(Note: there is a real bug in the build system involving install_name_tool, #5, which I'm working on a fix for.)