Re: [libtool 2.2] testsuite: 33 34 35 36 44 45 46 48 49 50 51 52 53 57 58 60 61 62 failed [NetBSD IA-32]
Ralf Wildenhues wrote: Hello Nelson, Peter, Not sure I remember. On the NetBSD system I tested, everything went through just fine. But I did use recent pristine Autoconf and Automake. I also tried in a VM with netbsd-4.0 (no modifications/additions to the default install) and there were no unexpected failures. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 40 41 42 44 45 46 48 49 50 51 52 53 failed
snowcrash+libtool wrote: (hm. looks like a list 'scrip is needed for bug-libtool. 'take 2'.) 13: duplicate_deps.at:25 preserve duplicate convenience deps libtool 17: convenience.at:109 F77 convenience archives F77 libtool 18: convenience.at:169 FC convenience archives FC libtool 19: convenience.at:229 Java convenience archives GCJ libtool 21: link-order2.at:46 Link order of deplibs. libtool 55: template.at:126template test with subdirs CXX libtool I have tried and failed to reproduce your failures on powerpc Mac OS X 10.4, and i386 Mac OS X 10.4 and 10.5. What versions of autoconf and automake did you use? Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [patch] 1.5.26 do echo=echo if necessary
Thien-Thi Nguyen wrote: () Thien-Thi Nguyen [EMAIL PROTECTED] () Sat, 08 Mar 2008 18:35:03 +0100 --- libtool-1.5.26/ltmain.sh.ORIG +++ libtool-1.5.26/ltmain.sh I see now that ltmain.sh is produced from ltmain.in. The change should be made there, instead. By the way, with this small change (and after installing Libtool 1.5.26), Automake 1.10.1 make check is successful. Hi, It seems likely that you have a configure that was created with a different version of libtool than ltmain.sh was created with. For matching versions of libtool.m4 and ltmain.sh from libtool-1.5.26, the generated libtool script should already have: # An echo program that does not interpret backslashes. echo=echo Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 64 failed [GNU/Linux IA-32]
Ralf Wildenhues wrote: * Peter O'Gorman wrote on Fri, Mar 07, 2008 at 08:40:08AM CET: Peter O'Gorman wrote: Ralf has already checked in a workaround for gcj being unable to create objects/executables. I guess I will add to that so it tests that an executable created by the compiler will actually run. Ok? Yes, provided that you've tested it ... +AT_CHECK([./foo1$(EXEEXT) || exit 77],[],[ignore],[ignore]) +rm -f foo1.o foo1.obj foo1$(EXEEXT) ... after eliminating those syntax errors, $EXEEXT instead of $(EXEEXT). Well that makes me feel silly :) Thanks. I tested that it ran the test on GNU/linux with GCJ=gcj and skipped when I set GCJ to 'gcj -L/home/pogma/lib -lzero' without /home/pogma/lib in the dynamic linker's search path. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 18 19 64 failed [Solaris 7 SPARC]
Ralf Wildenhues wrote: Hello Peter, * Peter O'Gorman wrote on Fri, Mar 07, 2008 at 02:04:41AM CET: Peter O'Gorman wrote: Nelson H. F. Beebe wrote: libtool: link: f90 -shared -Qoption ld --whole-archive ./.libs/liba1.a ./.libs/liba2.a -Qoption ld --no-whole-archive -Qoption ld -soname -Qoption ld liba12.so.0 -o .libs/liba12.so.0.0.0 /convenience.at:211: exit code was 1, expected 0 18. convenience.at:169: 18. FC convenience archives (convenience.at:169): FAILED (convenience.at:211) Libtool detected FC as f90, but otherwise used the gcc tools. I'll look into this. Because we generally use the same archive_cmds for F77, FC as for CXX, No we don't. archive_cmds _is_ tagged. In a casual test, it worked just fine for me to mix gcc and g++ with Solaris 10 f77 and f90. I know that it is tagged, however, I was smoking a lot of crack at the time and it must have had a bad effect on my judgement. I will try to cut down. Looks like Nelson is using GNU ld, so he always gets -shared in his archive_cmds. The solution might be to check on solaris if the compiler is a GNU compiler, and if not, set with_gnu_ld=no for that tag. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]
Ralf Wildenhues wrote: Hello Nelson, Peter, * Peter O'Gorman wrote on Thu, Mar 06, 2008 at 06:18:42AM CET: Nelson H. F. Beebe wrote: libtool: compile: gcj -g -O2 -c A3.java gcj: libgcj.spec: No such file or directory Your gcj and automake are broken. Do you have a sane toolchain on any of your systems? First off, let us thank Nelson for doing all this testing work for us. Thank you! Yes, thank you Nelson. Then, let's avoid us getting blame for broken gcj installations. OK to apply this patch to avoid the gcj test when a compile would fail? Or do you feel tests for working compilers should be done in configure already? I think the test for a working GCJ should be in libtool, and unset GCJ, avoid adding the tag etc.if it is found to be nonfunctional. We would have to issue a warning during configure or something. Does not look to be quite as easy as this patch though, if you want to apply this one as a stop-gap measure, that is fine. Cheers, Ralf 2008-03-06 Ralf Wildenhues [EMAIL PROTECTED] * tests/convenience.at (Java convenience archives): Skip test if gcj cannot compile a .java file. Report by Nelson H. F. Beebe. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]
Ralf Wildenhues wrote: * Bob Friesenhahn wrote on Thu, Mar 06, 2008 at 08:43:15PM CET: On Thu, 6 Mar 2008, Peter O'Gorman wrote: I think the test for a working GCJ should be in libtool, and unset GCJ, avoid adding the tag etc.if it is found to be nonfunctional. We would have to issue a warning during configure or something. Does not look to be quite as easy as this patch though, if you want to apply this one as a stop-gap measure, that is fine. I'm considering doing that (the stop-gap measure). Your call. Yes, and I can conceive just as well a libtool-using package which may optionally use a Java compiler, and thus its configure script should not bail out at Libtool's whim either. I agree, the way LT_LANG has worked so far is to test if a compiler for the language exists and is executable (or something similar), but not cause an error if it does not. What would be ideal is to check that the compiler exists, is executable, works (an possibly, when not cross-compiling, test that trivial code that is compiled with the compiler runs) but not cause an error if the compiler is broken or does not exist, simply warn the user that a broken compiler was detected and set the same vars in the same way as would be set if no compiler was detected. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 18 19 64 failed [Solaris 7 SPARC]
Peter O'Gorman wrote: Nelson H. F. Beebe wrote: libtool: link: f90 -shared -Qoption ld --whole-archive ./.libs/liba1.a ./.libs/liba2.a -Qoption ld --no-whole-archive -Qoption ld -soname -Qoption ld liba12.so.0 -o .libs/liba12.so.0.0.0 /convenience.at:211: exit code was 1, expected 0 18. convenience.at:169: 18. FC convenience archives (convenience.at:169): FAILED (convenience.at:211) Libtool detected FC as f90, but otherwise used the gcc tools. I'll look into this. Because we generally use the same archive_cmds for F77, FC as for CXX, things can get a little messed up. This fixes the most common case, gcc, g++, g77/gfortran some other fortran compiler, by pretending the other fortran compiler does not exist. Thoughts? Peter -- Peter O'Gorman http://pogma.com 2008-03-06 Peter O'Gorman [EMAIL PROTECTED] * libltdl/m4/libtool.m4 (_LT_PROG_FC): Report FC=no if the FC compiler is not a GNU compiler and the CXX compiler is a GNU compiler. Reported by Nelson H. F. Beebe. Index: libltdl/m4/libtool.m4 === RCS file: /sources/libtool/libtool/libltdl/m4/libtool.m4,v retrieving revision 1.138 diff -u -r1.138 libtool.m4 --- libltdl/m4/libtool.m4 4 Mar 2008 21:14:22 - 1.138 +++ libltdl/m4/libtool.m4 7 Mar 2008 01:00:35 - @@ -6644,6 +6644,15 @@ if test -z $FC || test X$FC = Xno; then _lt_disable_FC=yes fi + +# If g++ is being used, but the fortran compiler is not a gnu +# compiler, we should simply ignore it. It will not grok -shared, for +# example. +if test x$ac_cv_fc_compiler_gnu != x$GXX; then + FC=no + _lt_disable_FC=yes +fi + popdef([AC_MSG_ERROR]) ])# _LT_PROG_FC ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 64 failed [GNU/Linux IA-32]
Nelson H. F. Beebe wrote: Re: [libtool 2.2] testsuite: 19 64 failed [GNU/Linux IA-32] Hmm. Does the gcj on this system add -liconv at link time, but somehow not add it to the rpath? Thank you for the response. The separate need for -Wl,-rpath,/path/to/something or -R/path/to/something in addition to -L/path/to/something is common on many Unix flavors if executables are to run without an environment variable like LD_LIBRARY_PATH having to be set. We don't use the ld.so.conf feature on GNU/Linux, because we found that it broke too many gnome packages. The gcj in /usr/local/bin does indeed add -liconv, thank you for confirming my suspicion. Ralf has already checked in a workaround for gcj being unable to create objects/executables. I guess I will add to that so it tests that an executable created by the compiler will actually run. What does: gcj -### -o /dev/null /dev/null show? I have two versions of gcj on this system: % \which -a gcj /usr/local/bin/gcj /usr/bin/gcj % /usr/bin/gcj --version gcj (GCC) 3.4.6 20060404 (Red Hat 3.4.6-9) % /usr/local/bin/gcj --version gcj (GCC) 3.4.3 % /usr/bin/gcj -### -o /dev/null /dev/null Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/libgcj.spec rename spec lib to liborig Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/u sr/share/info --enable-shared --enable-threads=posix --disable-checking --with-s ystem-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-aw t=gtk --host=i386-redhat-linux Thread model: posix gcc version 3.4.6 20060404 (Red Hat 3.4.6-9) /usr/libexec/gcc/i386-redhat-linux/3.4.6/collect2 --eh-frame-hdr -m elf_ i386 -dynamic-linker /lib/ld-linux.so.2 -o /dev/null /usr/lib/gcc/i386 -redhat-linux/3.4.6/../../../crt1.o /usr/lib/gcc/i386-redhat-linux/3.4.6/../.. /../crti.o /usr/lib/gcc/i386-redhat-linux/3.4.6/crtbegin.o -L/usr/local/sys/ FortranPlus/fplus_55h/lib -L/usr/lib/gcc/i386-redhat-linux/3.4.6 -L/usr/lib/ gcc/i386-redhat-linux/3.4.6 -L/usr/lib/gcc/i386-redhat-linux/3.4.6/../../.. /dev/null -lgcc_s -lgcc -lgcj -lm -lpthread -lz -ldl -lgcc_s - lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/i386-redhat-linux % /usr/local/bin/gcj -### -o /dev/null /dev/null Reading specs from /export/local/i386-linux/bin/../lib/gcc/i686-pc-linux-gnu/3.4 .3/specs Reading specs from /export/local/i386-linux/bin/../lib/gcc/i686-pc-linux-gnu/3.4 .3/../../../libgcj.spec rename spec lib to liborig Configured with: ../gcc-3.4.3/configure Thread model: posix gcc version 3.4.3 /export/local/i386-linux/bin/../libexec/gcc/i686-pc-linux-gnu/3.4.3/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o /d ev/null /usr/lib/crt1.o /usr/lib/crti.o /export/local/i386-linux/bin/../li b/gcc/i686-pc-linux-gnu/3.4.3/crtbegin.o -L/export/local/i386-linux/bin/../lib /gcc/i686-pc-linux-gnu/3.4.3 -L/export/local/i386-linux/bin/../lib/gcc -L/us r/local/sys/FortranPlus/fplus_55h/lib -L/usr/local/lib/gcc/i686-pc-linux-gnu/3 .4.3 -L/export/local/i386-linux/bin/../lib/gcc/i686-pc-linux-gnu/3.4.3/../../. ./../i686-pc-linux-gnu/lib -L/usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/../../ ../../i686-pc-linux-gnu/lib -L/export/local/i386-linux/bin/../lib/gcc/i686-pc- linux-gnu/3.4.3/../../.. -L/usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/../../.. /dev/null -lgcc_s -lgcc -lgcj -lm -liconv -lpthread -ldl -lgc c_s -lgcc -lc -lgcc_s -lgcc /export/local/i386-linux/bin/../lib/gcc/i6 86-pc-linux-gnu/3.4.3/crtend.o /usr/lib/crtn.o Thank you. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 18 19 64 failed [Solaris 7 SPARC]
Bob Friesenhahn wrote: On Thu, 6 Mar 2008, Peter O'Gorman wrote: Libtool detected FC as f90, but otherwise used the gcc tools. I'll look into this. Because we generally use the same archive_cmds for F77, FC as for CXX, things can get a little messed up. This fixes the most common case, gcc, g++, g77/gfortran some other fortran compiler, by pretending the other fortran compiler does not exist. This seems ok for now but it does seem that the inability to mix compilers which would otherwise interoperate should be put on the list of future libtool issues to solve for the next big release. It seems perfectly reasonable to use a non-GNU fortran or C++ compiler along with GCC. Thanks. I committed it. Not that I like it either :( Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 18 19 64 failed [Solaris 7 SPARC]
Gary V. Vaughan wrote: On 6 Mar 2008, at 20:04, Peter O'Gorman wrote: Peter O'Gorman wrote: Nelson H. F. Beebe wrote: libtool: link: f90 -shared -Qoption ld --whole-archive ./.libs/liba1.a ./.libs/liba2.a -Qoption ld --no-whole-archive -Qoption ld -soname -Qoption ld liba12.so.0 -o .libs/liba12.so.0.0.0 /convenience.at:211: exit code was 1, expected 0 18. convenience.at:169: 18. FC convenience archives (convenience.at:169): FAILED (convenience.at:211) Libtool detected FC as f90, but otherwise used the gcc tools. I'll look into this. Because we generally use the same archive_cmds for F77, FC as for CXX, things can get a little messed up. This fixes the most common case, gcc, g++, g77/gfortran some other fortran compiler, by pretending the other fortran compiler does not exist. Thoughts? What happens to a project written with gnu C and vendor fortran? Will this test spot g++ and refuse to build the fortran files? Depends on if those fortran compilers have their own rules or if they are inheriting. Maybe we should look into tagging the archive_cmds instead. I did not see this mail til just now (after the commit). Want me to revert? Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 18 19 64 failed [Solaris 7 SPARC]
Ralf Wildenhues wrote: I find this patch very very ugly. It's a confession that after a decade, we still can't get multi-lang right. I'm pretty sure that it will cause regressions for some people, too. Ok - reverting. Btw, fixed my spam filter, now you and gary do not end up in spam mailbox :) Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 64 failed [Solaris AMD64]
Ralf Wildenhues wrote:
This should be $LD -r here, no? AFAICS this failure happens inside the
low max_cmd_len test. This looks like a regression caused by the patch
that removed _LT_SYS_DYNAMIC_LINKER from _LT_LANG_GCJ_CONFIG. (If that
turns out to be true, I am glad we did not make this change for the
other tags). This did not show up on GNU/Linux because there
--whole-archive is used.
Case in point:
$ ./libtool --tag=GCJ --config|grep ^LD
LD=/usr/bin/ld
LD=
Fixed with attached patch. Committed as obvious.
Thanks for pointing me in the right direction.
Peter
--
Peter O'Gorman
http://pogma.com
2008-03-07 Peter O'Gorman [EMAIL PROTECTED]
* libltdl/m4/libtool.m4 (_LT_LANG_GCJ_CONFIG): Need to set LD.
Reported by Nelson H. F. Beebe.
Index: libltdl/m4/libtool.m4
===
RCS file: /sources/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.140
diff -u -r1.140 libtool.m4
--- libltdl/m4/libtool.m4 7 Mar 2008 06:14:26 - 1.140
+++ libltdl/m4/libtool.m4 7 Mar 2008 06:37:46 -
@@ -6815,6 +6815,7 @@
CC=${GCJ-gcj}
compiler=$CC
_LT_TAGVAR(compiler, $1)=$CC
+_LT_TAGVAR(LD, $1)=$LD
_LT_CC_BASENAME([$compiler])
# GCJ did not exist at the time GCC didn't implicitly link libc in.
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 64 failed [GNU/Linux IA-32]
Peter O'Gorman wrote: The gcj in /usr/local/bin does indeed add -liconv, thank you for confirming my suspicion. Ralf has already checked in a workaround for gcj being unable to create objects/executables. I guess I will add to that so it tests that an executable created by the compiler will actually run. Ok? Peter -- Peter O'Gorman http://pogma.com 2008-03-07 Peter O'Gorman [EMAIL PROTECTED] * tests/convenience.at (Java convenience archives): Skip test if gcj cannot compile a working executable from .java files. Report by Nelson H. F. Beebe. Index: tests/convenience.at === RCS file: /sources/libtool/libtool/tests/convenience.at,v retrieving revision 1.9 diff -u -r1.9 convenience.at --- tests/convenience.at 6 Mar 2008 19:59:25 - 1.9 +++ tests/convenience.at 7 Mar 2008 07:38:32 - @@ -262,8 +262,10 @@ # There are just too many broken gcj installations out there, either missing # libgcj.spec or unable to find it. Skip this test for them. if test $i -eq 1; then -AT_CHECK[($GCJ $GCJFLAGS -c foo1.java || exit 77], [], [ignore], [ignore]) -rm -f foo1.o foo1.obj +AT_CHECK([$GCJ $GCJFLAGS -c foo1.java || exit 77], [], [ignore], [ignore]) +AT_CHECK([$GCJ $GCJFLAGS --main=foo1 -o foo1 foo1.java A1.java || exit 77],[],[ignore],[ignore]) +AT_CHECK([./foo1$(EXEEXT) || exit 77],[],[ignore],[ignore]) +rm -f foo1.o foo1.obj foo1$(EXEEXT) fi $LIBTOOL --tag=GCJ --mode=compile $GCJ $GCJFLAGS -c foo$i.java ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [Solaris IA-32]
Nelson H. F. Beebe wrote:
## --- ##
## libtool 2.2 test suite. ##
## --- ##
testsuite: command line was:
$ /local/build/bare/libtool-2.2/tests/testsuite MAKE=make CC=gcc CFLAGS=-g
-O2 CPP=gcc -E CPPFLAGS= LD=/usr/ccs/bin/ld LDFLAGS= LIBS= LN_S=ln -s
NM=/usr/local/bin/nm -B RANLIB=ranlib STRIP=strip OBJEXT=o EXEEXT=
SHELL=/bin/bash CONFIG_SHELL=/bin/bash CXX=g++ CXXFLAGS=-g -O2 CXXCPP=g++ -E
F77=g77 FFLAGS=-g -O2 FC=f95 FCFLAGS=-g GCJ=gcj GCJFLAGS=-g -O2
_lt_pkgdatadir=/local/build/bare/libtool-2.2
LIBTOOLIZE=/local/build/bare/libtool-2.2/libtoolize
LIBTOOL=/local/build/bare/libtool-2.2/libtool
tst_aclocaldir=/local/build/bare/libtool-2.2/libltdl/m4
+++ /local/build/bare/libtool-2.2/tests/testsuite.dir/at-stderr
2008-03-04 15:36:24.883120064 -0700
@@ -0,0 +1 @@
+GC Warning: Large stack limit(133464064): only scanning 8 MB
19. convenience.at:229: 19. Java convenience archives (convenience.at:229):
FAILED (convenience.at:277)
This stack limit warning caused the test to fail. Not pretty, but a bug
in the test, not in libtool itself.
automake:
automake: ## Internal Error ##
automake:
automake: Unknown ?token? `LZMA' (neg = 0)
automake: Please contact [EMAIL PROTECTED].
at /usr/local/share/automake-1.10/Automake/Channels.pm line 570
Automake::Channels::msg('automake', '', 'Unknown ?token? `LZMA\' (neg =
0)') called at /usr/local/share/automake-1.10/Automake/ChannelDefs.pm line 191
Automake::ChannelDefs::prog_error('Unknown ?token? `LZMA\' (neg = 0)')
called at /usr/local/bin/automake line 6406
Automake::transform('?LZMA?', 'HASH(0x85404bc)') called at
/usr/local/bin/automake line 6469
Automake::make_paragraphs('/usr/local/share/automake-1.10/am/distdir.am',
'GETTEXT', 0, 'DISTCHECK-HOOK', '', 'FILENAME_FILTER', '', 'DIST-TARGETS',
'', ...) called at /usr/local/bin/automake line 6539
Automake::file_contents_internal(1,
'/usr/local/share/automake-1.10/am/distdir.am',
'Automake::Location=HASH(0x8614194)', 'DISTCHECK-HOOK', '', 'GETTEXT', 0,
'FILENAME_FILTER', '', ...) called at /usr/local/bin/automake line 6719
Automake::file_contents('distdir',
'Automake::Location=HASH(0x8614194)', 'DIST-TARGETS', '', 'GETTEXT', 0,
'DISTCHECK-HOOK', '', 'FILENAME_FILTER', ...) called at
/usr/local/bin/automake line 3688
Automake::handle_dist() called at /usr/local/bin/automake line 7493
Automake::generate_makefile('Makefile.am', 'Makefile.in') called at
/usr/local/bin/automake line 7834
stdout:
./am-subdir.at:78: exit code was 2, expected 0
./am-subdir.at:78: grep 'require .*but have' stderr (exit 77)
35. am-subdir.at:33: 35. C subdir-objects (am-subdir.at:33): FAILED
(am-subdir.at:78)
There appears to be a problem with your automake install that is causing
most of these test failures.
Peter
--
Peter O'Gorman
http://pogma.com
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 18 19 64 failed [Solaris 7 SPARC]
Nelson H. F. Beebe wrote: libtool: link: f90 -shared -Qoption ld --whole-archive ./.libs/liba1.a ./.libs/liba2.a -Qoption ld --no-whole-archive -Qoption ld -soname -Qoption ld liba12.so.0 -o .libs/liba12.so.0.0.0 /convenience.at:211: exit code was 1, expected 0 18. convenience.at:169: 18. FC convenience archives (convenience.at:169): FAILED (convenience.at:211) Libtool detected FC as f90, but otherwise used the gcc tools. I'll look into this. libtool: compile: gcj -g -O2 -c A3.java A3.java:0: Can't find default package `java.lang'. Check the CLASSPATH environment variable and the access to the archives. Your gcj install is broken. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]
Nelson H. F. Beebe wrote:
libtool: compile: gcj -g -O2 -c A3.java
gcj: libgcj.spec: No such file or directory
automake:
automake: ## Internal Error ##
automake:
automake: Unknown ?token? `LZMA' (neg = 0)
automake: Please contact [EMAIL PROTECTED].
at /usr/local/share/automake-1.10/Automake/Channels.pm line 570
Automake::Channels::msg('automake', '', 'Unknown ?token? `LZMA\' (neg =
0)') called at /usr/local/share/automake-1.10/Automake/ChannelDefs.pm line 191
Automake::ChannelDefs::prog_error('Unknown ?token? `LZMA\' (neg = 0)')
called at /usr/local/bin/automake line 6406
Automake::transform('?LZMA?', 'HASH(0x104aa0d0)') called at
/usr/local/bin/automake line 6469
Automake::make_paragraphs('/usr/local/share/automake-1.10/am/distdir.am',
'GETTEXT', 0, 'DISTCHECK-HOOK', '', 'FILENAME_FILTER', '', 'DIST-TARGETS',
'', ...) called at /usr/local/bin/automake line 6539
Automake::file_contents_internal(1,
'/usr/local/share/automake-1.10/am/distdir.am',
'Automake::Location=HASH(0x105b3d30)', 'DISTCHECK-HOOK', '', 'GETTEXT', 0,
'FILENAME_FILTER', '', ...) called at /usr/local/bin/automake line 6719
Automake::file_contents('distdir',
'Automake::Location=HASH(0x105b3d30)', 'DIST-TARGETS', '', 'GETTEXT', 0,
'DISTCHECK-HOOK', '', 'FILENAME_FILTER', ...) called at
/usr/local/bin/automake line 3688
Automake::handle_dist() called at /usr/local/bin/automake line 7493
Automake::generate_makefile('Makefile.am', 'Makefile.in') called at
/usr/local/bin/automake line 7834
Your gcj and automake are broken. Do you have a sane toolchain on any of
your systems?
Peter
--
Peter O'Gorman
http://pogma.com
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 64 failed [GNU/Linux IA-32]
Nelson H. F. Beebe wrote: libtool: link: gcj -g -O2 --main=foo1 -o main_static .libs/foo1.o ./.libs/liba1.a +++ /local/build/bare/libtool-2.2/tests/testsuite.dir/at-stderr 2008-03-04 15:26:49.0 -0700 @@ -0,0 +1 @@ +./main_static: error while loading shared libraries: libiconv.so.2: cannot open shared object file: No such file or directory ./convenience.at:277: exit code was 127, expected 0 19. convenience.at:229: 19. Java convenience archives (convenience.at:229): FAILED (convenience.at:277) Hmm. Does the gcj on this system add -liconv at link time, but somehow not add it to the rpath? What does: gcj -### -o /dev/null /dev/null show? Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 64 failed [Solaris AMD64]
Nelson H. F. Beebe wrote: Hi Nelson, I admit that I don't understand the failures like this one yet. /convenience.at:265: $LIBTOOL --tag=GCJ --mode=link $GCJ $GCJFLAGS $LDFLAGS -o liba12.la liba1.la liba2.la -rpath /notexist stderr: stdout: libtool: link: gcj -shared -Wl,-z -Wl,text -Wl,-h -Wl,liba12.so.0 -o .libs/liba12.so.0.0.0 -Wl,-z -Wl,allextract ./.libs/liba1.a ./.libs/liba2.a -Wl,-z -Wl,defaultextract $GCJ is properly expanded to 'gcj' here. /convenience.at:267: $LIBTOOL --tag=GCJ --mode=link $GCJ $GCJFLAGS $LDFLAGS -o liba123.la A3.lo liba1.la liba2.la -rpath /notexist stderr: /local/build/bare/libtool-2.2/tests/testsuite.dir/64/libtool: line 7084: -r: command not found stdout: libtool: link: -r -o .libs/liba123.la-1.o .libs/A3.o But here it is the empty string! I'll look at it tomorrow. Thanks. Peter ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]
Bob Friesenhahn wrote: On Wed, 5 Mar 2008, Peter O'Gorman wrote: Your gcj and automake are broken. Do you have a sane toolchain on any of your systems? That sounds a little harsh. I think that the LZMA complaint from automake may be because libtool requests a lzma package and it requires the very latest automake to do so. Most people won't have the latest automake. Libtool maintainers typically run all of the latest autotools in relatively pristine environments. With so many tests, we can expect plenty of breakage in more typical user environments. The test failures don't mean that libtool won't satisfy the user's actual requirements. You are right, of course, it was too harsh. I was simply overwhelmed when I looked at the volume of mail on the bug-libtool list. Because of the lzma addition, an automake that is new enough to create lzma dists is required to run the testsuite. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 33 34 35 36 44 45 46 48 49 50 51 52 53 57 58 60 61 62 failed [NetBSD IA-32]
Nelson H. F. Beebe wrote: ./old-m4-iface.at:85: CONFIG_SHELL=$SHELL $SHELL ./configure $configure_options stderr: stdout: ./old-m4-iface.at:85: $MAKE stderr: make[4]: *** No targets specified and no makefile found. Stop. Hmm. 'CONFIG_SHELL=$SHELL $SHELL ./configure $configure_options' does not appear to do anything? I think Ralf has seen this before, if not I will look at it. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 12 17 19 38 64 failed [Mac OS X Intel]
Nelson H. F. Beebe wrote: ./duplicate_conv.at:81: $LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o main main.$OBJEXT cee.$OBJEXT stderr: /usr/bin/ld: Undefined symbols: _c collect2: ld returned 1 exit status stdout: libtool: link: gcc -g -O2 -o main main.o cee.o ./duplicate_conv.at:81: exit code was 1, expected 0 12. duplicate_conv.at:25: 12. duplicate convenience archive names (duplicate_conv.at:25): FAILED (duplicate_conv.at:81) This one looks like my bad. Will look. Thanks. /usr/bin/ld: /usr/local/lib/libf2c.a(main.o) malformed object (section (__TEXT,__textcoal_nt) no symbol at start of coalesced section) /usr/bin/ld: /usr/local/lib/libf2c.a(close.o) malformed object (section (__TEXT,__textcoal_nt) no symbol at start of coalesced section) /usr/bin/ld: /usr/local/lib/libf2c.a(err.o) malformed object (section (__TEXT,__textcoal_nt) no symbol at start of coalesced section) /usr/bin/ld: /usr/local/lib/libf2c.a(sig_die.o) malformed object (section (__TEXT,__textcoal_nt) no symbol at start of coalesced section) /usr/bin/ld: /usr/local/lib/libf2c.a(endfile.o) malformed object (section (__TEXT,__textcoal_nt) no symbol at start of coalesced section) /usr/bin/ld: /usr/local/lib/libf2c.a(open.o) malformed object (section (__TEXT,__textcoal_nt) no symbol at start of coalesced section) collect2: ld returned 1 exit status I must admit to not having tested on Mac OS X with fortran and java for a while, but this looks like a broken compiler. gcj: libgcj.spec: No such file or directory libtool: compile: gcj -g -O2 -c A3.java gcj: libgcj.spec: No such file or directory So does this. I am now building gfortran, gcj etc on Mac OS X intel to make sure that things are working :) Thanks, Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 64 failed [GNU/Linux Alpha]
Nelson H. F. Beebe wrote: @@ -0,0 +1 @@ +./main_static: error while loading shared libraries: libgcj.so.4: cannot open shared object file: No such file or directory ./convenience.at:277: exit code was 127, expected 0 19. convenience.at:229: 19. Java convenience archives (convenience.at:229): FAILED (convenience.at:277) Your gcj on this system does not appear to add the runpath to libgcj when linking. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 64 failed [GNU/Linux AMD64]
Nelson H. F. Beebe wrote: /export/local/x86_64-linux/bin/../lib/gcc-lib/x86_64-unknown-linux-gnu/3.3.5/jc1: error while loading shared libraries: libiconv.so.2: cannot open shared object file: No such file or directory Problem with your gcj install and libiconv on this machine too. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Another powerpc64 biarch problem.
Steven Munroe wrote: On Sat, 2008-03-01 at 09:39 -0600, Peter O'Gorman wrote: Steven Munroe wrote: I am trying to build a package on a OpenSuse-10.3 PowerMac G5. and I see the following: /bin/sh ../../libtool --tag=CC --mode=link /usr/bin/gcc -m64 -g -O2 -mcpu=power 4 -fno-strict-aliasing -Wdeclaration-after-statement -g -Wall -Wunused -Wmissing -prototypes -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes -Wn ested-externs -Wpointer-arith -Wno-cast-qual -Wcast-align -Wwrite-strings -m64 -o pedump pedump.o libmonoruntime.la ../io-layer/libwapi.la ../utils/libmonouti ls.la ../../libgc/libmonogc.la -pthread -lgthread-2.0 -lrt -lglib-2.0 -lm -ldl -lpthread -lm libtool: link: cannot find the library `/usr/lib64/libpcre.la' or unhandled argument `/usr/lib64/libpcre.la' It seems likely that some other .la file has /usr/lib64/libpcre.la in its dependency_libs. If you add --debug immediately prior to the --tag=CC and save stdout and stderr to a log, reading the log should tell you which one. Alternatively, grep for /usr/lib64/libpcre.la in /usr/lib64. The dependency seem to be coming from /usr/lib64/libgthread-2.0.la at least on the system that is failing. The older (--debug output - libtool-libpcre-ok.tgz) system does not seem to have the same dependency. I still don't understand why libtool does not simply link to the /usr/lib64/libpcre.so that is there? This is really annoying... Both libgthread and libglib have /usr/lib64/libpcre.la in dependency_libs, so this file must have existed when glib was built. Now it does not. Your choices are: 1) rebuild glib (when rebuilt without the presence of /usr/lib64/libpcre.la, that will not appear in dependency_libs) 2) rebuild/reinstall 64bit pcre (to get the .la file back) 3) edit the glib .la files by hand and change /usr/lib64/libpcre.la to -lpcre (ugly) Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libltdl memory corruption
Ralf Wildenhues wrote: Hello Andreas, * Andreas Schwab wrote on Mon, Mar 03, 2008 at 03:39:47PM CET: libltdl uses memory after free when initialized twice. Thank you very much for the bug report. Proposed patch below. I tested it on i686-unknown-linux-gnu but it should be tested with as many loaders as possible. So I'd appreciate a review of this, and also test results on systems with loaders other than preopen and dlopen. (I haven't even tested successful compilation on those other systems.) This looks ok with a quick visual inspection. I'll try it on a couple of systems tonight (dyld on mac os x 10.2, and shl_load on hpux10.20). Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Another powerpc64 biarch problem.
Steven Munroe wrote: I am trying to build a package on a OpenSuse-10.3 PowerMac G5. and I see the following: /bin/sh ../../libtool --tag=CC --mode=link /usr/bin/gcc -m64 -g -O2 -mcpu=power 4 -fno-strict-aliasing -Wdeclaration-after-statement -g -Wall -Wunused -Wmissing -prototypes -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes -Wn ested-externs -Wpointer-arith -Wno-cast-qual -Wcast-align -Wwrite-strings -m64 -o pedump pedump.o libmonoruntime.la ../io-layer/libwapi.la ../utils/libmonouti ls.la ../../libgc/libmonogc.la -pthread -lgthread-2.0 -lrt -lglib-2.0 -lm -ldl -lpthread -lm libtool: link: cannot find the library `/usr/lib64/libpcre.la' or unhandled argument `/usr/lib64/libpcre.la' It seems likely that some other .la file has /usr/lib64/libpcre.la in its dependency_libs. If you add --debug immediately prior to the --tag=CC and save stdout and stderr to a log, reading the log should tell you which one. Alternatively, grep for /usr/lib64/libpcre.la in /usr/lib64. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: portability of -Lrelative_directory_name
Hi Bruno, Bruno Haible wrote: Hi, A while ago someone said that if in a build directory I have a (not yet installed) ../lib/libfoo.la, to link with this library I should *not* use libtool ... -L../lib -lfoo but rather mention the .la file explicitly: libtool ... -L../lib ../lib/libfoo.la Even this will probably end up with the build directory encoded in the .la file's dependency_libs, the -L../lib will be modified to -L/absolute/path/to/lib and that added to dependency_libs. or libtool ... ../lib/libfoo.la Now I see the same advice in the second-to-last paragraph of http://wiki.finkproject.org/index.php/Fink:Porting_Notes Is it true that references to non-yet-installed libool libraries should not be made with -l? If so, it would be worth to document this in the libtool documentation. I didn't find it there. I think this is a bug in libtool that it encodes the build directory into the .la files, however, you are correct, it is a doc bug too, I will look making a patch to the docs tonight. Thanks, Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Mac OS X 10.2.8 HEAD test failures.
So, I dug my old g3 tower out of the closet, started it up and ran the libtool testsuite (I wanted to see what failed currently before trying a patch to see what failed after it). There are a number of failures related to the older autotools in the default install of 10.2.8. (autoconf-2.52, automake-1.6.1) Test 28 fails because autoconf-2.52 does not grok --force. autoconf: invalid option --force Tests 46, 47 and 48 fail because autoconf-2.52 does not have AC_CONFIG_MACRO_DIR: ./configure: line 894: syntax error near unexpected token `LT_CONFIG_LTDL_DIR(ltdl,' Tests 05,29,30,31,39,40,41,43,44,45,46,47,48,52 and 53 fail because aclocal: macro `_LT_CHECK_BUILDDIR' required but not defined Looks like _LT_CHECK_BUILDDIR is m4_defun'ed but AC_REQUIRED. Should we skip 28,46,47 and 48 if autoconf is too old, and m4_require _LT_CHECK_BUILDDIR? Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libtool fails if user has environment variable D defined
On Wed, 2007-08-08 at 11:16 -1000, Sebastian Jester wrote: We do not want portage's install root ($D) present. This is not in the official libtool release, probably from a gentoo patch. Peter ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: lt_dlsym() Doesn't Allow for a Symbol with Address of 0.
On Sun, 2007-07-22 at 18:30 +0100, Ralph Corderoy wrote:
Hi Peter,
I investigated a problem on the llvmdev mailing list where someone was
trying to find the value of a symbol that has an address of 0.
$ nm /System/Library/Frameworks/Foundation.framework/Foundation |
grep .objc_class_name_NSAutoreleasePool
A .objc_class_name_NSAutoreleasePool
$
It is not possible to lookup this symbol on Mac OS X with dlsym()
because it does not have an underscore prefix.
I don't know if dlsym() is being used on Mac OS X, I just went looking
there because I understand it behaviour.
Yes, dlsym is used on Mac OS X 10.3 and later, and it will return a
symbol not found error (and set dlerror) when you call
dlsym(h,.objc_foo) because it will look for _.objc_foo and not find
it. This is something that the llvm people will have to figure out on
their end. See the manpages for Mac OS X's dlsym at
http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/dlsym.3.html
for confirmation.
Thanks, my dlsym(3) on Ubuntu Linux warns me it can return NULL when the
found symbol has an address of 0 and to use dlerror() twice to find out
what really happened.
Yes, I agree with your analysis, lt_dlerror should return NULL if
dlerror() would have done so. If you want to send a patch to do this
(for HEAD - a quite different libltdl), please do so, if not, I guess
it's up to me :-)
I don't believe that changing this behavior in ltdl will actually help
in the llvm objc case though, sorry.
Peter
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libtool generates incorrect option for Solaris ld
On Mon, 2007-07-02 at 15:48 +0200, Vincent Lefevre wrote: I've done a make dist on the MPFR library under Debian, and with this tarball, when I do a ./configure --enable-shared under Solaris, make fails: [...] /bin/ksh ./libtool --tag=CC --mode=link cc -xtarget=native -xarch=v9 -xO4 -L/users/spaces/vlefevre/sparc-solaris/gmp-assert/lib -o libmpfr.la -rpath /usr/local/lib -version-info 2:0:1 exceptions.lo extract.lo uceil_exp2.lo uceil_log2.lo ufloor_log2.lo add.lo add1.lo add_ui.lo agm.lo clear.lo cmp.lo cmp_abs.lo cmp_si.lo cmp_ui.lo comparisons.lo div_2exp.lo div_2si.lo div_2ui.lo div.lo div_ui.lo dump.lo eq.lo exp10.lo exp2.lo exp3.lo exp.lo frac.lo get_d.lo get_exp.lo get_str.lo init.lo inp_str.lo isinteger.lo isinf.lo isnan.lo isnum.lo const_log2.lo log.lo mul_2exp.lo mul_2si.lo mul_2ui.lo mul.lo mul_ui.lo neg.lo next.lo out_str.lo const_pi.lo pow.lo pow_si.lo pow_ui.lo print_raw.lo print_rnd_mode.lo random2.lo random.lo reldiff.lo round_prec.lo set.lo setmax.lo setmin.lo set_d.lo set_dfl_prec.lo set_exp.lo set_rnd.lo set_f.lo set_prc_raw.lo set_prec.lo set_q.lo set_si.lo set_str.lo set_str_raw.lo set_ui.lo set_z.lo sqrt.lo sqrt_ui.lo sub.lo sub1.lo sub_ui.lo rint.lo ui_div.lo ui_sub.lo urandomb.lo get_z_exp.lo swap.lo factorial.lo cosh.lo sinh.lo tanh.lo acosh.lo asinh.lo atanh.lo atan.lo cmp2.lo exp_2.lo asin.lo const_euler.lo cos.lo sin.lo tan.lo fma.lo fms.lo hypot.lo log1p.lo expm1.lo log2.lo log10.lo ui_pow.lo ui_pow_ui.lo minmax.lo dim.lo copysign.lo gmp_op.lo init2.lo acos.lo sin_cos.lo set_nan.lo set_inf.lo powerof2.lo gamma.lo set_ld.lo get_ld.lo cbrt.lo volatile.lo fits_sshort.lo fits_sint.lo fits_slong.lo fits_ushort.lo fits_uint.lo fits_ulong.lo fits_uintmax.lo fits_intmax.lo get_si.lo get_ui.lo zeta.lo cmp_d.lo erf.lo inits.lo inits2.lo clears.lo sgn.lo check.lo sub1sp.lo version.lo mpn_exp.lo mpfr-gmp.lo mp_clz_tab.lo sum.lo add1sp.lo free_cache.lo si_op.lo cmp_ld.lo set_ui_2exp.lo set_si_2exp.lo set_uj.lo set_sj.lo get_sj.lo get_uj.lo get_z.lo iszero.lo cache.lo sqr.lo int_ceil_log2.lo isqrt.lo strtofr.lo pow_z.lo logging.lo mulders.lo get_f.lo round_p.lo erfc.lo atan2.lo subnormal.lo const_catalan.lo root.lo sec.lo csc.lo cot.lo eint.lo sech.lo csch.lo coth.lo round_near_x.lo constant.lo abort_prec_max.lo stack_interface.lo lngamma.lo zeta_ui.lo set_d64.lo get_d64.lo jn.lo yn.lo remquo.lo -lgmp libtool: link: warning: library `/users/spaces/vlefevre/sparc-solaris/gmp-assert/lib/libgmp.la' was moved. /usr/ccs/bin/ld -64 -G -h libmpfr.so.1 -o .libs/libmpfr.so.1.1.0 .libs/exceptions.o .libs/extract.o .libs/uceil_exp2.o .libs/uceil_log2.o .libs/ufloor_log2.o .libs/add.o .libs/add1.o .libs/add_ui.o .libs/agm.o .libs/clear.o .libs/cmp.o .libs/cmp_abs.o .libs/cmp_si.o .libs/cmp_ui.o .libs/comparisons.o .libs/div_2exp.o .libs/div_2si.o .libs/div_2ui.o .libs/div.o .libs/div_ui.o .libs/dump.o .libs/eq.o .libs/exp10.o .libs/exp2.o .libs/exp3.o .libs/exp.o .libs/frac.o .libs/get_d.o .libs/get_exp.o .libs/get_str.o .libs/init.o .libs/inp_str.o .libs/isinteger.o .libs/isinf.o .libs/isnan.o .libs/isnum.o .libs/const_log2.o .libs/log.o .libs/mul_2exp.o .libs/mul_2si.o .libs/mul_2ui.o .libs/mul.o .libs/mul_ui.o .libs/neg.o .libs/next.o .libs/out_str.o .libs/const_pi.o .libs/pow.o .libs/pow_si.o .libs/pow_ui.o .libs/print_raw.o .libs/print_rnd_mode.o .libs/random2.o .libs/random.o .libs/reldiff.o .libs/round_prec.o .libs/set.o .libs/setmax.o .libs/setmin.o .libs/set_d.o .libs/set_dfl_prec.o .libs/set_exp.o .libs/set_rnd.o .libs/set_f.o .libs/set_prc_raw.o .libs/set_prec.o .libs/set_q.o .libs/set_si.o .libs/set_str.o .libs/set_str_raw.o .libs/set_ui.o .libs/set_z.o .libs/sqrt.o .libs/sqrt_ui.o .libs/sub.o .libs/sub1.o .libs/sub_ui.o .libs/rint.o .libs/ui_div.o .libs/ui_sub.o .libs/urandomb.o .libs/get_z_exp.o .libs/swap.o .libs/factorial.o .libs/cosh.o .libs/sinh.o .libs/tanh.o .libs/acosh.o .libs/asinh.o .libs/atanh.o .libs/atan.o .libs/cmp2.o .libs/exp_2.o .libs/asin.o .libs/const_euler.o .libs/cos.o .libs/sin.o .libs/tan.o .libs/fma.o .libs/fms.o .libs/hypot.o .libs/log1p.o .libs/expm1.o .libs/log2.o .libs/log10.o .libs/ui_pow.o .libs/ui_pow_ui.o .libs/minmax.o .libs/dim.o .libs/copysign.o .libs/gmp_op.o .libs/init2.o .libs/acos.o .libs/sin_cos.o .libs/set_nan.o .libs/set_inf.o .libs/powerof2.o .libs/gamma.o .libs/set_ld.o .libs/get_ld.o .libs/cbrt.o .libs/volatile.o .libs/fits_sshort.o .libs/fits_sint.o .libs/fits_slong.o .libs/fits_ushort.o .libs/fits_uint.o .libs/fits_ulong.o .libs/fits_uintmax.o .libs/fits_intmax.o .libs/get_si.o .libs/get_ui.o .libs/zeta.o .libs/cmp_d.o .libs/erf.o .libs/inits.o .libs/inits2.o .libs/clears.o .libs/sgn.o .libs/check.o .libs/sub1sp.o .libs/version.o .libs/mpn_exp.o .libs/mpfr-gmp.o .libs/mp_clz_tab.o .libs/sum.o .libs/add1sp.o .libs/free_cache.o .libs/si_op.o .libs/cmp_ld.o .libs/set_ui_2exp.o .libs/set_si_2exp.o
Re: dlfcn.h (libtool 1.5.23b)
On Tue, 2007-06-05 at 16:04 -0600, deckrider wrote: On 6/5/07, Peter O'Gorman [EMAIL PROTECTED] wrote: So, why does AC_PROG_CPP set CPP= for you? Not sure, but in the Makefile that was generated, it is this: CPP = cc +DD64 -Wl,+k -E How odd! Could you post the entire config.log (compressed), thanks. Peter ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: version scripts and symbol prefixes
On Wed, 2007-05-30 at 01:32 -0400, Mike Frysinger wrote:
On Tuesday 29 May 2007, Peter O'Gorman wrote:
On Tue, 2007-05-29 at 19:17 -0400, Mike Frysinger wrote:
On Tuesday 29 May 2007, Peter O'Gorman wrote:
On May 29, 2007, at 1:59 AM, Mike Frysinger wrote:
i just came across libupnp which uses some libtool functionality to
generate a
list of exported symbols and pass it to ld so that only the ones
that are
part of the ABI get exported ... however, this code doesnt take
symbol prefixes into account so in my case, the generated library
doesnt include any
global symbols ;(
libupnp is using libtool-1.5.22 but a quick glance at current CVS
head indicates this is still a problem ... can someone correct me ?
i'd just run
a small cpp test and see what __USER_LABEL_PREFIX__ is set to ..
gcc always
defines this and in my case, it's:
#define __USER_LABEL_PREFIX__ _
unless someone has some cool ld/as/string foo to perform a similar
test on
object code ...
What system are you running on?
build = powerpc-linux-gnu
host = bfin-linux-uclibc
Ok, currently libtool checks for that underscore by looking at the
host_os. Using __USER_LABEL_PREFIX__ when building with gcc seems like a
much better plan.
I'll try to make some libtool time this week and come up with a patch
for this. In the meantime, look at libtool.m4 and see how interix and
darwin deal with this issue, maybe you can come up with something that
will work for your host. Look for 's,^,_,' to find it.
actually, i toyed around a little more, and i think there might be a bug in
the existing code ...
in the function AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE, it does a dynamic test
for and _ in order to set global_symbol_pipe properly ... this is
supposed to generate both the raw symbol and the C symbol (which in my case
it works: it detects the raw symbol as _FOO and the C symbol as FOO). btw,
if that loop fails, global_symbol_pipe is set to which causes syntax
errors later ... maybe an early sanity check is needed
however, the code to generate the version script to give to ld takes this
output and only uses the last item in the list (the C symbol) rather than the
first item in the list (the raw symbol). normally this is irrelevant as the
symbols are the same (no symbol prefix), but in my case no good :)
so shouldnt the default export_symbol_cmds be changed from:
_LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience |
$global_symbol_pipe | $SED '\''s/.* //'\'' | sort | uniq $export_symbols'
to (something like):
_LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience |
$global_symbol_pipe | $SED '\'s/[^ ]* \(_[^ ]*\) .*/\1/\'' | sort | uniq
$export_symbols'
or is there more to it ?
also, perhaps a sep topic, but in the case of libupnp (and ive seen a few
others) which use the -export-symbols-regex, perhaps it'd be appropriate to
AC_SUBST() the symbol prefix ? that way, package people can do:
-export-symbols-regex [EMAIL PROTECTED]@ixml.*
and in my case i get:
-export-symbols-regex ^_ixml.*
-mike
A patch like this one should just work, including for
-export-symbols-regex (it does on darwin).
Peter
Index: libtool.m4
===
RCS file: /sources/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.177
diff -u -r1.314.2.177 libtool.m4
--- libtool.m4 28 May 2007 07:03:50 - 1.314.2.177
+++ libtool.m4 30 May 2007 06:33:26 -
@@ -5707,7 +5707,14 @@
if test $supports_anon_versioning = yes; then
_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$echo { global: $output_objdir/$libname.ver~
+case $host in
+bfin-linux*)
+ cat $export_symbols | sed -s s,^,_, -e s/\(.*\)/\1;/ $output_objdir/$libname.ver~
+ ;;
+*)
cat $export_symbols | sed -e s/\(.*\)/\1;/ $output_objdir/$libname.ver~
+ ;;
+esac
$echo local: *; }; $output_objdir/$libname.ver~
$CC '$tmp_sharedflag$tmp_addflag' $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname ${wl}-version-script ${wl}$output_objdir/$libname.ver -o $lib'
fi
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: version scripts and symbol prefixes
On Tue, 2007-05-29 at 19:17 -0400, Mike Frysinger wrote: On Tuesday 29 May 2007, Peter O'Gorman wrote: On May 29, 2007, at 1:59 AM, Mike Frysinger wrote: i just came across libupnp which uses some libtool functionality to generate a list of exported symbols and pass it to ld so that only the ones that are part of the ABI get exported ... however, this code doesnt take symbol prefixes into account so in my case, the generated library doesnt include any global symbols ;( libupnp is using libtool-1.5.22 but a quick glance at current CVS head indicates this is still a problem ... can someone correct me ? i'd just run a small cpp test and see what __USER_LABEL_PREFIX__ is set to .. gcc always defines this and in my case, it's: #define __USER_LABEL_PREFIX__ _ unless someone has some cool ld/as/string foo to perform a similar test on object code ... What system are you running on? build = powerpc-linux-gnu host = bfin-linux-uclibc Ok, currently libtool checks for that underscore by looking at the host_os. Using __USER_LABEL_PREFIX__ when building with gcc seems like a much better plan. I'll try to make some libtool time this week and come up with a patch for this. In the meantime, look at libtool.m4 and see how interix and darwin deal with this issue, maybe you can come up with something that will work for your host. Look for 's,^,_,' to find it. Thanks, Peter ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libtool_osx
On Sat, 2007-05-26 at 04:40 -0700, seth tyler wrote: Hi! I'm new to the terminal and trying to install jpeg-6b on my ibook running osx.3.9 and I tried the ./configure -enable-shared and got the following. seth-tylers-Computer:~/Desktop/jpeg-6b.1 sethtyler$ ./configure checking host system type... ltconfig: cannot guess host type; you I hope this helps with future bug fixes! Hi Seth, The libtool that is included in the jpeg-6b package is really really old. If you want to build it shared, why not look at the patches that others use to build jpeg on OS X. http://trac.macosforge.org/projects/macports/browser/trunk/dports/graphics/jpeg/files or the http://www.finkproject.org patches (they are probably very similar). The latest stable GNU libtool is 1.5.22, but they way that it works means that you will often see older/different/patched versions appearing in packages that you want to build. This particular bug at least is fixed in current libtool :-) Thanks for the report, Peter ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: make check fails on sparc-sun-solaris2.10
On May 10, 2007, at 4:16 PM, Elias Pipping wrote: Hi, I've run libtool's test suite for different versions on a sparc-sun-solaris2.10 machine with these results: $bzgrep -E '(FAIL|tests failed)' *.log.bz2 1.5.23b.log.bz2:FAIL: tagdemo-make.test 1.5.23b.log.bz2:FAIL: tagdemo-make.test 1.5.23b.log.bz2:FAIL: tagdemo-make.test 1.5.23b.log.bz2:3 of 108 tests failed The tagdemo test involves the c++ compiler, I think something is wrong with yours. sparc-sun-solaris2.10 passes tagdemo for me with both gcc and sun studio compilers. Please rerun this test with VERBOSE=1. You only need to use the daily snapshots (updated today after a while of not updating - sorry). Thanks, Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: linking got broken on MacOSX
On May 1, 2007, at 4:43 AM, Christoph Egger wrote: Hello Christoph, * Christoph Egger wrote on Tue, May 01, 2007 at 10:36:29AM CEST: In cvs head, the last change in libltdl/config/ltmain.m4sh broke linking on MacOSX. Darn. Thanks for the report. I want to link against -framework ApplicationServices -framework Cocoa -framework Carbon What I get is this: powerpc-apple-darwin8-gcc-4.0.1: ApplicationServices.ltframework: No such file or directory powerpc-apple-darwin8-gcc-4.0.1: Cocoa.ltframework: No such file or directory powerpc-apple-darwin8-gcc-4.0.1: Carbon.ltframework: No such file or directory When I undo the last changes in libltdl/config/ltmain.m4sh, then linking works. Please post the complete link command line, and all its output, with --debug added, and packed (gzip). Thanks. Attached. Thanks. Ralf, if you don't have a patch handy, I can look into this. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: linking got broken on MacOSX
On May 1, 2007, at 4:14 AM, Ralf Wildenhues wrote: Hello Christoph, * Christoph Egger wrote on Tue, May 01, 2007 at 10:36:29AM CEST: In cvs head, the last change in libltdl/config/ltmain.m4sh broke linking on MacOSX. Darn. Thanks for the report. Ralf, looking at the diff, it may be a typo: - compiler_flags=$compiler_flags $inherited_linker_flags + compiler_flags=$compiler_flags $new_inherited_linker_flags A new_ appeared from nowhere :) At this point, inherited_linker_flags has been adjusted to change the Cocoa.ltframework etc back to -framework Cocoa, but new_inherited_linker_flags has not. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Libtool fails to build working binary when -no-install is used
On Apr 3, 2007, at 4:44 PM, Ralf Wildenhues wrote: Hi Peter, all, * quoting myself: * Simon Josefsson wrote on Thu, Mar 29, 2007 at 12:17:32PM CEST: /bin/sh ../libtool --tag=CC --mode=link gcc -DLIBSSH2_DARWIN -I/ usr/include -I/usr/include -no-install -L/usr/lib -lcrypto -L/usr/ lib -lz -o simple simple.o ../src/libssh2.la mkdir .libs gcc -DLIBSSH2_DARWIN -I/usr/include -I/usr/include -o simple simple.o -L/usr/lib ../src/.libs/libssh2.dylib -lcrypto -lz make check-TESTS dyld: Library not loaded: /usr/local/lib/libssh2.1.dylib Referenced from: /Users/daniel/Desktop/libssh2/tests/./simple Reason: image not found FAIL: simple Looks like a Darwin-related (hint, hint! ;-) bug to me. Do I understand correctly that Darwin has no way to hardcode library paths (other than the ones given by -install-name)? OK to apply and backport? It fixes the stresstest failure exposed by my last patch. Yes. Sorry, I have not been watching the list as closely as I should be. This looks okay to me, please apply. Thanks, Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Libtool fails to build working binary when -no-install is used
On Apr 3, 2007, at 5:16 PM, Simon Josefsson wrote: On 3 apr 2007, at 23.44, Ralf Wildenhues wrote: Do I understand correctly that Darwin has no way to hardcode library paths (other than the ones given by -install-name)? OK to apply and backport? It fixes the stresstest failure exposed by my last patch. After some experiments and a lot of man page reading on my powerbook, I believe this is correct. I was rather surprised to not find anything like -R or -Wl,-rpath on Mac OS X, so it may be that I missed something. Still, this patch is the best we can do without more information from Mac OS X experts. There is no -rpath on Mac OS X 10.4 and earlier, it is, or at least was, I believe, a planned feature for 10.5, but plans and reality don't always intersect... Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libjpeg.la
On Mar 23, 2007, at 1:40 PM, [EMAIL PROTECTED] wrote: Hi, I am installing GDAL1.3.2 and 1.4.0 but here I am getting error as follows.. usr/bin/sed: can't read /usr/lib/libjepg.la: No such file or directory libtool: link: '/usr/lib/libjpeg.la' is not a valid libtool archive make[1]: *** [libgdal.la] Error 1 make[1]: Leaving directory '/usr/lib/gdal/gdal-cvs-2006.05.18' make: *** [check-lib] Error 2 You need to install the -dev or -devel package that provides you with /usr/lib/libjpeg.la, possibly libjpeg-dev? The name of the package depends on your distribution. Hope this helps, Peter ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libtool-1.15.23b (i386-unknown-freebsd4.3) check results
On Feb 22, 2007, at 8:38 AM, David Fang wrote: Hi again, Here are my results for libtool-1.15.23b on i386-unknown-freebsd4.3 (most PASSes omitted): Hi David, Hmm, all tests pass for me with i386-unknown-freebsd4.8. Please rerun the failing tests with VERBOSE=1 e,g: env VERBOSE=1 TESTS='hardcode.test pdemo-conf.test pdemo-make.test tagdemo-conf.test tagdemo-make.test tagdemo-exec.test \ gmake check And post the results. Thanks, Peter ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [GNU Autoconf 2.60] testsuite: 3 120 failed
[cutting autoconf-patches list] On Feb 11, 2007, at 6:33 PM, Ralf Wildenhues wrote: OK to apply? + +# Cheap backport of AS_EXECUTABLE_P and required macros +# from Autoconf 2.59; we should not use $as_executable_p directly. + +# _AS_TEST_PREPARE +# +m4_ifndef([_AS_TEST_PREPARE], +[m4_defun([_AS_TEST_PREPARE], +[as_executable_p=test -f Hi Ralf, Could we test if test -x works and use that? I know that this is barely used, but it bugs me that test -f does not test for the executable bit :) I think autoconf has this: if test -x / /dev/null 21; then as_executable_p='test -x' else as_executable_p='test -f' fi Peter ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: tries to link to 32-bit libs on 64-bit build
On Feb 6, 2007, at 11:38 PM, Paul Raines wrote: I am trying to build libgnomedb from RPM on a 64-bit box. It dies as follows: /bin/sh ../libtool --tag=CC --mode=link gcc -O2 -g -pipe -m64 -o libgnomedb-2.la -rpath /usr/lib64 -version-info 4:0:0 db-shell.lo sql-viewer.lo table-properties-dialog.lo tables-page.lo utils.lo gnome-db-combo.lo gnome-db-connection-properties.lo gnome-db- connection-selector.lo gnome-db-dsn-config.lo gnome-db-error.lo gnome-db-error-dialog.lo gnome-db-form.lo gnome-db-gray-bar.lo gnome-db-grid.lo gnome-db-find-dialog.lo gnome-db-init.lo gnome-db- list.lo gnome-db-model.lo gnome-db-provider-selector.lo gnome-db- query-builder.lo gnome-db-report-editor.lo gnome-db-stock.lo gnome- db-table-editor.lo gnome-db-util.lo gnome-db-browser.lo gnome-db- browser-procedures.lo gnome-db-browser-tables.lo gnome-db-browser- types.lo gnome-db-browser-views.lo gnome-db-config.lo gnome-db- control.lo gnome-db-control-widget.lo gnome-db-data-source- selector.lo gnome-db-dsn-config-druid.lo gnome-db-editor.lo gnome- db-icon-list.lo gnome-db-login.lo gnome-db-login-dialog.lo gnome-db- window.lo -Wl,--export-dynamic -lgtk-x11-2.0 -lgdk-x11-2.0 - latk-1.0 -lgdk_pixbuf-2.0 -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 - lgobject-2.0 -lgmodule-2.0 -ldl -lgda-2 -lglib-2.0 -lxslt -lxml2 - lpthread -lz -lm-Wl,--export-dynamic -lglade-2.0 -lgtk-x11-2.0 - lxml2 -lpthread -lz -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm - lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 - ldl -lglib-2.0 -Wl,--export-dynamic -pthread -L/usr/X11R6/lib64 - lgnomeui-2 -lSM -lICE -lbonoboui-2 -lxml2 -lpthread -lz - lgnomecanvas-2 -lgnome-2 -lpopt -lart_lgpl_2 -lpangoft2-1.0 -lgtk- x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangoxft-1.0 - lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lbonobo-2 -lgconf-2 - lgnomevfs-2 -lbonobo-activation -lORBit-2 -lm -lgmodule-2.0 -ldl - lgthread-2.0 -lglib-2.0 gcc -shared .libs/db-shell.o .libs/sql-viewer.o .libs/table- properties-dialog.o .libs/tables-page.o .libs/utils.o .libs/gnome- db-combo.o .libs/gnome-db-connection-properties.o .libs/gnome-db- connection-selector.o .libs/gnome-db-dsn-config.o .libs/gnome-db- error.o .libs/gnome-db-error-dialog.o .libs/gnome-db-form.o .libs/ gnome-db-gray-bar.o .libs/gnome-db-grid.o .libs/gnome-db-find- dialog.o .libs/gnome-db-init.o .libs/gnome-db-list.o .libs/gnome-db- model.o .libs/gnome-db-provider-selector.o .libs/gnome-db-query- builder.o .libs/gnome-db-report-editor.o .libs/gnome-db- stock.o .libs/gnome-db-table-editor.o .libs/gnome-db-util.o .libs/ gnome-db-browser.o .libs/gnome-db-browser-procedures.o .libs/gnome- db-browser-tables.o .libs/gnome-db-browser-types.o .libs/gnome-db- browser-views.o .libs/gnome-db-config.o .libs/gnome-db- control.o .libs/gnome-db-control-widget.o .libs/gnome-db-data- source-selector.o .libs/gnome-db-dsn-config-druid.o .libs/gnome-db- editor.o .libs/gnome-db-icon-list.o .libs/gnome-db-login.o .libs/ gnome-db-login-dialog.o .libs/gnome-db-window.o -lgda-2 -lxslt - lglade-2.0 -pthread -L/usr/X11R6/lib64 -lgnomeui-2 -lSM -lICE - lbonoboui-2 -lxml2 -lpthread -lz -lgnomecanvas-2 -lgnome-2 /usr/lib/ libpopt.so -lart_lgpl_2 -lpangoft2-1.0 -lgtk-x11-2.0 -lgdk-x11-2.0 - latk-1.0 -lgdk_pixbuf-2.0 -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 - lgobject-2.0 -lbonobo-2 -lgconf-2 -lgnomevfs-2 -lbonobo-activation - lORBit-2 -lm -lgmodule-2.0 -ldl -lgthread-2.0 -lglib-2.0 -m64 - Wl,--export-dynamic -Wl,--export-dynamic -Wl,--export-dynamic -Wl,- soname -Wl,libgnomedb-2.so.4 -o .libs/libgnomedb-2.so.4.0.0 /usr/lib/libpopt.so: could not read symbols: File in wrong format Why despite the fact that there is -rpath /usr/lib64 there and there is a perfectly valid /usr/lib64/libpopt.o is libtool resolving to use /usr/lib/libpopt.so? Please reconfirm this bug using a snapshot of libtool, see http:// www.gnu.org/software/libtool for a link to the snapshots. You will have to relibtoolize the source to test. You should also probably complain to whoever provided you with the rpm. Peter ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: tries to link to 32-bit libs on 64-bit build
On Feb 7, 2007, at 12:52 AM, Paul Raines wrote: I took a guess and got the RPM to build by putting in a export LDFLAGS=-L/usr/lib64 before the configure line in the RPM spec file. That seems to have worked as it got a -L/usr/lib64 into the below. But I still don't understand why libtool would need such direction as it should be able to tell it is building on a 64bit box and there are no explict cross complitation flags. Anyway, I am building on RHEL4 with the latest libtool-1.5.6-4.EL4.1 and in general like to stick with the official RPMS RHEL4 does not have libgnomedb so that RPM comes from Fedora Core 4 Extras I think that this bug is fixed in our cvs which is why I asked you to try a snapshot. Anyway, glad you got it working. Peter ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem
On Sep 21, 2006, at 5:43 AM, Kate Minola wrote: To followup on my previous post on this subject, I propose that in libtool.m4 in the macro AC_LIBTOOL_SYS_DYNAMIC_LINKER the line Hi Kate, I just applied a patch that I believe fixes your issue. http://lists.gnu.org/archive/html/libtool-patches/2006-10/ msg8.html If you wait ~24 hours, you can download the daily snapshot http:// www.gnu.org/software/libtool to verify it is fixed. Sorry it took me so long to get around to it. Peter ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem
On Sep 15, 2006, at 1:08 AM, Ralf Wildenhues wrote:
Hi Ralf,
Okay, I don't think my solution solves anything :/. My gcc compiler
in /opt/gcc-4.0.1 only passes -L flags for /opt/gcc-4.0.1/lib/gcc/
powerpc-apple-darwin8.2.0/4.0.1 and /opt/gcc-4.0.1/lib, but -print-
search-dirs also includes /usr/lib and /lib etc.
You may want to read this:
http://lists.gnu.org/archive/html/libtool-patches/2005-01/
msg00181.html
and then decide whether to ignore it or not. If yes, then that should
be documented.
(I think the reverse downside was that gcc would not list search dirs
that don't exist at the time; but I haven't tested it either and can't
find a reference to this now.)
While looking into a patch for this, I notice that
sys_lib_search_path_spec is not a tagged var, so we run it for each
compiler for each tag, with the latest one it finds being the final
answer. Does not seem quite right to me.
Good catch. Probably doing this for the C compiler only should be
enough.
Also we seem to use $AWK in libtool.m4 (and substituted into libtool)
without setting it anywhere when $lt_cv_nm_interface = MS dumpbin
I also came up with the awk expression from hell :-)
Here is what should be a readable portable awk expression from hell,
but I need to return to square 1 for an actual problem solution.
Peter
awk '
BEGIN {RS= ; FS=/; } /-L\// {
foo=;
for (i = NF; i 0; i--) {
if ($i != $i != . $i != -L $i != \n) {
if ($i == ..) { count++ }
else if (count == 0) {
if (foo == ) { foo=$i }
else { foo=$i / foo }
}
else { count-- }
}
else if ($i == -L) { foo=/ foo }
}
if (foo != ) { freq[foo]++ }
if (freq[foo] == 1) { print foo }
}'
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem
On Sep 13, 2006, at 11:34 PM, Bob Friesenhahn wrote:
On Wed, 13 Sep 2006, Kate Minola wrote:
On my x86_64-unknown-linux-gnu system, the m4 macro
AC_LIBTOOL_SYS_DYNAMIC_LINKER in libtool.m4
uses gcc -print-search-dirs to set sys_lib_search_path_spec.
Unfortunately, -print-search-dirs lists -m32 library directories,
but gcc is in (default) -m64 mode on my system. Consequently libtool
tries to link with the wrong library (32 bit when it should be
using 64 bit).
The particular error message I get is
I think that this is really a GCC bug. I have the same problem
under Solaris. Libtool should work around the GCC bug by detecting
64-bit compilation and expanding the search path to look in the 64-
bit library directories first.
Hi Bob,
As far as I'm aware there is not going to be a fix for this in gcc,
so yes, we need to fix it.
Perhaps something like:
echo int main(){return 0;} conftest.c
search_path=`$CC $CFLAGS -c conftest.c 21 | awk 'BEGIN {RS= } /^
[\]?-L/ {sub (-L,);print $0};'`
rm -f conftest.c conftest.o
Peter
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem
On Sep 13, 2006, at 11:41 PM, Peter O'Gorman wrote:
On Sep 13, 2006, at 11:34 PM, Bob Friesenhahn wrote:
On Wed, 13 Sep 2006, Kate Minola wrote:
On my x86_64-unknown-linux-gnu system, the m4 macro
AC_LIBTOOL_SYS_DYNAMIC_LINKER in libtool.m4
uses gcc -print-search-dirs to set sys_lib_search_path_spec.
Unfortunately, -print-search-dirs lists -m32 library directories,
but gcc is in (default) -m64 mode on my system. Consequently
libtool
tries to link with the wrong library (32 bit when it should be
using 64 bit).
The particular error message I get is
I think that this is really a GCC bug. I have the same problem
under Solaris. Libtool should work around the GCC bug by
detecting 64-bit compilation and expanding the search path to look
in the 64-bit library directories first.
Hi Bob,
As far as I'm aware there is not going to be a fix for this in gcc,
so yes, we need to fix it.
Perhaps something like:
echo int main(){return 0;} conftest.c
search_path=`$CC $CFLAGS -c conftest.c 21 | awk 'BEGIN {RS= } /^
[\]?-L/ {sub (-L,);print $0};'`
rm -f conftest.c conftest.o
I really should try things before sending mail :)
gcc -v -o conftest conftest.c 21 | awk 'BEGIN {RS= } /^[\]?-L/
{sub (-L,); print $0};'
Peter
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem
On Sep 13, 2006, at 11:49 PM, Ralf Wildenhues wrote: Only as a last resort, if you ask me. Other compilers love to disguise as gcc, and Autoconf's AC_FC_LIBRARY_LDFLAGS is witness of how helplessly maintenance-intensive an approach like the above is. That's looking at all kinds of flags, in this case we're only interested in -L. Peter ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem
On Sep 14, 2006, at 12:12 AM, Ralf Wildenhues wrote: * Peter O'Gorman wrote on Wed, Sep 13, 2006 at 04:55:11PM CEST: On Sep 13, 2006, at 11:49 PM, Ralf Wildenhues wrote: Only as a last resort, if you ask me. Other compilers love to disguise as gcc, and Autoconf's AC_FC_LIBRARY_LDFLAGS is witness of how helplessly maintenance-intensive an approach like the above is. That's looking at all kinds of flags, in this case we're only interested in -L. Alright, feel free to give it a shot. From the Autoconf macro we know that -LANG:=* | -LIST:* | -LNO:* should be ignored, for pathscale and some other compilers I have forgotten now. Otherwise your awk script seems to work with PGI, Intel, and PathScale. I don't think we need to worry about that as the test is specific to gcc. However I'll think about it more tomorrow when I hack at it, bedtime here now :) Peter ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: --whole-archive doesn't work on OSX
On Aug 3, 2006, at 10:01 AM, Andrew Miller wrote: Peter O'Gorman wrote: On Aug 2, 2006, at 10:24 AM, Andrew Miller wrote: Hi, I have just posted a bug regarding libtool on OSX to http:// savannah.gnu.org/support/index.php?func=detailitemitem_id=105489 I'm not sure if that is the right place to post bugs, so in case it isn't, here is the text of the report: This bug tested on: Darwin bioeng21.bioeng.auckland.ac.nz 8.7.0 Darwin Kernel Version 8.7.0: Fri May 26 15:20:53 PDT 2006; root:xnu-792.6.76.obj~1/ RELEASE_PPC Power Macintosh powerpc It seems that recent versions of libtool don't support the -- whole-archive on MacOSX. This causes the --whole-archive flag to be passed to gcc (which seems to be silently ignored on OSX), resulting in a link which doesn't really contain the whole archive. For example: --whole-archive is not a libtool flag, where do you see documentation that states you can pass --whole-archive to libtool? After looking into this, I couldn't find anywhere, so I guess it just ended up in my tree from before libtool was used. However, the documentation seems to imply that the behaviour of whole-archive should happen on all platforms, for all convenience libraries. e.g. — Variable: *whole_archive_flag_spec* Compiler flag to generate shared objects from convenience archives. If whole_archive_flag_spec is empty, as it is on darwin for more recent versions of libtool then the convenience archive will be unpacked using lipo/ar and the objects will be added to the link line. Peter ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: 3 failed tests?
On Jul 28, 2006, at 12:49 AM, Jon Handler wrote: Hello, I ended up getting 3 failed tests, all being the same test, depdemo-inst.test. Im running off of Mac OS X 10.4.7, using the bash shell. Also it gave me this right under your email. make[2]: *** [check-TESTS] Error 1 make[1]: *** [check-am] Error 2 make: *** [check-recursive] Error 1 I hope this helps. Hi Jon, Actually, it would be much more interesting to see which tests failed and why. Could you run make check again with VERBOSE=1 e.g. env VERBOSE=1 make check TESTS=depdemo-conf depdemo-make depdemo-inst And post the results here (compressed if large). Also please include the libtool version and xcode version. Thanks, Peter ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libtool 1.5.22 tests failed
On Wed, 2006-07-12 at 11:50 -0600, Stephen Cartwright wrote: Here you go! Thank you, since the post was too big for the list, I rejected it. Here (for the list) is the failure: cc -DPACKAGE_NAME=\mdemo\ -DPACKAGE_TARNAME=\mdemo\ -DPACKAGE_VERSION=\0.1\ -DPACKAGE_STRING=\mdemo 0.1\ -DPACKAGE_BUGREPORT=\[EMAIL PROTECTED] -DPACKAGE=\mdemo\ -DVERSION=\0.1\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_MATH_H=1 -I. -I. -I./../libltdl -g -c mlib.c -o mlib.o cc: Error: mlib.c, line 31: In this declaration, lt_dlinfo appears to be used as if it named a type, but there is no declared type of that name visible. (typedefnotdef) const lt_dlinfo *info; ^ cc: Error: mlib.c, line 45: In this statement, info is not declared. (undeclared) info = lt_dlgetinfo(handle); --^ *** Exit 1 all failures are variants of this. Peter signature.asc Description: This is a digitally signed message part ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libtool 1.5.22 tests failed
On Mon, 2006-07-10 at 15:47 -0600, Stephen Cartwright wrote: Hello, I tried to make the latest version of libtool in order to try to get automake to work. However these tests failed when I did a make check. This is on an alpha/Tru65 5.1B box. PASS: mdemo-conf.test FAIL: mdemo-make.test SKIP: mdemo-exec.test SKIP: mdemo-inst.test PASS: mdemo-unst.test FAIL: dryrun.test Please run these tests in verbose mode and post the results: env VERBOSE=1 TESTS=mdemo-conf.test mdemo-make.test dryrun.test \ make check Thanks, Peter signature.asc Description: This is a digitally signed message part ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libtool uses incorrect module extension (.so instead of .dylib) under Darwin
On Tue, 2006-03-21 at 21:24 +0900, Peter O'Gorman wrote: On Mon, 2006-03-20 at 21:56 +0100, Vincent Lefevre wrote: and this breaks GTK applications under Mac OS X. This is a bug with the glib2 package, either upstream or darwinports. The correct extension for loadable bundles on darwin is .so, for libraries that can be used as input to ld(1) it is .dylib. Already fixed upstream: http://bugzilla.gnome.org/show_bug.cgi?id=322476 Peter signature.asc Description: This is a digitally signed message part ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: darwin: mix up of .dylib and .bundle
Christoph Egger wrote: Attached. libgii-debug-experimental.output.gz is the whole subdirectory as I sent in my last mail with debug info. libgii-debug-experimental.output2.gz is the failing libtool link line with debug info. Doh! In a directory named ggbundle, file -L /path/to/with/ggbundle/in/it | grep bundle will return true! Let me look into a patch, probably testing for 'Mach-O bundle' is better than testing for 'bundle'. | P.S.: How about integrating libtest into libtool's testsuite? | It might uncover bugs on many other operating systems | (win32, linux, *bsd, solaris, aix, etc.) If you send a patch for head, using the new testsuite and fill out the fsf copyright assignment forms, sure :-). hmm... I should subscribe an NDA ? No, it is not an NDA, the FSF requires that it get copyright for all changes that are non-trivial. So for something like your test case you'd have to complete a copyright assignment. http://www.gnu.org/software/libtool/contribute.html Thanks for this report, Peter ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Running ranlib after installation - okay or not?
Ralf Wildenhues wrote: Should that be: old_postinstall_cmds=$old_postinstall_cmds~\$RANLIB \$oldlib ?? Yes, I believe so (both CVS HEAD and branch-1-5). Unless there exists ranlib's that change file mode.. Okay, the attached pathces are applied to libtool HEAD and branch-1-5. Thank you, Peter 2005-09-01 Peter O'Gorman [EMAIL PROTECTED] * libltdl/m4/libtool.m4 (old_postintall_cmds): chmod 644 before running ranlib. Reported by Gerald Pfeifer [EMAIL PROTECTED] Index: libltdl/m4/libtool.m4 === RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v retrieving revision 1.10 diff -u -3 -p -u -r1.10 libtool.m4 --- libltdl/m4/libtool.m4 1 Sep 2005 14:16:08 - 1.10 +++ libltdl/m4/libtool.m4 1 Sep 2005 16:03:08 - @@ -1200,10 +1200,10 @@ old_postuninstall_cmds= if test -n $RANLIB; then case $host_os in openbsd*) -old_postinstall_cmds=\$RANLIB -t \$oldlib~$old_postinstall_cmds +old_postinstall_cmds=$old_postinstall_cmds~\$RANLIB -t \$oldlib ;; *) -old_postinstall_cmds=\$RANLIB \$oldlib~$old_postinstall_cmds +old_postinstall_cmds=$old_postinstall_cmds~\$RANLIB \$oldlib ;; esac old_archive_cmds=$old_archive_cmds~\$RANLIB \$oldlib 2005-09-01 Peter O'Gorman [EMAIL PROTECTED] * libtool.m4 (old_postintall_cmds): chmod 644 before running ranlib. Reported by Gerald Pfeifer [EMAIL PROTECTED] Index: libtool.m4 === RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v retrieving revision 1.314.2.105 diff -u -3 -p -u -r1.314.2.105 libtool.m4 --- libtool.m4 31 Aug 2005 18:29:21 - 1.314.2.105 +++ libtool.m4 1 Sep 2005 16:04:15 - @@ -176,10 +176,10 @@ old_postuninstall_cmds= if test -n $RANLIB; then case $host_os in openbsd*) -old_postinstall_cmds=\$RANLIB -t \$oldlib~$old_postinstall_cmds +old_postinstall_cmds=$old_postinstall_cmds~\$RANLIB -t \$oldlib ;; *) -old_postinstall_cmds=\$RANLIB \$oldlib~$old_postinstall_cmds +old_postinstall_cmds=$old_postinstall_cmds~\$RANLIB \$oldlib ;; esac old_archive_cmds=$old_archive_cmds~\$RANLIB \$oldlib ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Running ranlib after installation - okay or not?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter O'Gorman wrote: | The problem is that libtool tries to run ranlib after install and that | ranlib can fail if the library is not writable? [crosspost - beware - for context see http://gcc.gnu.org/ml/gcc/2005-08/msg00937.html] When I look more closely at this, I see in libtool.m4: old_postinstall_cmds='chmod 644 $oldlib' and a little later: old_postinstall_cmds=\$RANLIB \$oldlib~$old_postinstall_cmds Should that be: old_postinstall_cmds=$old_postinstall_cmds~\$RANLIB \$oldlib ?? Peter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQxaND7iDAg3OZTLPAQIenwQAw+FtzccBDNnixZdjK8gdI0Zaxu3xpX0D 9jPOkhPZaGMshTHF77W7h2ZxLmqmNwvWTlGjHCnwZXBuY3nW2Lms+ow0AZ9V+eP3 ADFRfvmlnkmkxl/pDiLKYPyCfJucuae1mAF8DMmWHN6gS3AknP0n4imybOp3GULd FbSpIRKclJ0= =COg3 -END PGP SIGNATURE- ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.1a] testsuite: 5 15 failed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Oxenreider wrote:
|5: inherited_flags.at:20 inherited_linker_flags
| 15: stresstest.at:25 Link option thorough search test
This patch, applied as obvious, should, I hope, fix the inherited linker
flags test.
Peter
- --
Peter O'Gorman - http://www.pogma.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)
iQCVAwUBQsaorriDAg3OZTLPAQIexwP9F5ugU1Y8UmsfY1TB4pGmJsX4TPBjRdbp
m3bHIh2MWf5fxYL1MkD9gjmPWHhFGsnx2n0j7RDbZrXV7OeHcPigDTOfrPxnmetO
Fy2D2tyBgZDHMj858fQnnV1dFVPzriDhkln32ocvXjqNUQdTh3JKU8yypZbEHvgv
OekXKpgg5jc=
=A/tg
-END PGP SIGNATURE-
Index: ChangeLog
2005-07-02 Peter O'Gorman [EMAIL PROTECTED]
* tests/inherited_flags.at: Use -no-undefined.
Reported by Chris Oxenreider [EMAIL PROTECTED]
from Ralf Wildenhues [EMAIL PROTECTED]
Index: tests/inherited_flags.at
===
RCS file: /cvsroot/libtool/libtool/tests/inherited_flags.at,v
retrieving revision 1.3
diff -u -3 -p -u -r1.3 inherited_flags.at
--- tests/inherited_flags.at 27 Apr 2005 18:18:10 - 1.3
+++ tests/inherited_flags.at 2 Jul 2005 14:42:50 -
@@ -43,8 +43,8 @@ ${LIBTOOL} --mode=compile --tag=CC $CC $
${LIBTOOL} --mode=compile --tag=CC $CC $CFLAGS -c -o bar.lo bar.c
${LIBTOOL} --mode=compile --tag=CC $CC $CFLAGS -c -o baz.lo baz.c
${LIBTOOL} --mode=compile --tag=CC $CC $CFLAGS -c -o main.lo main.c
-${LIBTOOL} --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o libfoo.la foo.lo
-rpath /usr/local/lib
-${LIBTOOL} --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o libbar.la bar.lo
-rpath /usr/local/lib
+${LIBTOOL} --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o libfoo.la foo.lo
-rpath /usr/local/lib -no-undefined
+${LIBTOOL} --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o libbar.la bar.lo
-rpath /usr/local/lib -no-undefined
mv libfoo.la libfoo.la.bak
@@ -55,7 +55,7 @@ mv libbar.la libbar.la.bak
sed -e
's/^inherited_linker_flags.*/inherited_linker_flags=-llt_unlikely_existing_lib/g'
libbar.la.bak libbar.la
rm libbar.la.bak
-AT_CHECK([${LIBTOOL} --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o libbaz.la
baz.lo -rpath /usr/local/lib ./libfoo.la ./libbar.la | grep
'llt_[[ui]]nlikely_existing_lib.*llt_[[ui]]nlikely_existing_lib'],[0],[ignore],[ignore])
-AT_CHECK([${LIBTOOL} --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o main main.lo
-rpath /usr/local/lib ./libfoo.la ./libbar.la | grep
'llt_[[ui]]nlikely_existing_lib.*llt_[[ui]]nlikely_existing_lib'],[0],[ignore],[ignore])
+AT_CHECK([${LIBTOOL} --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o libbaz.la
baz.lo -no-undefined -rpath /usr/local/lib ./libfoo.la ./libbar.la | grep
'llt_[[ui]]nlikely_existing_lib.*llt_[[ui]]nlikely_existing_lib'],[0],[ignore],[ignore])
+AT_CHECK([${LIBTOOL} --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o main main.lo
-no-undefined -rpath /usr/local/lib ./libfoo.la ./libbar.la | grep
'llt_[[ui]]nlikely_existing_lib.*llt_[[ui]]nlikely_existing_lib'],[0],[ignore],[ignore])
AT_CLEANUP
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Handling object name conflicts
Ralf Wildenhues wrote: Hi Peter, * Peter O'Gorman wrote on Sat, May 28, 2005 at 05:56:03PM CEST: Ralf Wildenhues wrote: What happens instead with your patch applied (sorry for not checking myself)? Attached is a gnuradio build snippit. Also passes all tests. That looks fine, yes. Thanks! I just applied this patch to all branches. Peter -- Peter O'Gorman - http://www.pogma.com Index: ChangeLog 2004-05-31 Peter O'Gorman [EMAIL PROTECTED] * ltmain.in: Do not add installed static litool libraries to convenience, they are not convenience libraries. Reported by Chen-Mou Cheng [EMAIL PROTECTED] from Ralf Wildenhues [EMAIL PROTECTED] Index: ltmain.in === RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v retrieving revision 1.334.2.69 diff -u -3 -p -u -r1.334.2.69 ltmain.in --- ltmain.in 4 May 2005 13:52:10 - 1.334.2.69 +++ ltmain.in 31 May 2005 03:46:21 - @@ -2729,8 +2729,6 @@ EOF fi fi else - convenience=$convenience $dir/$old_library - old_convenience=$old_convenience $dir/$old_library deplibs=$dir/$old_library $deplibs link_static=yes fi ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Handling object name conflicts
Chen-Mou Cheng wrote: Yes it happens with released version as well. Can you confirm that the attached patch to ltmain.sh fixes this issue for you? Thanks, Peter -- Peter O'Gorman - http://www.pogma.com --- ltmain.sh~ Mon May 16 18:39:29 2005 +++ ltmain.sh Sat May 28 07:38:05 2005 @@ -2729,8 +2729,6 @@ fi fi else - convenience=$convenience $dir/$old_library - old_convenience=$old_convenience $dir/$old_library deplibs=$dir/$old_library $deplibs link_static=yes fi ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libtool fails without a CXX compiler installed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter O'Gorman wrote: | Eric Sandall wrote: | | Quoting Bob Friesenhahn [EMAIL PROTECTED]: | | snip | | | | The problems I have heard about up until now have been that autoconf | | found a C++ compiler, but it was discovered not to work. In this | | case, autoconf's macro throws up its hands and spontaneously quits. | | | | So libtool is not working if there is no C++ at all? | | I fixed this once: | 2004-08-12 | | ~* configure.ac, libtool.m4: Ensure that a c++ compiler exists | before | ~checking for the c++ preprocessor. Apparently reported by multiple | ~people, multiple times. | | I guess it got rebroken :( Replying to myself... it is still fixed. Please use a newer libtool. http://www.opendarwin.org/~pogma/lt_no_cxx.txt Peter - -- Peter O'Gorman - http://www.pogma.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQpPXUbiDAg3OZTLPAQIeaQP/au0siqKUxqL3u26BAl344862COGcV0yh k1OZZ6ciBJKDpgfgs/dyl/Tykuu1eNABQcWlL7psJ2VjTxSdyYHb2PT25a9Sff53 K2c8X91TRd4+w0GlG5lnTIevUOQFNMYT79Cn7lmSik3umqOhuwjhdbfV1QlrjD5x sDUbEB6GB1E= =6Jvl -END PGP SIGNATURE- ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libtool fails without a CXX compiler installed
Eric Sandall wrote: Quoting Peter O'Gorman [EMAIL PROTECTED]: snip Replying to myself... it is still fixed. Please use a newer libtool. http://www.opendarwin.org/~pogma/lt_no_cxx.txt I was using 1.5.16, will try 1.5.18, thanks. :) Was also fixed in 1.5.16. If your configure script is calling AC_PROG_CXX then you will have to use a similar workaround to libtool: pushdef([AC_MSG_ERROR], [CXX=no]) AC_PROG_CXX popdef([AC_MSG_ERROR]) AM_CONDITIONAL(HAVE_CXX, [test -n $CXX ( test X$CXX != Xno ( (test X$CXX = Xg++ `g++ -v /dev/null 21` ) || (test X$CXX != Xg++)))]) Note that all the tests are not really necessary, but... I was paranoid. Horrible, isn't it? Peter -- Peter O'Gorman - http://www.pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [rth@redhat.com: libjava build times]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Wildenhues wrote: | I'm pretty sure I can get it quite a bit faster even. The patches need | cleanup so that they use allowed file names and work properly in corner | cases as well, but those don't scale with the number of objects, so they | matter less. | + $ECHO $oldobjs | $SP2NL | $SED -n -e '/./p' _objs Ralf, you really rock! I do worry about this echo though. How big is $oldobjs? Will we exceed the max_cmd_len if echo is an external program? Peter - -- Peter O'Gorman - http://www.pogma.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQnoN67iDAg3OZTLPAQKGAgP/dqzSt23v4QA/90LDmCrIoGdSpHsLilj/ ffrjmDHEVhRwHySb1YCnO7YsXwvGnXyKfNAxCHB3GsD1LQjIIkrVtX3gx/Vr7y1W gJ03CggYBpNn8ft4DVPFcigduJ4aTHne8+ND0oBPVLpiYrO7UFJcNlzHGVnLaTLG zctQUdZrgac= =5dvv -END PGP SIGNATURE- ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libtool 1.5.14 eats -framework option on Darwin/MacOSX
Adam wrote: | Greetings, | | There is a problem when using libtool (1.5.14) on Darwin/MacOSX. | Then compiling programs, the -framework options is not passed to the | compiler. | For example: | /usr/pkg/bin/libtool --mode=link cc -framework CoreAudio -o x x.c | Results in: | cc -o x x.c | | Please, advice. Use -Wl, or -Xlinker or libtool-1.5.16. Peter - -- Peter O'Gorman - http://www.pogma.com Peter, libtool-1.5.16 still has the same bug Well aren't I stupid, I did not notice that you specified *program* and I tried linking a library and it got passed through happily enough. I applied this patch to branch-1-5. Peter -- Peter O'Gorman - http://www.pogma.com Index: ChangeLog 2005-05-04 Peter O'Gorman [EMAIL PROTECTED] * ltmain.in [darwin]: Pass -framework for executables too. Reported by Adam [EMAIL PROTECTED] from Andreas Schwab [EMAIL PROTECTED] Index: ltmain.in === RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v retrieving revision 1.334.2.68 diff -u -3 -p -u -r1.334.2.68 ltmain.in --- ltmain.in 22 Apr 2005 09:05:41 - 1.334.2.68 +++ ltmain.in 4 May 2005 13:50:49 - @@ -1357,6 +1357,8 @@ EOF ;; darwin_framework) compiler_flags=$compiler_flags $arg + compile_command=$compile_command $arg + finalize_command=$finalize_command $arg prev= continue ;; @@ -1421,6 +1423,8 @@ EOF -framework) prev=darwin_framework compiler_flags=$compiler_flags $arg + compile_command=$compile_command $arg + finalize_command=$finalize_command $arg continue ;; ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Small fix for 1.5.16 to turn off installation on default
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dalibor Topic wrote: | | Ralf, thank you very much for taking care of libtool's 1.5 branch and | pushing regular releases out with the team. [1] Would a 1.5.18/1.5.16.1 | with just that single fix be faster to get out, by chance? | | cheers, | dalibor topic | | [1] /me waves to pogma I'll wave back, but there is little chance of me having free time enough to do a release until mother-in-law leaves (i.e. mid-May). Anyway, Ralf is better :) Peter - -- Peter O'Gorman - http://www.pogma.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQnJND7iDAg3OZTLPAQJdZAP+Ibpo/dGUgl6KwSpg5o7lbX36tPjwKB69 g/OfFh7CIMDQSoMZq+xKkHwPSeMK8tPcMM7XrZnMQdkLuvS9Wdonr1aokcO6BRNw 2OcNlWBLD7EDY30JwVixPdM2OgG1GI6FpZYkMCsEGfbIWF4Gu9wBnoa+PpCUdS7w p6Hjbr5lONs= =+lNy -END PGP SIGNATURE- ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
