[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Peter Johansson
Subject: Re: lazy symbol binding failed - on MacOSX 10.7 and 10.8
Date: Mon, 18 Mar 2013 09:58:49 +1000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130108 Thunderbird/10.0.12

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]