sys_lib_search_path_spec

near the line 1110 of libtool.m4 thre should be
sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" | $SED -e 
's/\/ / /g'`

this strips '/' from the end of each path spec

else I got things like "warning /usr/lib//libIL.la moved"

segfault in ltdl:lt_dlforeachfile() on Mac OS 10

libtool 1.5

[FrankenMac:~/naim-0.11.6/libltdl] n% ../config.guess
powerpc-apple-darwin6.6
[FrankenMac:~/naim-0.11.6/libltdl] n% cat test.c
#include <time.h>
#include <ltdl.h>

int     modlist_filehelper(const char *path, lt_ptr data) {
        printf("path=%s, data=%p\n", path, data);
        return(0);
}

int     main(void) {
        lt_dlsetsearchpath("/usr/lib");
        lt_dlforeachfile(NULL, modlist_filehelper, NULL);
        return(0);
}
[FrankenMac:~/naim-0.11.6/libltdl] n% gcc -g3 test.c .libs/libltdlc.a -o test
[FrankenMac:~/naim-0.11.6/libltdl] n% gdb test
(gdb) run
Starting program: /Users/n/naim-0.11.6/libltdl/test
Reading symbols for shared libraries . done

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x9000423c in free_list_remove_ptr ()
(gdb) bt
#0  0x9000423c in free_list_remove_ptr ()
#1  0x90003f74 in szone_free ()
#2  0x9000e428 in szone_realloc ()

DESTDIR patch for the remaining inst_prefix problem

This patch is also posted to libtool <at> , that fixes another problem when
relinking staging libraries. The original behavior is to search system
library path first, so old version of libraries can be picked up before
the new ones in staging path. Now it always search staging path first,
thus avoiding wrong relinking.

Abel

-- 
Abel Cheung
Linux counter #256983   | http://counter.li.org
GPG Key: (0xC67186FF)   | http://deaddog.org/gpg.asc
Key fingerprint: 671C C7AE EFB5 110C D6D1  41EE 4152 E1F1 C671 86FF

Index: ChangeLog
===================================================================
RCS file: /cvsroot/libtool/libtool/ChangeLog,v
retrieving revision 1.1220.2.18
diff -u -r1.1220.2.18 ChangeLog
--- ChangeLog	26 Jun 2003 06:55:25 -0000	1.1220.2.18
+++ ChangeLog	6 Jul 2003 10:22:19 -0000
 <at>  <at>  -1,3 +1,9  <at>  <at> 
+2003-07-06  Abel Cheung  <maddog <at> linux.org.hk>
+
+	* ltmain.in: Always prepend inst_prefix_dir to deplibs so that
+	system libraries won't be picked up before staging libraries during
+	relinking.
+
 2003-06-25  Alexandre Oliva  <aoliva <at> redhat.com>, Tim Waugh  <twaugh <at> redhat.com>

make check failures

Libtool v. 1.5 fails on some tests; whereas libtool v. 1.4.3 passes all
the tests.

preamble:
SunOS [deleted] 5.8 Generic_108529-22 i86pc i386
gcc version 3.3 using native "ld" and "as"
./configure i686-pc-solaris2.8 --prefix=/usr/local/gnu --exec-prefix=/usr/local/gnu

test failures:

PASS: cdemo-static.test
PASS: cdemo-make.test
PASS: cdemo-exec.test
PASS: demo-static.test
FAIL: demo-make.test
FAIL: demo-exec.test
FAIL: demo-inst.test
PASS: demo-unst.test
PASS: depdemo-static.test
PASS: depdemo-make.test
PASS: depdemo-exec.test
PASS: depdemo-inst.test
PASS: depdemo-unst.test
PASS: mdemo-static.test
FAIL: mdemo-make.test
SKIP: mdemo-exec.test
SKIP: mdemo-inst.test
PASS: mdemo-unst.test
PASS: cdemo-conf.test
PASS: cdemo-make.test

libtool.m4: shrext should be shared_ext

[not subscribed to the list, only submitting bugfix]
Libtool 1.5 linux

Problem: $shared_ext has no value, libs are installed without .so suffix
Search on shrext and shared_ext in the mailinglist: no results.

/usr/share/aclocal/libtool.m4:

# Shared library suffix (normally ".so").
shrext='$shrext'

that should be
shared_ext='$shrext'

Re: libtool.m4: shrext should be shared_ext

tjoen wrote:
> [not subscribed to the list, only submitting bugfix]
> Libtool 1.5 linux
> 
> Problem: $shared_ext has no value, libs are installed without .so suffix
> Search on shrext and shared_ext in the mailinglist: no results.
> 
> /usr/share/aclocal/libtool.m4:
> 
> # Shared library suffix (normally ".so").
> shrext='$shrext'
> 
> that should be
> shared_ext='$shrext'

I think you have mismatched versions of libtool.m4 and ltmain.sh.

Max.

Problem in ".la" file

Hi

I'm working on the MacOS X (10.2.6) port of the OpenC++ project which  
uses Hans Boehm's garbage collector (GC 6.2) and GNU Libtool (1.5).

When building static versions of the garbage collector (libgc.a) and  
OpenC++ (libocc.a) a problem occurs during the generation of the  
"libocc.la" file:

# libocc.la - a libtool library file
# Generated by ltmain.sh - GNU libtool 1.5 (1.1220 2003/04/05 19:32:58)
#
# Please DO NOT delete this file!
# It is necessary for linking the library.

# The name that we can dlopen(3).
dlname=''

# Names of this library.
library_names=''

# The name of the static archive.
old_library='libocc.a'

# Libraries that this one depends upon.
dependency_libs=' -ldl /Users/ktulu/Projects/OpenC++/gc/libgc.la  
-lpthread  '

# Version information for libocc.
current=0

Re: wrong library path on cross compiling - libtool 1.5

On Mon, 14 Jul 2003, Sebastian Mancke wrote:
>
> On kaffe Mailing list I got the following answer:
> That's yet another bug in libtool, AFAIK. It seems to pick up libraries passed
> by --with-libraries only after it has tried to find a library in common
> library locations like /usr/lib. See
> http://mail.gnu.org/archive/html/libtool/2001-10/msg00127.html for a possible
> patch, that apparently has a typo somewhere ... sigh.

Please verify that this bug still exists in the current CVS libtool.
This patch is in libtool CVS:

2003-06-03  Benjamin Reed  <ranger <at> befunk.com>

        * ltmain.in: search libraries in the order of preference, rather
        than picking .la's even if they're in a less preferred directory.

Perhaps it will help with the library order problem.

Bob
======================================
Bob Friesenhahn
bfriesen <at> simple.dallas.tx.us
http://www.simplesystems.org/users/bfriesen

wrong library path on cross compiling - libtool 1.5

Hello.

I hope, my explanation ist enough.

On cross compiling kaffe (www.kaffe.org) to arm-linux
I ran in tho following error.

>  It inherently uses /usr/lib/libjpeg.so instead of 
> /usr/arm-linux/lib/libjpeg.so
> I also tryed to set the lib dirs by the following options:
>       LDFLAGS=-L/usr/arm-linux/lib/ 
>       --with-libraries=/usr/arm-linux/lib/
>       --with-awtlibpath=/usr/arm-linux/lib/
> Theese had no affects.

On kaffe Mailing list I got the following answer:
That's yet another bug in libtool, AFAIK. It seems to pick up libraries passed
by --with-libraries only after it has tried to find a library in common 
library locations like /usr/lib. See
http://mail.gnu.org/archive/html/libtool/2001-10/msg00127.html for a possible
patch, that apparently has a typo somewhere ... sigh.

Kind regards,
  Sebastian Mancke

Tests failed with libtool 1.5

Hi,

The following tests failed for me with libtool-1.5:

PASS: tagdemo-shared.test
PASS: tagdemo-make.test
PASS: tagdemo-exec.test
PASS: f77demo-static.test
PASS: f77demo-make.test
FAIL: f77demo-exec.test    <<< That one
PASS: f77demo-conf.test
PASS: f77demo-make.test
FAIL: f77demo-exec.test    <<< That one
PASS: f77demo-shared.test
PASS: f77demo-make.test
FAIL: f77demo-exec.test    <<< That one
====================================
3 of 105 tests failed
Please report to bug-libtool <at> gnu.org
====================================
make[2]: *** [check-TESTS] Error 1
make[2]: Leaving directory `/usr/src/libtool-1.5/tests'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/usr/src/libtool-1.5/tests'
make: *** [check-recursive] Error 1

I can't be any more informative at this time, except to say that I am
running glibc-2.3.2 and gcc-3.2.3 on a Linux 2.4.21 system. Where is
the output from the tests?