bug-autoconf
[Top][All Lists]
Advanced

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

Re: AC_FC_LIBRARY_LDFLAGS: quoting bug on Solaris with gfortran


From: Stefano Lattarini
Subject: Re: AC_FC_LIBRARY_LDFLAGS: quoting bug on Solaris with gfortran
Date: Thu, 16 Sep 2010 23:06:58 +0200
User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )

Hi Eric.  Thanks for looking into this; unfortunately, your
patch doesn't work :-(

On Thursday 16 September 2010, Eric Blake wrote:
> On 09/15/2010 04:38 PM, Stefano Lattarini wrote:
> > On Thursday 16 September 2010, Eric Blake wrote:
> >> On 07/01/2010 07:00 AM, Stefano Lattarini wrote:
> >>> This is a minimal example exposing a bug that bit me while I
> >>> was running the Automake testsuite on a Solaris system.  The
> >>> bug seems to be located in the macro `AC_FC_LIBRARY_LDFLAGS'.
> >>> 
> >>> $ cat configure.ac
> >>> AC_INIT([foo], [1.0])
> >>> AC_PROG_FC
> >>> AC_FC_LIBRARY_LDFLAGS
> >>> AC_CONFIG_FILES([Makefile])
> >>> AC_OUTPUT
> >>> 
> >>> $ cat Makefile.in
> >>> FCLIBS = @FCLIBS@
> >>> default:; @echo $(FCLIBS)
> >> 
> >> Have you had a chance to look into this any deeper?
> > 
> > No, but I might give it a try.
> 
> I can't reproduce this on the Solaris machine I have access to, but
> I also didn't have gfortran installed on that machine.
The testcase above works correctly with the Sun Fortran Compiler for
me, too.
 
> It looks like AC_FC_LIBRARY_LDFLAGS is rather fragile, in that it
> uses _AC_PROG_FC_V_OUTPUT to try and parse compiler -v output,
> which may or may not be enclosed in shell quoting, and that it is
> special-casing output from some, but not all, compilers.
> 
> Since you mentioned gfortran, I'm assuming that the output that
> autoconf is trying to parse results from something like this
> (looking at config.log can verify for sure):
> 
> gfortran -o conftest -g -v conftest.f 2>&1
Precisely, "gfortran -o conftest -g -O2 -v conftest.f 2>&1"

> 
> where conftest.f is a simple file:
>        program main
>        end
> 
> On Fedora, I'm seeing something that ends in:
> 
> COLLECT_GCC_OPTIONS='-o' 'conftest' '-g' '-v' '-shared-libgcc'
> '-mtune=generic'
>   /usr/libexec/gcc/x86_64-redhat-linux/4.4.4/collect2
> --no-add-needed --eh-frame-hdr --build-id -m elf_x86_64
> --hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o
> conftest
> /usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../lib64/crt1.o
> /usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../lib64/crti.o
> /usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtbegin.o
> -L/usr/lib/gcc/x86_64-redhat-linux/4.4.4
> -L/usr/lib/gcc/x86_64-redhat-linux/4.4.4
> -L/usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../lib64
> -L/lib/../lib64 -L/usr/lib/../lib64
> -L/usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../.. /tmp/cc9Gzd9e.o
> -lgfortranbegin -lgfortran -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
> /usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtend.o
> /usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../lib64/crtn.o

This is what I'm seeing on Solaris:

Driving: gfortran -o conftest -g -O2 -v conftest.f -lgfortranbegin -lgfortran 
-lm -shared-libgcc
Using built-in specs.
Target: i386-pc-solaris2.10
Configured with: /home/bfriesen/src/gnu/gcc-4.4.4/configure 
LDFLAGS='-L/usr/local/lib -R/usr/local/lib' --program-suffix=-4.4.4 
--enable-shared --enable-threads --
enable-version-specific-runtime-libs --with-gnu-as 
--with-as=/usr/local/lib/binutils-2.20/bin/as --without-gnu-ld 
--with-ld=/usr/ccs/bin/ld --with-gmp=/usr/local --
with-mpfr=/usr/local --with-cpu=opteron --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.4.4 (GCC) 
COLLECT_GCC_OPTIONS='-o' 'conftest' '-g' '-O2' '-v' '-shared-libgcc' 
'-mtune=opteron'
 /usr/local/libexec/gcc/i386-pc-solaris2.10/4.4.4/f951 conftest.f -ffixed-form 
-quiet -dumpbase conftest.f -mtune=opteron -auxbase conftest -g -O2 -version -
fintrinsic-modules-path /usr/local/lib/gcc/i386-pc-solaris2.10/4.4.4/finclude 
-o /tmp/cchOdCHA.s
GNU Fortran (GCC) version 4.4.4 (i386-pc-solaris2.10)
        compiled by GNU C version 4.4.4, GMP version 4.3.1, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-o' 'conftest' '-g' '-O2' '-v' '-shared-libgcc' 
'-mtune=opteron'
 /usr/local/lib/binutils-2.20/bin/as -v --traditional-format -V -Qy -s -o 
/tmp/ccUwxfR4.o /tmp/cchOdCHA.s
GNU assembler version 2.20 (i386-pc-solaris2.10) using BFD version (GNU 
Binutils) 2.20
COMPILER_PATH=/usr/local/libexec/gcc/i386-pc-solaris2.10/4.4.4/:/usr/local/libexec/gcc/i386-pc-solaris2.10/4.4.4/:/usr/local/libexec/gcc/i386-pc-
solaris2.10/:/usr/local/lib/gcc/i386-pc-solaris2.10/4.4.4/:/usr/local/lib/gcc/i386-pc-solaris2.10/:/usr/ccs/bin/
LIBRARY_PATH=/usr/local/lib/gcc/i386-pc-solaris2.10/4.4.4/:/usr/local/lib/gcc/i386-pc-solaris2.10/4.4.4/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-o' 'conftest' '-g' '-O2' '-v' '-shared-libgcc' 
'-mtune=opteron'
 /usr/local/libexec/gcc/i386-pc-solaris2.10/4.4.4/collect2 -V -Y 
P,/usr/ccs/lib:/usr/lib -Qy -o conftest /usr/lib/crt1.o /usr/lib/crti.o 
/usr/lib/values-Xa.o 
/usr/local/lib/gcc/i386-pc-solaris2.10/4.4.4/crtbegin.o 
-L/usr/local/lib/gcc/i386-pc-solaris2.10/4.4.4 
-L/usr/local/lib/gcc/i386-pc-solaris2.10/4.4.4/../../.. 
/tmp/ccUwxfR4.o -lgfortranbegin -lgfortran -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc 
/usr/local/lib/gcc/i386-pc-solaris2.10/4.4.4/crtend.o /usr/lib/crtn.o
ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.497

The culprit seems to be the line:
 Configured with: ... LDFLAGS='-L/usr/local/lib -R/usr/local/lib' ...

> which I can correlate to the final setting of FCLIBS:
> 
> $ make
> -L/usr/lib/gcc/x86_64-redhat-linux/4.4.4
> -L/usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../lib64
> -L/lib/../lib64 -L/usr/lib/../lib64
> -L/usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../.. -lgfortranbegin
> -lgfortran -lm
> 
> Notice how some, but not all, of the 'gfortran -v' output was
> single-quoted.
> 
> Maybe the fix is to teach _AC_PROG_FC_V_OUTPUT to blindly strip
> leading and trailing ' and " from all words, regardless of
> compiler - after all, a user worried about portability should not
> be in a situation where the default linker is using libraries with
> spaces in their names.
> 
> If my hunch is right, then does this (untested) patch fix your
> problem?
Unfortunately no.

Would you like me to post the output of "sh -x configure" run
on my testcase with an autoconf having your patch enabled?

Thanks,
   Stefano



reply via email to

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