gift-openft is using libtool 1.4.3. Works brilliantly. gift-gnutella,
however, seems to be using libtool 1.5a, and this does not work correctly
on my OpenBSD box.
When I attempt to build gift-gnutella on OpenBSD using these commands:
PKG_CONFIG_PATH=$HOME/lib/pkgconfig ./configure --prefix=$HOME --enable-shared
gmake
it churns along for a while, and then produces this mess:
===
/bin/sh ../libtool --mode=link ccwrap -I/home/gift/include -g -O2 -o
libGnutella.la -rpath /home/gift/lib/giFT -module -avoid-version file_cache.lo
gt_accept.lo gt_ban.lo gt_conf.lo gt_connect.lo gt_gnutella.lo gt_guid.lo
gt_http_client.lo gt_http_server.lo gt_netorg.lo gt_node_cache.lo gt_node.lo
gt_packet.lo gt_protocol.lo gt_query_route.lo gt_search.lo gt_search_exec.lo
gt_share.lo gt_share_file.lo gt_stats.lo gt_urn.lo gt_utils.lo gt_web_cache.lo
gt_xfer.lo gt_xfer_obj.lo html.lo http.lo http_request.lo sha1.lo trie.lo
-L/home/gift/lib -lgift -lgiftproto -lz
../libtool[6378]: OpenBSD.* shared library: not found
../libtool[6378]: OpenBSD.* shared library: not found
../libtool[6378]: OpenBSD.* shared library: not found
../libtool[6378]: OpenBSD.* shared library: not found
*** Warning: linker path does not have real file for library -lgift.
*** 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 I did check the linker path looking for a file starting
*** with libgift and none of the candidates passed a file format test
*** using a file magic. Last file checked: /home/gift/lib/libgift.so.0.0
===
(There's more like it. Then it proceeds to build a .libs/libGnutella.a
file using "ar cru" commands, instead of a shared library.)
I worked around this problem by copying the generated libtool file
from the gift-openft directory straight into the gift-gnutella
directory. Then "gmake clean" and "gmake" and it was all happy.
This sounds like a libtool bug to me (1.5a is an "alpha" version, right?)
I looked at the script, and the key difference from 1.4.3 to 1.5a is here:
if eval $file_magic_cmd \"\$potlib\" 2>/dev/null \
| ${SED} 10q \
| egrep "$file_magic_regex" > /dev/null; then
if eval $file_magic_cmd \"\$potlib\" 2>/dev/null \
| ${SED} 10q \
| $EGREP "$file_magic_regex" > /dev/null; then
(There are multiple instances of this.) As far as I can tell, the
EGREP variable is not being filled in, so it's trying to execute
"OpenBSD.* shared library" as a command. This reminds me of the
problems lots of people have been experiencing with the SED variable
not being populated. I also noted that gift-openft has the following
line in its configure.ac:
AC_PATH_PROG(SED, sed)
but gift-gnutella does not have this line. I'm not sure whether that's
good or bad. I was thinking that perhaps the gift developers could
add a line like this one to the configure.ac:
AC_PATH_PROG(EGREP, egrep)
But I wonder why this is necessary in the first place. (Why does libtool
reference an EGREP variable that's never defined?)
Details:
OpenBSD 3.3 i386 (an a.out platform)
gcc version 2.95.3 20010125 (prerelease, propolice)
(I actually use a wrapper script around gcc, which passes
-I/usr/local/include and -L/usr/local/lib, but I don't think that's
relevant here.)
GNU Make 3.80
gift 0.11.3
"file /home/gift/lib/libgift.so.0.0" says:
OpenBSD/i386 demand paged shared library not stripped
gift-openft 0.1.0.5 (uses libtool 1.4.3, works fine)
gift-gnutella 0.0.4 (uses libtool 1.5a, fails)
libtool says:
VERSION=1.5a
TIMESTAMP=" (1.1239 2003/06/11 16:33:49)"
[...]
deplibs_check_method="file_magic OpenBSD.* shared library"
I can supply additional details as needed.
--
Greg Wooledge | "Truth belongs to everybody."
[EMAIL PROTECTED] |- The Red Hot Chili Peppers
http://wooledge.org/~greg/ |
pgp0.pgp
Description: PGP signature
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
