GNU logs - #10972, boring messages

Message sent to bug-libtool@HIDDEN:

Subject: bug#10972: Some troubles with gfortran 4.6 and libtool
Resent-From: Roger Ferrer =?UTF-8?Q?Ib=C3=A1=C3=B1ez?= <rofirrim@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Thu, 08 Mar 2012 23:33:02 +0000
Resent-Message-ID: <handler.10972.B.133124955031020 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 10972 <at> debbugs.gnu.org
MIME-Version: 1.0
Date: Thu, 8 Mar 2012 23:41:26 +0100
Message-ID: <CAGeEQ1h9vZzfG5h1XYbu8bVqmvmCpgR72U6GYWCS0jv9hHQahQ@HIDDEN>
From: Roger Ferrer =?UTF-8?Q?Ib=C3=A1=C3=B1ez?= <rofirrim@HIDDEN>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org

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

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Roger Ferrer =?UTF-8?Q?Ib=C3=A1=C3=B1ez?= <rofirrim@HIDDEN>
Subject: bug#10972: Acknowledgement (Some troubles with gfortran 4.6 and
 libtool)
Message-ID: <handler.10972.B.133124955031020.ack <at> debbugs.gnu.org>
References: <CAGeEQ1h9vZzfG5h1XYbu8bVqmvmCpgR72U6GYWCS0jv9hHQahQ@HIDDEN>
X-Gnu-PR-Message: ack 10972
X-Gnu-PR-Package: libtool
Reply-To: 10972 <at> debbugs.gnu.org
Date: Thu, 08 Mar 2012 23:33:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-libtool@HIDDEN

If you wish to submit further information on this problem, please
send it to 10972 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
10972: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D10972
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.