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 [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
====================================== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
-- ----------------------------- Brad House Sr. Developer Main Street Softworks, Inc.
[EMAIL PROTECTED] (352) 378-8228 -----------------------------
_______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
_______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
