[1.5.26] new test using 'make install DESTDIR=...'

2008-03-14 Thread Michael Haubenwallner 
Hi,

as I still encounter problems with libtool-1.5.26 and make install
DESTDIR=..., from 'depdemo-inst.test' I've derived a new
'depdemo-instd.test', simply installing depdemo via DESTDIR.
Attached is a patch to add this test for libtool-1.5.26.

When adding this after depdemo-static, depdemo-conf, depdemo-nofast and
depdemo-shared, on platforms where I can test results are:

  build/host-triplet   staticconfnofastshared
---
  i686-pc-linux-gnu PASS PASS FAIL  PASS
  i386-pc-solaris2.10   PASS PASS PASS  PASS
  sparc-sun-solaris2.9  PASS PASS PASS  PASS
  ia64-hp-hpux11.23 PASS PASS PASS  PASS
  powerpc-ibm-aix5.3.0.0PASS SKIP FAIL *FAIL*
  hppa2.0w-hp-hpux11.11 PASS FAIL SKIP  FAIL

Ok, failing on hppa2.0w-hp-hpux11.11 is less surprising currently.
More interesting is failing on linux with nofast...

But I'm focussing on 'conf' and 'shared' now, because they are the ones
being normally used AFAICT, so my current problem is 'shared' on
powerpc-ibm-aix5.3.0.0:

Here the problem is around line ltmain.in#2804, when one shared library
needs another in-package shared library:

2803 # Finalize command for both is simple: just hardcode it.
2804 if test $hardcode_direct = yes; then
2805   add=$libdir/$linklib
2806 elif test $hardcode_minus_L = yes; then
   ...
2809 elif test $hardcode_shlibpath_var = yes; then
   ...
2815 elif test $hardcode_automatic = yes; then
   ...
2822 else
2823   # We cannot seem to hardcode it, guess we'll fake it.
   ...

It is impossible to hardcode_direct using $libdir/$linklib, because
$linklib is not in $libdir yet but in $inst_prefix_dir$libdir.
But hardcoding $inst_prefix_dir$libdir/$linklib is bad either, as
$inst_prefix_dir is not there at runtime lateron.

Remember libtool is configured this way:
  hardcode_direct=yes
  hardcode_minus_L=no
  hardcode_shlibpath_var=unsupported

It simply works when using something like the second attached patch to
fall back to guess we'll fake it (like all my other platforms),
although hardcode_direct IMHO is generally a bad idea when some RUNPATH
can be encoded, even without using DESTDIR.

Thoughts?

Thanks!
/haubi/
diff -rNu libtool-1.5.26.vanilla/tests/Makefile.in libtool-1.5.26.instd-test/tests/Makefile.in
--- libtool-1.5.26.vanilla/tests/Makefile.in	2008-02-01 17:38:41.0 +0100
+++ libtool-1.5.26.instd-test/tests/Makefile.in	2008-03-14 10:49:53.244749000 +0100
@@ -184,6 +184,7 @@
 	demo-inst.test demo-unst.test \
 	depdemo-static.test depdemo-make.test \
 	depdemo-exec.test depdemo-inst.test depdemo-unst.test \
+	depdemo-instd.test depdemo-unst.test \
 	mdemo-static.test mdemo-make.test mdemo-exec.test \
 	mdemo-inst.test mdemo-unst.test \
 	cdemo-conf.test cdemo-make.test cdemo-exec.test \
@@ -191,6 +192,7 @@
 	demo-inst.test demo-unst.test deplibs.test \
 	depdemo-conf.test depdemo-make.test \
 	depdemo-exec.test depdemo-inst.test depdemo-unst.test \
+	depdemo-instd.test depdemo-unst.test \
 	mdemo-conf.test mdemo-make.test mdemo-exec.test \
 	mdemo-inst.test mdemo-unst.test dryrun.test \
 	demo-nofast.test demo-make.test demo-exec.test \
@@ -199,11 +201,13 @@
 	demo-nopic.test demo-make.test demo-exec.test \
 	depdemo-nofast.test depdemo-make.test \
 	depdemo-exec.test depdemo-inst.test depdemo-unst.test \
+	depdemo-instd.test depdemo-unst.test \
 	cdemo-shared.test cdemo-make.test cdemo-exec.test \
 	demo-shared.test demo-make.test demo-exec.test demo-inst.test \
 	hardcode.test build-relink.test noinst-link.test demo-unst.test \
 	depdemo-shared.test depdemo-make.test \
-	depdemo-exec.test depdemo-inst.test build-relink2.test \
+	depdemo-exec.test depdemo-instd.test depdemo-unst.test \
+	depdemo-inst.test build-relink2.test \
 	depdemo-unst.test \
 	mdemo-shared.test mdemo-make.test mdemo-exec.test \
 	mdemo-inst.test mdemo-unst.test \
diff -rNu libtool-1.5.26.vanilla/tests/defs libtool-1.5.26.instd-test/tests/defs
--- libtool-1.5.26.vanilla/tests/defs	2005-07-08 17:50:35.0 +0200
+++ libtool-1.5.26.instd-test/tests/defs	2008-03-14 10:49:53.254752000 +0100
@@ -42,6 +42,16 @@
   prefix=NONE
 fi
 
+image=./_image
+if test $need_image = yes; then
+  # An absolute path to an image directory.
+  test -d $image || mkdir $image
+  image=`cd $image  pwd`
+else
+  test -d $image  rm -rf $image
+  image=
+fi
+
 # Extract CC from the libtool configuration
 eval `$libtool --config | grep '^CC='`
 
