libtool/mail/egcs
1998-11-02 19:30:15 +00:00

116 lines
5.1 KiB
Plaintext

From nobody Wed Oct 14 16:45:31 1998
From: Alexandre Oliva <oliva@dcc.unicamp.br>
Subject: libtool 1.2a broken on egcs (IRIX)
To: bug-libtool@gnu.org
Date: 21 Apr 1998 00:57:51 -0300
X-From-Line: gord@gnu.org Tue Apr 21 04:21:22 1998
Return-Path: <gord@gnu.org>
Delivered-To: gord@trick.profitpress.com
Received: (qmail 25010 invoked from network); 21 Apr 1998 04:21:20 -0000
Received: from unknown (HELO bambam.m-tech.ab.ca) (127.0.0.1)
by 127.0.0.1 with SMTP; 21 Apr 1998 04:21:20 -0000
Received: from mescaline.gnu.org (gateway.m-tech.ab.ca [10.0.0.1]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with ESMTP id VAA25050 for <gord@m-tech.ab.ca>; Mon, 20 Apr 1998 21:59:01 -0600
Received: from grande.dcc.unicamp.br by mescaline.gnu.org (8.8.5/8.6.12GNU) with ESMTP id AAA22629 for <bug-libtool@gnu.org>; Tue, 21 Apr 1998 00:04:34 -0400
Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11])
by grande.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id BAA08201
for <bug-libtool@gnu.org>; Tue, 21 Apr 1998 01:04:18 -0300 (EST)
Received: from cuca.lsd.dcc.unicamp.br (cuca.lsd.dcc.unicamp.br [143.106.24.139])
by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with SMTP id BAA08156
for <bug-libtool@gnu.org>; Tue, 21 Apr 1998 01:04:19 -0300 (EST)
Message-ID: <or3ef7aksg.fsf@cuca.lsd.dcc.unicamp.br>
X-Mailer: Gnus v5.6.4/XEmacs 20.4 - "Emerald"
X-Emacs: 20.4 "Emerald" XEmacs Lucid without mule
MIME-Version: 1.0 (generated by SEMI 1.2.4 - "Arimagawa")
Content-Type: multipart/mixed;
boundary="Multipart_Tue_Apr_21_00:57:51_1998-1"
Content-Transfer-Encoding: 7bit
Xref: trick.profitpress.com mail.libtool:1364
Lines: 85
X-Gnus-Article-Number: 1 Mon Nov 2 17:18:43 1998
[1 <text/plain; US-ASCII (7bit)>]
Hi!
I've just installed and tested libtool 1.2a on several platforms. It
worked beautifully and passed all tests on Solaris 2.[56] and RedHat
Linux 4.0 and 5.0/x86 and 5.0/alpha.
It failed to pass some tests on IRIX 5.2 and 6.3 because, although
ltconfig detected that print was available on ksh only, it somehow
tried to run print with sh in some situation. I haven't investigated
the problem any further, but I managed to fix it by defining echo as
`/bin/ksh print -r'. The attached patch caused libtool to pass all
tests on both platforms.
On SunOS 4.1.3 (with egcs 1.0.2 and GNU ld from binutils 2.9), libtool
1.2a failed to pass the following tests:
FAIL: demo-exec.test
FAIL: hardcode.test
Running tests with VERBOSE=yes produced the following additional
messages for these two tests:
=== Running demo-exec.test
Executing uninstalled programs in ../demo
Welcome to GNU Hell!
ld.so: open error 2 for .libs/libhello.so.3.12
./demo-exec.test: cannot execute ../demo/hell
-dlopen is unsupported
FAIL: demo-exec.test
=== Running hardcode.test
= Running make hardcode in ../demo
make[4]: Entering directory `/l/dsk01/temp/install-libtool-1.2a-atibaia-15206/libtool-1.2a/demo'
You may ignore any linking errors from the following command:
gcc -o hc-direct main.o ./.libs/libhello.so.3.12 -lm || echo unsupported > hc-direct
rm -rf hc-libflag _hclibs
mkdir _hclibs
objdir=`sed -n -e 's/^objdir=\"\(.*\)\"$/\1/p' ./libtool`; cd _hclibs && for lib in ../$objdir/libhello*; do \
ln -s $lib `echo "$lib" | sed 's%^.*/%%'` || exit 1; \
done
gcc -o hc-libflag main.o -Wl,--rpath -Wl,/l/dsk01/temp/install-libtool-1.2a-atibaia-15206/libtool-1.2a/demo/.libs -L./_hclibs -lhello -lm
rm -rf _hclibs
You may ignore any linking errors from the following command:
LD_LIBRARY_PATH=./.libs gcc -o hc-libpath main.o -lhello -lm || echo unsupported > hc-libpath
gcc -o hc-minusL main.o -L./`sed -n -e 's/^objdir=\"\(.*\)\"$/\1/p' ./libtool` -lhello -lm
make[4]: Leaving directory `/l/dsk01/temp/install-libtool-1.2a-atibaia-15206/libtool-1.2a/demo'
= Finding ltconfig's guesses at hardcoding values
= Searching for hardcoded library directories in each program
.libs was hardcoded in `hc-direct', which fooled libtool
.libs was hardcoded in `hc-libflag', as libtool expected
.libs was not hardcoded in `hc-libpath', which fooled libtool
.libs was hardcoded in `hc-minusL', which fooled libtool
FAIL: hardcode.test
This must have something to do with SunOS's hard-coding of -L dirs
into binary programs. `ldd ../demo/.libs/hell', for example, prints:
.libs/libhello.so.3.12 (not found)
-lc.1 => /usr/lib/libc.so.1.8
-ldl.1 => /usr/lib/libdl.so.1.0
--
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil
[2 .patch-libtool-1.2a <application/octet-stream>]
--- ltconfig.in~ Sun Apr 19 16:35:49 1998
+++ ltconfig.in Mon Apr 20 17:44:34 1998
@@ -61,11 +61,8 @@
if test "X`(print -r '\t') 2>/dev/null`" = 'X\t'; then
# This shell has a builtin print -r that does the trick.
echo='print -r'
- elif test -f /bin/ksh && test "X$CONFIG_SHELL" != X/bin/ksh; then
- # If we have ksh, try running ltconfig again with it.
- CONFIG_SHELL=/bin/ksh
- export CONFIG_SHELL
- exec "$CONFIG_SHELL" "$0" --no-reexec ${1+"$@"}
+ elif test -x /bin/ksh && test "X`(/bin/ksh print -r '\t') 2>/dev/null`" = 'X\t'; then
+ echo='/bin/ksh print -r'
else
# Try using printf.
echo='printf %s\n'