GNU bug report logs - #10972
Some troubles with gfortran 4.6 and libtool

Message received at submit <at> debbugs.gnu.org:

Received: (at submit) by debbugs.gnu.org; 8 Mar 2012 23:32:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Mar 08 18:32:30 2012
Received: from localhost ([127.0.0.1]:39600 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1S5moh-00083u-Jb
	for submit <at> debbugs.gnu.org; Thu, 08 Mar 2012 18:32:30 -0500
Received: from eggs.gnu.org ([208.118.235.92]:42716)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <rofirrim@HIDDEN>) id 1S5m2l-0006vU-6M
	for submit <at> debbugs.gnu.org; Thu, 08 Mar 2012 17:43:04 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <rofirrim@HIDDEN>) id 1S5m1e-0000vc-4d
	for submit <at> debbugs.gnu.org; Thu, 08 Mar 2012 17:41:35 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
	RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable version=3.3.2
Received: from lists.gnu.org ([208.118.235.17]:40615)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rofirrim@HIDDEN>) id 1S5m1d-0000vW-VG
	for submit <at> debbugs.gnu.org; Thu, 08 Mar 2012 17:41:34 -0500
Received: from eggs.gnu.org ([208.118.235.92]:38913)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rofirrim@HIDDEN>) id 1S5m1b-000822-WE
	for bug-libtool@HIDDEN; Thu, 08 Mar 2012 17:41:33 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <rofirrim@HIDDEN>) id 1S5m1Z-0000uY-Ly
	for bug-libtool@HIDDEN; Thu, 08 Mar 2012 17:41:31 -0500
Received: from mail-yw0-f41.google.com ([209.85.213.41]:32936)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rofirrim@HIDDEN>) id 1S5m1Z-0000sf-FA
	for bug-libtool@HIDDEN; Thu, 08 Mar 2012 17:41:29 -0500
Received: by yhr47 with SMTP id 47so697532yhr.0
	for <bug-libtool@HIDDEN>; Thu, 08 Mar 2012 14:41:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type
	:content-transfer-encoding;
	bh=Ilyoi8MFQfunDY26u4hVQw7TlAHm6eLdyUEnyOuDTiw=;
	b=MkHKf+LTddbQMrPcG+BqveJJhIdd1DGkbjO2oQrt4dq77S9vYQBhU52WG0gdA38gx+
	hsxRomSAThR5wUpaYXZpl5m/BxDmDwiZ2jkoHPH8tiosgVuxv2jREF+Hs4UWfUbCN0OO
	AqoDjVH5qD3LW6tJ9WCn6mOsIkx0Hw/pPLNM5dd7OZm/qDfXpRG66Th3p4HbeOdinOih
	vvbtVKtBQOkjp8BjMk9WC0fKVWYg68sBDjph90N/wZcs+yjdjqBXmHFvPxOuiAvYTyxN
	OBi0cxUWObJFVICo+EQyRIf/IplFoTEUT2C89wfMKhEOMxKRpQQTTaLU2rN59PS8OwJF
	dWTQ==
MIME-Version: 1.0
Received: by 10.236.153.104 with SMTP id e68mr13083094yhk.74.1331246486655;
	Thu, 08 Mar 2012 14:41:26 -0800 (PST)
Received: by 10.236.165.35 with HTTP; Thu, 8 Mar 2012 14:41:26 -0800 (PST)
Date: Thu, 8 Mar 2012 23:41:26 +0100
Message-ID: <CAGeEQ1h9vZzfG5h1XYbu8bVqmvmCpgR72U6GYWCS0jv9hHQahQ@HIDDEN>
Subject: Some troubles with gfortran 4.6 and libtool
From: =?UTF-8?B?Um9nZXIgRmVycmVyIEliw6HDsWV6?= <rofirrim@HIDDEN>
To: bug-libtool@HIDDEN
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-detected-operating-system: by eggs.gnu.org: Genre and OS details not
	recognized.
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3)
X-Received-From: 208.118.235.17
X-Spam-Score: -1.9 (-)
X-Debbugs-Envelope-To: submit
X-Mailman-Approved-At: Thu, 08 Mar 2012 18:32:04 -0500
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -6.1 (------)

Hi,

maybe this has been discussed earlier, if so I apologize in advance.

While looking into some link failures using libtool + gfortran 4.6 I
discovered that as of 4.6, "gfortran -v" emits its own libraries with
a blank between '-l' and the name of the library. As I understood
after skimming libtool source, in most places a form "-lname" is
assumed and no "-l name" is handled (at least in the places relevant
to my problem).

