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: Robert Boehne
Subject: Re: MacOSX module linking with static archive libtool problem
Date: Tue, 25 Feb 2003 22:55:11 -0600

Brad,

A convenience library is usually part of your own package,
it turns into a list of object files when you link to it.
It could be in a subdirectory, much like libltdl is for
many packages that use it.
Here is a section of the manual that mentions them:
http://www.gnu.org/software/libtool/manual.html#SEC14

Even when the archive contains only PIC, there are sometimes
extra flags that have to be passed, like "-full_archive" (IIRC)
to get all of the object files into the target.  That means
if you depend on using some part of an archive you're linking
against that isn't used by the object files you're linking into
the shared lib, those symbols won't appear in your shared library.
Some linkers will link all the archive's objects, some won't,
and you won't find out until your software is in the field.
That's bad.
In the list of platforms you give below, I think that HPUX is
probably the most picky about PIC objects.  I had a hell of a time
once when Autoconf would find a static version of a system library
(and therefore add it in) but it wasn't PIC, and my shared library
builds died when it tried to link it.
If your archive is built by someone else, you won't know if it
is PIC or not, unless you happen to be on a platform where
that's all there is.
If OpenSSL is designed to be static only, then it probably should
be linked only to executables.  There may be some security advantages
to NOT having OpenSSL code in a shared lib, and by making one you
may open up a vulnerabiltiy.
  In the end, we can't support linking archives into shared libs
because it isn't portable.  This has been discussed before on this
list, so perhaps my predecessors were a bit more elegant in presenting
their arguments.  You may want to search the archives for past
discussions on this topic.

Thanks,

Robert Boehne


Brad House wrote:
> 
> Does a convenience library have to be part of your own
> package? I've looked through the libtool manual and
> cannot find anything about convenience libraries, a pointer
> to a reference would be greatly appreciated.
> 
> If it must be part of your own build, it would be nearly
> impossible to convert all of OpenSSL over to use
> autoconf/automake/libtool, just so I could statically
> link it into another shared object (Especially on
> OS X as there's no telling when Apple is going to
> release a fix for the latest openssl vulnerability,
> or go to the openssl 0.9.7a series so that we
> can take advantage of AES or eliptic curve algoths)
> 
> Anyhow, the way we currently do it (linking against
> static libraries to create a module/shared lib), works
> on:
> 
> Linux (ppc, x86) [need to test alpha & sparc, but I have
>                    the hw to do so]
> FreeBSD (x86)
> SCO (OpenServer5 & Unixware7)
> AIX (4.3.3) [have not tested on 5.x yet]
> Solaris (sparc & x86)
> OpenBSD (x86)
> 
> The only remaining major platforms that I have not
> tested on are Tru64 (which is Alpha, and you said
> PIC doesn't matter there), Irix, and
> HP-UX (PA-RISC & ia64)
> 
> What happens if these platforms prove to be immune
> to this as well.  Why would it not be "a good thing
> to do"?  Perhaps I'm naive, but seems like maybe
> this is a deprecated concern?
> 
> Anyhow, the real point is that IT DOES WORK if you
> link by hand, but LibTool doesn't support it.  And
> those other platforms that it does work on (which is
> all in my exp), LibTool also works on, therefore it
> is a divergence from behavior of the other platforms.
> Though it might not be the "good" thing to do, I'm
> more concerned with what works in practice, as
> "in theory" isn't always the best thing to implement.
> 
> -Brad
> 
> Robert Boehne wrote:
> > Brad,
> >
> > You are correct that all PPC code is pic, so is Alpha.
> > Still, that doesn't mean that this behavior is portable,
> > nor does it mean that building a shared lib from a
> > static archive is a "good" thing to do.  Your software will
> > be better off if it does not depend on archive libraries
> > being PIC, and from your end this is easy to work around
> > by using convenience libraries.  If Libtool allowed this
> > then you would have never learned why you shouldn't do it.
> > That is precisely why it operates this way.
> > If I recall correctly, you build a convenience library by
> > not specifying "-static" nor "-rpath" on Libtool's link line.
> > Automake also has support for convenience libraries built in.
> >
> > HTH,
> >
> > Robert
> >
> > Brad House wrote:
> >
> >>Ok, I've put some thought into this over the weekend,
> >>and I think it should be classified as a BUG.  The
> >>argument you put up about library compiled as PIC
> >>is irrelevant on PPC.  Here's a snippet from the
> >>libtool manual:
> >>(http://www.gnu.org/software/libtool/manual.html#FOOT11)
> >>
> >>"All code compiled for the PowerPC and RS/6000 chips (powerpc-*-*,
> >>powerpcle-*-*, and rs6000-*-*) is position-independent, regardless of
> >>the operating system or compiler suite. So, "regular objects" can be
> >>used to build shared libraries on these systems and no special PIC
> >>compiler flags are required."
> >>
> >>And MACOSX is PPC!
> >>We have this same package compiling on
> >>Linux, FreeBSD, OpenBSD, AIX, SCO OpenServer/Unixware
> >>and this behavior diverges from ALL of those, therefore
> >>it should be classified as a bug.
> >>
> >>-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
> >>
> >>--
> >>-----------------------------
> >>Brad House
> >>Sr. Developer
> >>Main Street Softworks, Inc.
> >>
> >>address@hidden
> >>(352) 378-8228
> >>-----------------------------
> >>
> >>_______________________________________________
> >>Libtool mailing list
> >>address@hidden
> >>http://mail.gnu.org/mailman/listinfo/libtool




reply via email to

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