diff -rNu libtool-1.5.26.vanilla/tests/depdemo-instd.test libtool-1.5.26.instd-test/tests/depdemo-instd.test
--- libtool-1.5.26.vanilla/tests/depdemo-instd.test	1970-01-01 01:00:00.0 +0100
+++ libtool-1.5.26.instd-test/tests/depdemo-instd.test	2008-03-14 10:49:53.264743000 +0100
@@ -0,0 +1,68 @@
+#! /bin/sh
+# depdemo-instd.test - try installing

[libtool 2.1a] testsuite: 25 26 un-expected failure onhppa2.0w-hpux11.11

2007-10-12 Thread Michael Haubenwallner 
Hi,

libtool-2.1a (Build: 1.2519 2007/10/09 19:32:44) cannot do DESTDIR
installs (at least) on hppa2.0w-hp-hpux11.11.

Thing is, testsuite 25 and 26 result to expected failure, which really
should be FAIL.

There are three other thests FAILing: 18 32 55, but these are harmless
compared to 25 16.

Attached is a tar.bz2 containing some logfiles in 'build-gcc' after
these commands:

$ ../libtool-2.1a/configure --prefix=/tools/test/prefix-gcc  configure.out 21
$ gmake  gmake.out 21
$ VERBOSE=yes gmake check  check.out 21

For my build environment:

I'm using a self-built gcc-4.1.1 with self-built GNU as 2.16.1 and
native ld (through wrapper script, see below), both in same prefix.

$ gcc -v
Using built-in specs.
Target: hppa2.0w-hp-hpux11.11
Configured with: 
/mnt/toolsjunk/snapshot/src/sasrvb/toolsbox-3.5.4pre.20071011/buildroot/gcc/gcc-4.1.1/configure
 --enable-threads=posix
 --with-gnu-as
 
--with-as=/mnt/toolsjunk/snapshot/toolsbox-3.5.4pre.20071011/hppa2.0w-hp-hpux11.11/hppa2.0w-hp-hpux11.11/bin/as
 --without-gnu-ld
 
--with-local-prefix=/mnt/toolsjunk/snapshot/toolsbox-3.5.4pre.20071011/hppa2.0w-hp-hpux11.11
 --disable-nls
 --disable-static
 --disable-dependency-tracking
 
--prefix=/mnt/toolsjunk/snapshot/toolsbox-3.5.4pre.20071011/hppa2.0w-hp-hpux11.11
Thread model: posix
gcc version 4.1.1
$ $(gcc -print-prog-name=as) -v /dev/null
GNU assembler version 2.16.1 (hppa2.0w-hp-hpux11.11) using BFD version 2.16.1

As gcc does not ensure prefix/lib always being encoded into runpath
(for libgcc_s, libstdc++), I have some wrapper script around
'/usr/ccs/bin/ld', used by gcc to link.
This script ensures to have prefix/lib in runpath always, but without
changing expected ld(1) behaviour in respect of '+[no]defaultrpath',
'+s', '+b', '-L' ld flags. It is attached as ld.
Even if I checked that ld wrapper thrice, it still _could_ contain bugs
- apologize for them please - but they should not have any influence on
that DESTDIR checks.

Thanks!

/haubi/

-- 
17.-19. Oktober 2007
Salomon Automation am 24. Deutschen Logistik-Kongress der BVL, Berlin; Stand 
W/09

14. November 2007
Salomon Automation an der LogIT Retail im Leopoldsmuseum in Wien



Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz
Sitz der Gesellschaft: Friesach bei Graz
UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K
Firmenbuchgericht: Landesgericht für Zivilrechtssachen Graz



ld
Description: application/shellscript


libtool-2.1a-1.2519_hppa2.0w-hp-hpux11.11_gcc_check.tar.bz2
Description: application/bzip-compressed-tar
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool

checks using DESTDIR in libtool-1.5.22+ ?

2007-01-24 Thread Michael Haubenwallner 
Hi,

Using DESTDIR during 'make install' is very common for binary-packagers.
I've seen some problems on various platforms (mostly hpux and aix),
which do not appear when installing without DESTDIR.

So, am I missing something here, or are there no libtool-checks using
DESTDIR installs at all ?

I mean sth. like this:

 1. $ configure ...
 2. $ make
 3. $ make install DESTDIR=./_image
 4. $ make clean
 5. copy _image/$prefix to $prefix
 6. remove _image
 7. run the installed executables from $prefix

The two cleanup steps (4 and 6) are to check that the installed binaries
do not depend on libs in build- or image-dir.

Thanks,
/haubi/



___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool

general question on gcc -print-search-dirs multilib problem

2006-09-13 Thread Michael Haubenwallner 
Hi,

Based on recent thread on AC_LIBTOOL_SYS_DYNAMIC_LINKER:

I wonder why it is actually necessary for libtool to query system
library search dirs from gcc, because when gcc is used as linker, it
will know where to get system libs from.
Are there exceptions to this behaviour, which libtool has to work
around ?

Thanks,
  haubi
-- 
Michael HaubenwallnerSALOMON Automation GmbH
Forschung  Entwicklung  A-8114 Friesach bei Graz
mailto:[EMAIL PROTECTED]  http://www.salomon.at
No HTML/MIME please, see http://expita.com/nomime.html



___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool