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 [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 18 19 64 failed [Solaris 7 SPARC]
* Bob Friesenhahn wrote on Fri, Mar 07, 2008 at 08:17:03PM CET:
> 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'.
Well, it works with Libtool 2.2 on blade, I just tried. :-)
Not completely, mind you, but at least there are no test failures with
configure -C CC=gcc CXX=g++ F77=f77 FC=f90
After f{77,c}demo-{conf,shared}.test, the build fails due to
unreferenced symbols, roughly like this:
libtool: link: f90 -G -z defs -h libmix.so.0 -o .libs/libmix.so.0.0.0
.libs/foof.o .libs/foof2.o .libs/fooc.o
Undefined first referenced
symbol in file
puts.libs/fooc.o
__f90_slw_ch.libs/foof.o
__f90_sslw .libs/foof.o
__f90_eslw .libs/foof.o
which can be worked around by not using -no-undefined, or probably fixed
by fixing the extraction of all the Fortran support libraries from the
verbose link output. Nothing terribly bad, and the above issues only
cause SKIPs in the testsuite.
Cheers,
Ralf
___
Bug-libtool mailing list
[email protected]
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 [email protected] 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 [email protected] 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 [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 18 19 64 failed [Solaris 7 SPARC]
* Peter O'Gorman wrote on Fri, Mar 07, 2008 at 06:42:13AM CET: > Gary V. Vaughan wrote: > > On 6 Mar 2008, at 20:04, Peter O'Gorman wrote: > >> > >> 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? 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. Cheers, Ralf ___ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 18 19 64 failed [Solaris 7 SPARC]
Hi Peter, On 7 Mar 2008, at 00:42, Peter O'Gorman wrote: 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? If you think it causes a regression... it seems to me that things are no worse than before, so I think leaving it is fine for now. A FIXME to look at a better long term solution after we branch seems like a good idea tho' Cheers, Gary -- <=. Email me: [EMAIL PROTECTED] / @ @ /| Read my blog: http://blog.azazil.net \ \\ ...and my book: http://sources.redhat.com/autobook \^^\\ PGP.sig Description: This is a digitally signed message part ___ Bug-libtool mailing list [email protected] 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 [email protected] 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 [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 18 19 64 failed [Solaris 7 SPARC]
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? Maybe we should look into tagging the archive_cmds instead. Cheers, Gary -- <=. Email me: [EMAIL PROTECTED] / @ @ /| Read my blog: http://blog.azazil.net \ \\ ...and my book: http://sources.redhat.com/autobook \^^\\ PGP.sig Description: This is a digitally signed message part ___ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 18 19 64 failed [Solaris 7 SPARC]
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. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Bug-libtool mailing list [email protected] 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 [email protected] 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 [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
