On Thu, 6 Mar 2008, Ralf Wildenhues wrote:
Then, let's avoid us getting blame for broken gcj installations.
OK to apply this patch to avoid the gcj test when a compile would fail?
Or do you feel tests for working compilers should be done in configure
already?
My feeling is that the sooner a
Ralf Wildenhues wrote:
Hello Nelson, Peter,
* Peter O'Gorman wrote on Thu, Mar 06, 2008 at 06:18:42AM CET:
Nelson H. F. Beebe wrote:
libtool: compile: gcj -g -O2 -c A3.java
gcj: libgcj.spec: No such file or directory
Your gcj and automake are broken. Do you have a sane toolchain on
On Thu, 6 Mar 2008, Peter O'Gorman wrote:
I think the test for a working GCJ should be in libtool, and unset GCJ,
avoid adding the tag etc.if it is found to be nonfunctional. We would
have to issue a warning during configure or something. Does not look to
be quite as easy as this patch though,
On Thu, 6 Mar 2008, Ralf Wildenhues wrote:
But that should not be Libtool's decision, but the package's.
Libtool already supports a syntax by which the package can specify the
languages that it wants to configure for. I agree that this may not
be expected to cause hard-failure if a
Ralf Wildenhues wrote:
* Bob Friesenhahn wrote on Thu, Mar 06, 2008 at 08:43:15PM CET:
On Thu, 6 Mar 2008, Peter O'Gorman wrote:
I think the test for a working GCJ should be in libtool, and unset GCJ,
avoid adding the tag etc.if it is found to be nonfunctional. We would
have to issue a
On Thu, 6 Mar 2008, Peter O'Gorman wrote:
What would be ideal is to check that the compiler exists, is executable,
works (an possibly, when not cross-compiling, test that trivial code
that is compiled with the compiler runs) but not cause an error if the
compiler is broken or does not exist,
Hello John,
* John Bytheway wrote on Tue, Jan 29, 2008 at 10:54:05PM CET:
I've been using libtool and libltdl to load libraries at runtime in a
project I'm working on, and encountered circumstances where the error
messages are less helpful than they might be.
Looking at CVS HEAD, The
Hi Bob,
On 6 Mar 2008, at 15:03, Bob Friesenhahn wrote:
There needs to be a way to output any warnings at the tail end of
configure so that at least someone is more likely to see them.
Without adequate notification to the user, the user is likely to try
'make' and then find that libtool
* Gary V. Vaughan wrote on Thu, Mar 06, 2008 at 10:41:47PM CET:
On 6 Mar 2008, at 15:03, Bob Friesenhahn wrote:
There needs to be a way to output any warnings at the tail end of
configure so that at least someone is more likely to see them.
Without adequate notification to the user, the
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
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
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
* 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?
13 matches
Mail list logo
