|
MacOSX module linking with static archive libtool problem: msg#00127gnu.libtool.general
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 |
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| Previous by Date: | [Q] what to do with unknown flags: 00127, Peter O'Gorman |
|---|---|
| Next by Date: | Re: MacOSX module linking with static archive libtool problem: 00127, Bob Friesenhahn |
| Previous by Thread: | [Q] what to do with unknown flagsi: 00127, Peter O'Gorman |
| Next by Thread: | Re: MacOSX module linking with static archive libtool problem: 00127, Bob Friesenhahn |
| Indexes: | [Date] [Thread] [Top] [All Lists] |
| News | FAQ | advertise |