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 <troj...@gmail.com> 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 _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool