Re: lazy symbol binding failed - on MacOSX 10.7 and 10.8

[Peter Johansson]

Hi Bob,

Thanks for your quick reply.

On 03/18/2013 04:41 AM, Bob Friesenhahn wrote:
> It is not portable, safe, or advisable to link a shared library with a 
> static library.  Due to this, libtool does not apply .a files while it 
> is linking a shared library.  Usually it warns and provides advice 
> when it skips applying the library.  It is willing to apply the .a 
> files while it is linking an executable which depends on the shared 
> library.

Sorry, I was unclear. I'm not trying to link a shared library with a 
static library. I'm creating a shared library that calls functions in 
the static library but I create the shared without mentioning the static 
library for the reason you mentioned above. Instead then when linking 
the executable, I link in the the static library and the linking works 
in the sense it doesn't error out, but at runtime the executable error 
out saying the dynamic loader couldn't find the symbols that should have 
been linked in from static library.

> There is special case of archive library known as a "convenience 
> library" which libtool will build with a .a extension, but since 
> libtool assures that objects in convenience libraries are built with 
> options suitable for a shared library (e.g. PIC), and because libtool 
> extracts the .o files prior to linking, libtool is willing to use a .a 
> file in that very special case.
>
> When using libtool, you have the option to build this other library as 
> a shared library, or you can allow your shared library to have many 
> unresolved externals and resolve them by adding this other library to 
> the link when a dependent executable is linked.  It is common for 
> shared libraries to have unresolved externals on many popular systems, 
> but usually these are related to implicitly-added operating system 
> run-time libraries and it is impolite to make users explicitly add 
> more libraries for a successful link (but libtool can help with that).

I'm not maintainer of this static library, so I rely on that users 
install this library. Unfortunately most distros install it as static 
only (for stupid reasons). Therefore, I'm following your second 
suggestion, which is to allow shared library to have unresolved 
externals and then resolve them when creating the executable. But this 
step fails on OSX. For some reason the symbol from static library is not 
included into the executable and executable fails at runtime.

Cheers,
Peter