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

[Satz Klauer]

It is not a libtool-specific thingy, you have to use these linking options:

-Wl,-whole-archive -lyourlib.a -lyourlib2.a -Wl,-no-whole-archive

This includes your static libraries libyourlib1.a and libyourlib2.a
into the shared library. Please do not forget the
"-Wl,-no-whole-archive" at the end to encapsulyte the libraries you
wan to link this way.

On Mon, Mar 18, 2013 at 12:58 AM, Peter Johansson <address@hidden> wrote:
> 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
>
> _______________________________________________
> https://lists.gnu.org/mailman/listinfo/libtool