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

2008-03-07 Thread Ralf Wildenhues
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]

2008-03-07 Thread Bob Friesenhahn

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]

2008-03-07 Thread Peter O'Gorman
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: 18 19 64 failed [Solaris 7 SPARC]

2008-03-06 Thread Peter O'Gorman
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: 18 19 64 failed [Solaris 7 SPARC]

2008-03-06 Thread Bob Friesenhahn

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
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


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

2008-03-06 Thread Gary V. Vaughan

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
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


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

2008-03-06 Thread Peter O'Gorman
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]

2008-03-06 Thread Peter O'Gorman
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]

2008-03-06 Thread Peter O'Gorman
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: 18 19 64 failed [Solaris 7 SPARC]

2008-03-05 Thread Peter O'Gorman
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