bug-libtool
[Top][All Lists]
Advanced

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

Re: 2.2.8 testsuite failures on mac os x 10.6.3 with gcc-4.5


From: Gary V. Vaughan
Subject: Re: 2.2.8 testsuite failures on mac os x 10.6.3 with gcc-4.5
Date: Sun, 6 Jun 2010 16:49:11 +0700

Hi Peter,

On 6 Jun 2010, at 03:29, Peter O'Gorman wrote:
> Hi,
> 
> Well, I guess I didn't test with latest gcc before:

Is there a new X-Code with gcc-4.5?  Or did you build it yourself?

I'd kinda like to have a full gcc with fortran etc, but it's just painful 
enough to find the details of how to get the apple version of gcc to build 
everything that I haven't made the effort to do it again since I moved to Snow 
Leopard. Instead, I run the pre-release tests on a Linux VM. (Secretly hoping 
that you'll say: "nowadays you just download this tarball and build it with 
these options"...)

> libtool: compile:  gfortran -g -O2 -c main3.f  -fno-common -o .libs/main3.o
> libtool: compile:  gfortran -g -O2 -c main3.f -o main3.o >/dev/null 2>&1
> libtool: compile:  gfortran -g -O2 -c a3.f  -fno-common -o .libs/a3.o
> libtool: compile:  gfortran -g -O2 -c a3.f -o a3.o >/dev/null 2>&1
> libtool: link: ar cru .libs/liba3.a .libs/a3.o
> libtool: link: ranlib .libs/liba3.a
> libtool: link: ( cd ".libs" && rm -f "liba3.la" && ln -s "../liba3.la" 
> "liba3.la" )
> ./convenience.at:211: $LIBTOOL --tag=FC --mode=link $FC $FCFLAGS $LDFLAGS -o 
> liba12.la liba1.la liba2.la -rpath /notexist
> stderr:
> gfortran: no input files; unwilling to write output files
> stdout:
> libtool: link: gfortran -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o 
> .libs/liba12.0.dylib   -Wl,-force_load,./.libs/liba1.a 
> -Wl,-force_load,./.libs/liba2.a  -L/sw/lib    -install_name 
> /notexist/liba12.0.dylib -compatibility_version 1 -current_version 1.0 
> -Wl,-single_module
> ./convenience.at:211: exit code was 1, expected 0
> 29. convenience.at:169: 29. FC convenience archives (convenience.at:169): 
> FAILED (convenience.at:211)
> 
> Do we really want to test this with no object files?

That looks like an oversight in the test.  I'm surprised it ever worked 
actually.

> and:
> 
> libtool: compile:  gcj -g -O2 -c A3.java  -fno-common -o .libs/A3.o
> A3.java:2: warning: The field A3.a is never read locally
>        private int a;
>                    ^
> 1 problem (1 warning)
> libtool: compile:  gcj -g -O2 -c A3.java -o A3.o >/dev/null 2>&1
> libtool: link: ar cru .libs/liba3.a .libs/A3.o
> libtool: link: ranlib .libs/liba3.a
> libtool: link: ( cd ".libs" && rm -f "liba3.la" && ln -s "../liba3.la" 
> "liba3.la" )
> ./convenience.at:275: $LIBTOOL --tag=GCJ --mode=link $GCJ $GCJFLAGS $LDFLAGS 
> -o liba12.la liba1.la liba2.la -rpath /notexist
> stderr:
> ld: -allow_stack_execute option can only be used when linking a main 
> executable
> collect2: ld returned 1 exit status
> stdout:
> libtool: link: gcj -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o 
> .libs/liba12.0.dylib   -Wl,-force_load,./.libs/liba1.a 
> -Wl,-force_load,./.libs/liba2.a  -L/sw/lib    -install_name 
> /notexist/liba12.0.dylib -compatibility_version 1 -current_version 1.0 
> -Wl,-single_module
> ./convenience.at:275: exit code was 1, expected 0
> 30. convenience.at:229: 30. Java convenience archives (convenience.at:229): 
> FAILED (convenience.at:275)
> 
> This one looks like a gcc issue, it shouldn't be passing -allow_stack_execute 
> with -dynamiclib. I'll look into it.

Thanks!

Cheers,
-- 
Gary V. Vaughan (address@hidden)


reply via email to

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