libtool
[Top][All Lists]
Advanced

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

Re: MacOSX module linking with static archive libtool problem


From: Bob Friesenhahn
Subject: Re: MacOSX module linking with static archive libtool problem
Date: Sun, 23 Feb 2003 11:45:25 -0600 (CST)

On Sun, 23 Feb 2003, Brad House wrote:

> Convenience library?  That's a term I'm not familiar with, do you
> have a reference I can look at that describes this further, or
> give me a general overview.

This is a Libtool/Automake feature.  See the libtool documentation. A
convenience library is a way to aggregate objects into a static
library for "convenience", but these objects are extracted into the
individual contained objects while the dependent shared library is
being built so the system linker is not aware that a static library
is used.

Bob

> Robert Boehne wrote:
> > Suggestion 1, you could link to shared libraries rather than archives.
> > Suggestion 2, if you're building it yourself, make the static libs
> >  convenience libraries, this will have the same effect as linking to
> >  static libs, but is portable.
> >
> > HTH,
> >
> > Robert
> >
> > Brad House wrote:
> >
> >>Thanks for your reply.
> >>
> >>Do you happen to know a flag or something I can send to libtool
> >>to force it to go ahead and link against the library?  Basically,
> >>we compile on  Linux, FreeBSD, SCO OpenServer/Unixware, Solaris 8&9,
> >>AIX and all of those work fine.
> >>
> >>Any suggestions other than totally ripping libtool out?
> >>
> >>Thanks.
> >>
> >>-Brad
> >>
> >>Bob Friesenhahn wrote:
> >>
> >>>Many/most operating systems require that anything linked into a shared
> >>>library be compiled as PIC.  The only way that libtool can be sure
> >>>that the code in a library is compiled as PIC is if it is also a
> >>>shared library.  Some system linkers will reject linking against
> >>>static libraries when building a shared library.  Modules are usually
> >>>shared libraries themselves so they observe the rules for building
> >>>shared libraries.
> >>>
> >>>This is a libtool "feature" rather than a "bug".
> >>>There are system-dependent ways that libtool could work around this
> >>>problem for many systems, but it would be a lot of work to implement.
> >>>
> >>>Bob
> >>>
> >>>On Sun, 23 Feb 2003, Brad House wrote:
> >>>
> >>>
> >>>
> >>>>Seems to be a bug in libtool 1.4.3 when linking a module if you want
> >>>>to use symbols out of an archive.  For example, inside of a package
> >>>>that uses autoconf/automake/libtool, a command executes:
> >>>>
> >>>>/bin/sh ../libtool --mode=link gcc -g -O2 -o module_ssl.la -rpath \
> >>>>/usr/local/lib -module -avoid-version module_ssl_la-module_ssl.lo \
> >>>>/usr/local/ssl/lib/libcrypto.a /usr/local/ssl/lib/libssl.a
> >>>>
> >>>>
> >>>>This message appears:
> >>>>
> >>>>*** Warning: Trying to link with static lib archive
> >>>>/usr/local/ssl/lib/libcrypto.a.
> >>>>*** I have the capability to make that library automatically link in when
> >>>>*** you link to this library.  But I can only do this if you have a
> >>>>*** shared version of the library, which you do not appear to have
> >>>>*** because the file extensions .a of this argument makes me believe
> >>>>*** that it is just a static archive that I should not used here.
> >>>>
> >>>>And does NOT link against libssl.a or libcrypto.a
> >>>>
> >>>>But when I:
> >>>>gcc -O2 -fno-common -flat_namespace -bundle -undefined suppress \
> >>>>-o module_ssl.so module_ssl.c /usr/local/ssl/lib/libcrypto.a \
> >>>>/usr/local/ssl/lib/libssl.a
> >>>>
> >>>>This module links perfectly, and is fully loadable within my
> >>>>main program.
> >>>>
> >>>>Any assistance here would be greatly appreciated.  I'd really rather
> >>>>not link against .dylib's as especially for SSL, I use 0.9.7a, and
> >>>>don't want to overwrite the dylibs Apple provides in /usr/lib,
> >>>>and the linker NEVER wants to link against the right dyamic version.
> >>>>
> >>>>-Brad
> >>>>
> >>>>
> >>>>
> >>>>_______________________________________________
> >>>>Libtool mailing list
> >>>>address@hidden
> >>>>http://mail.gnu.org/mailman/listinfo/libtool
> >>>>
> >>>
> >>>
> >>>======================================
> >>>Bob Friesenhahn
> >>>address@hidden
> >>>http://www.simplesystems.org/users/bfriesen
> >>
> >>_______________________________________________
> >>Libtool mailing list
> >>address@hidden
> >>http://mail.gnu.org/mailman/listinfo/libtool
>
>
>
>
> _______________________________________________
> Libtool mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/libtool
>

======================================
Bob Friesenhahn
address@hidden
http://www.simplesystems.org/users/bfriesen





reply via email to

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