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