link statically with one library and dynamically with another?

[Jack Bates]

How can I link statically with one library and dynamically with another?

I am building an Apache module which uses libtidy:
http://tidy.sourceforge.net/

Because I frequently want to install this module on Mac OS X, which does
not by default ship with a libtidy shared library, I include the libtidy
source when I distribute my module. When I build my module, I also build
libtidy, and statically link my module with it.

However I do not want to statically link my module with Apache or libapr
(Apache Portable Runtime) and I cannot figure out how to link statically
with libtidy and dynamically with everything else.

When I build my module, I call (Automake calls):

libtool --mode=link ... -module /usr/lib/libapr-1.la
$(top_srcdir)/tidy/src/libtidy.la ...

- which links dynamically with libapr and libtidy.

I tried calling instead:

libtool --mode=link ... -module /usr/lib/libapr-1.la
$(top_srcdir)/tidy/src/.libs/libtidy.a ...

- which did successfully link dynamically with libapr and statically
with libtidy, but libtool warned me that referencing .libs/libtidy.a was
not portable.

How can I link statically with libtidy and dynamically with libapr?

Thanks and best wishes, Jack


signature.asc
Description: This is a digitally signed message part
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: link statically with one library and dynamically with another?

[Bob Friesenhahn]

On Sun, 4 May 2008, Jack Bates wrote:


How can I link statically with one library and dynamically with another?


In an environment you don't personally control, the only way to be 
absolutely sure is to provide the full path to the static library 
(e.g. /usr/local/lib/libfoo.a) rather than using -l syntax.  That is 
what libtool itself does under the covers when it intends to link 
statically.  The problem is that virtually all Unix linkers search for 
shared libraries first and scan the path a second time for static 
libraries.


Libtool itself provides these options:

  -all-static   do not do any dynamic linking at all
  -static   do not do any dynamic linking of uninstalled libtool 
libraries
  -static-libtool-libs
do not do any dynamic linking of libtool libraries

Platform/linker specific options can be passed direct to the linker 
using -Wl,option type syntax.  If you are luckly, libtool will 
preserve the original location of these options in the command line. 
Getting options out of order with what they apply to is a common 
libtool bug.



- which did successfully link dynamically with libapr and statically
with libtidy, but libtool warned me that referencing .libs/libtidy.a was
not portable.


You should heed that warning.  If your libtidy is not built 
appropriately for use as a loadable module (e.g. PIC code on platforms 
which need it), the the linkage may fail.  Or the module loading will 
fail at run time.  The program which loads the module may simply core 
dump.


An option you should consider is to build libtidy as a convenience 
library which can then be safely linked with your module.  This 
approach likely requires that you create your own build environment 
for libtidy.


Bob
===
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/



___
http://lists.gnu.org/mailman/listinfo/libtool