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