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: mode=execute argument munging bug
Ralf Wildenhues wrote: * Roberto Bagnara wrote on Wed, Mar 05, 2008 at 07:37:58AM CET: It is better now, but there is still the problem that, apparently, libtool redirects stdin for the program it is running. Gosh. How embarrassing. I've applied this patch. Dear Ralf, everything seems to work for us now. Thanks! Roberto P.S. I will look at the testsuite failure during the weekend. -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED] ___ 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]
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 must admit that I don't yet know why this doesn't work for Nelson's system, though. 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. As I said before, I know several setups where this kind of thing does work (as long as your patch is not applied). Cheers, Ralf ___ 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]
On Fri, 7 Mar 2008, Ralf Wildenhues wrote: 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. You may recall that mixing tools was not working for me under Solaris 10 so I have fortran variables (F77 FC) set to 'no' in config.site so that they won't be used in the libtool tests. At the time I thought that perhaps this was due to a lacking libtool feature rather than a 'bug'. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ 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: 34 failed
On Sat, Mar 08, 2008 at 08:27:38AM +0100, Roberto Bagnara wrote: Ralf Wildenhues wrote: I can reproduce this error under the following circumstances: A libltdl 2.1 or newer has previously been installed in a place where the preprocessor and the link editor can find headers resp. library (suitable CPPFLAGS=-I... and LDFLAGS=-L... count, too), but the libltdl.la file is missing in the installation, and also the runtime linker does not search the installed location of libltdl.so.7 by default (and -R.../-Wl,-rpath,... have not been added). Does that match your setup? If yes, who removed the installed libltdl.la file, and why? yes, I believe this matches my setup. I had installed Libtool 2.1.b; nothing worked for me so, since I had no time to investigate further, I uninstalled it (not the proper way, I guess) and went back to Libtool 1.5.24. But if you used make uninstall, then there should be no traces left. What I instead meant was: the installed libltdl.la file is missing, but the libltdl.so.7 file is still present, as is the ltdl.h header in the include directory. Does that still match your setup? Also, are things working for you with 2.3a now? Thanks, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
