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
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
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]
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
