Re: AC_FC_LIBRARY_LDFLAGS: quoting bug on Solaris with gfortran

[Eric Blake]

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.

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

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
   _AC_PROG_FC_V_OUTPUT($ac_verb)
   # 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]]*)
          ac_cv_prog_[]_AC_LANG_ABBREV[]_v=$ac_verb

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