Re: AC_LIB_HAVE_LINKFLAGS: linking with static library on macOS

[Bruno Haible]

Mohammad Akhlaghi wrote:
> In Gnuastro, we recently changed to using `AC_LIB_HAVE_LINKFLAGS' for 
> all our library dependencies at configure time.
> 
> But while testing it on a macOS machine yesterday we came up with the 
> following problem:
> 
> The machine only has a static version of one of the libraries in 
> `/usr/local/lib' (which is also the default `--prefix'). So the output 
> of `AC_LIB_HAVE_LINKFLAGS' for that library was a static file 
> (`/usr/local/lib/libcfitsio.a') and configure finished without a problem.
> ...
> Previously (when we were simply using `AC_SEARCH_LIBS'), it would set 
> `-lcfitsio' and the linker would go searching in other parts of the 
> system and find the a shared library version of libcfitsio. So it 
> wouldn't crash, but was building with a library that we didn't know 
> about (also not good!)!!!

Good. Glad to hear that is works.

> But during Make, we got the following crash from `ranlib' when it was 
> trying to compile Gnuastro's library (which links with libcfitsio):
> 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib:
>  
> archive member: .libs/libgnuastro.a(libcfitsio.a) fat file for cputype 
> (7) cpusubtype (3) is not an object file (bad magic number)
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar:
>  
> internal ranlib command failed

This error does not involve any GNU tools tools or libraries. It only
involves the Apple tools and /usr/local stuff (MacPorts or Homebrew?).
You find the answer on stackoverflow.com:
https://stackoverflow.com/questions/54363030/cannot-install-any-version-of-ruby-on-mojave-internal-ranlib-command-failed/54936974

> After some investigation, I came up with [1] which says: "The root cause 
> of it is what we provide static libraries on OS X only in fat(Universal 
> binary) format and GNU libtool does not know anything about it. Our 
> recommendation here is to use libtool which is provided by Apple in 
> XCode.".

It is true that the GNU build system does not support building fat
binaries. Installing the GNU binutils would not help either. You can
build fat binaries only by building one binary per arch and then
glueing them together using the Apple tool ('lipo' or some such).

The text you cited sounds like Apple libtool is a replacement for
GNU libtool. This would be nonsense. There is no need to invoke
Apple's libtool. Use GNU libtool to create shared libraries.

Bruno