When using autoconf, libtool.m4-injected code, tries to discover
hidden libraries that might be used by the current compiler. There is
a moment where this command is executed

eval '$CC -shared $CFLAGS -v conftest.$objext 2>&1 | $GREP "\-L"'

that expanded to the Fortran compiler (in my case gfortran 4.6) looks like

gfortran -shared -g -O2 -v conftest.o | /bin/grep '\-L'

If we manually check the output of gfortran 4.6 we see many lines but
the one I care is the first one

# This is gfortran 4.6
$ gfortran -shared -g -O2 -v conftest.o
Driving: gfortran -shared -g -O2 -v conftest.o -l gfortran -l m -shared-lib=
gcc
... lots of lines follow ...

Note the blanks in "-l gfortran" and "-l m". Despite that blank, this
line is harmless since it is filtered by "$GREP "\-L"

[Note: In gfortran 4.5 this line appears like this

# This is gfortran 4.5
$ gfortran -shared -v -g -O2 conftest.o
Driving: gfortran -shared -v -g -O2 conftest.o -lgfortran -lm -shared-libgc=
c

Note too that neither gcc nor g++ output such "Driving:" line, this
seems to be a gfortran thing]

So far this is not a problem as that $GREP "\-L" saved us.

Things get messy, though, when using mpif90 (or another similar tool).
mpif90 is the driver/wrapper for easier compilation of MPI Fortran 90
applications. Such wrapper is usually provided by MPI implementations
(like MPICH or OpenMPI). If we tell mpif90 to use gfortran we see that
the above invocation is much more involved

# Tell OpenMPI's mpif90 to use gfortran 4.6
$ export OMPI_FC=3Dgfortran
# Let's assume here we are running configure with FC=3Dmpif90, at some
point the following command is run
$ mpif90 -shared -g -O2 -v conftest.o 2>&1 | grep $GREP "\-L"
Driving: gfortran -shared -g -O2 -v conftest.o -I/path_of_mpi/include
-I/path_of_mpi/lib -L/path_of_mpi/lib -lmpi_f90 -lmpi_f77 -lmpi -ldl
-Wl,--export-dynamic -lnsl -lutil -l gfortran -lm -ldl -l gfortran -l
m -shared-libgcc
... lots of lines follow ...

Note that the wrapper is adding an -Lflag, thus this line (with the
troublesome "-l gfortran" and "-l m") is not filtered by that $GREP
above.

When libtool code analizes "gfortran -v" output it assumes that the
form of a -l option is always "-lname". So it ends assuming it needs a
library named "" (the empty string). This causes that the "postdeps"
variable in the configure-generated libtool ends containing an empty
"-l" (among other legitimate "-lname" libraries). When linking the
application such "-l" flag is added by libtool and link fails.

I came up with several ideas to solve this issue but none seems
totally satisfying to me.

We could ask gfortran guys to revert to pre-4.6 behaviour of emitting
-lname instead of "-l name". Since "gfortran" understands "-l name"
this does not sound too realistic to me :)

Another approach is reducing the "-l name" problem to "-lname".
Replace every occurrence of the variable 'output_verbose_link_cmd' as
follows

 -      output_verbose_link_cmd=3D'$CC -shared $CFLAGS -v
conftest.$objext 2>&1 | $GREP "\-L"'
+      output_verbose_link_cmd=3D'$CC -shared $CFLAGS -v
conftest.$objext 2>&1 | $GREP "\-L" | $SED -e
"s/-l\s\+\(@<:@^-@:>@\S*\)/-l\1/g"'

This seems to work in my Linux machine (GNU sed powered).

I'm not expert in sed so maybe this is too naive, kludgy or plain
wrong. I assume that "-l" alone does not mean anything and must be
followed by a name. Concerning portability, I think that \s (for
whitespace) and \S (for non-whitespace) are GNU extensions. Although
not entirely equivalent they could be replaced by [ ] and [^ ].

Finally, another simpler approach would be filtering that line

+      output_verbose_link_cmd=3D'$CC -shared $CFLAGS -v
conftest.$objext 2>&1 | $GREP -v "Driving:" | $GREP "\-L"

Kind regards,

P.S.: This problem is not a blocker since one can always fix the
configure-generated libtool, for instance using sed.

--
Roger Ferrer Ib=C3=A1=C3=B1ez