[Top][All Lists]

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

Re: AC_FC_LIBRARY_LDFLAGS: quoting bug on Solaris with gfortran

From: Eric Blake
Subject: Re: AC_FC_LIBRARY_LDFLAGS: quoting bug on Solaris with gfortran
Date: Thu, 16 Sep 2010 14:37:01 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100907 Fedora/3.1.3-1.fc13 Mnenhy/0.8.3 Thunderbird/3.1.3

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])

$ cat Makefile.in
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.

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

where conftest.f is a simple file:
      program main

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

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?

diff --git i/ChangeLog w/ChangeLog
index 061c6ae..c99d120 100644
--- i/ChangeLog
+++ w/ChangeLog
@@ -1,5 +1,8 @@
 2010-09-16  Eric Blake  <address@hidden>

+       * lib/autoconf/fortran.m4 (_AC_PROG_FC_V): Ignore leading and
+       trailing single and double quotes, as a last ditch effort.
        m4sugar: fix regression in AC_MSG_ERROR expansion
        * lib/m4sugar/m4sugar.m4 (m4_defun_init): Avoid macro
        concatenation on subsequent expansions
diff --git i/lib/autoconf/fortran.m4 w/lib/autoconf/fortran.m4
index e8f7bbc..e2d4e20 100644
--- i/lib/autoconf/fortran.m4
+++ w/lib/autoconf/fortran.m4
@@ -566,6 +566,11 @@ for ac_verb in -v -verbose --verbose -V -\#\#\#; do
   # look for -l* and *.a constructs in the output
   for ac_arg in $ac_[]_AC_LANG_ABBREV[]_v_output; do
+    case $ac_arg in
+      [\'\"]* | *[\'\"])
+       ac_sed='s/^['\''"]//;s/['\''"]$//'
+       ac_arg=`echo "$ac_arg" | sed "$ac_sed"`;;
+    esac
      case $ac_arg in
        [[\\/]]*.a | ?:[[\\/]]*.a | -[[lLRu]]*)

Also, if it _does_ fix your issue, does anyone see a huge risk in applying this before 2.68?

Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

reply via email to

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