[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libtool 2.2] testsuite: 18 19 64 failed [Solaris 7 SPARC]

From: Gary V. Vaughan
Subject: Re: [libtool 2.2] testsuite: 18 19 64 failed [Solaris 7 SPARC]
Date: Fri, 7 Mar 2008 01:07:13 -0500

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
/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.


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'

  <=====.                   Email me: address@hidden
 / @ @  /|           Read my blog: http://blog.azazil.net
 \      \\      ...and my book: http://sources.redhat.com/autobook

Attachment: PGP.sig
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]