GNU logs - #29224, boring messages

Message sent to bug-libtool@HIDDEN:

Subject: bug#29224: Solaris, lost mapfiles and silent failures
Resent-From: Jeffrey Walton <noloader@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Thu, 09 Nov 2017 05:21:02 +0000
Resent-Message-ID: <handler.29224.B.151020480718780 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 29224 <at> debbugs.gnu.org
Reply-To: noloader@HIDDEN
MIME-Version: 1.0
From: Jeffrey Walton <noloader@HIDDEN>
Date: Thu, 9 Nov 2017 00:19:49 -0500
Message-ID: <CAH8yC8mhLyzAMgRkycWgsT8V-98WDEqVx9C-DRbeCVxf7an+Zw@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

I've been tracking an Autotools issue on Solaris 11.3 x86_64 (fully
patched). The project is a C++ library, and it uses a mapfile to set
capabilities on executables and shared objects.

The mapfile specifies SSE and SSE2 capabilities. The mapfile is added
with the linker option '-M mylib.mapfile'. There are no long forms of
the command. Confer,
https://docs.oracle.com/cd/E26502_01/html/E29030/ld-1.html.

When the Autotools project builds the library and test program,
libtool silently drops the mapfile when linking the shared object. It
just vanishes into the ether. The mapfile is present when building
test program. Its only missing when building the shared object.

Subsequently, trying to run the test program results in:

   $ ./cryptestcwd v
   ld.so.1: cryptestcwd: fatal:
   /export/home/cryptopp/.libs/libcryptopp.so.6: hardware capability
   (CA_SUNW_HW_1) unsupported: 0x4800000  [ AES SSE4.1 ]
   Killed

The failure is silent. libtool does not produce a warning or error
message stating its removing the option. The documentation does not
discuss libtool's behavior on Solaris. There's a warning for -M
options on Cygwin, and I believe that is the extent of it. Solaris is
certainly not Cygwin. Confer,
https://www.gnu.org/software/libtool/manual/libtool.html.

We spent the better part of a day trying to trouble shoot the issue.
Our attention was focused on Automake, and trying to untangle things
that result in missing AM_LDFLAGS options when linking the shared
object. The lack of a message probably wasted 6 to 10 man hours.

Please stop removing important options needed to link programs and
shared objects. The  options were specified for a reason and they are
necessary. If libtool cannot stop removing necessary options, then we
need (1) a clear message stating what is happening; (2) documentation
on the behavior; and (3) a way to override the default behavior.

An example of working around the problem would be nice since Autotools
does not appear to have a post-build or post-link hook. We cut-in an
awful hack, but it probably runs afoul of Autotools or libtool.
Confer, https://github.com/noloader/cryptopp-autotools/commit/61828068c6ab.

Thanks in advance.

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: noloader@HIDDEN
Subject: bug#29224: Acknowledgement (Solaris, lost mapfiles and silent
 failures)
Message-ID: <handler.29224.B.151020480718780.ack <at> debbugs.gnu.org>
References: <CAH8yC8mhLyzAMgRkycWgsT8V-98WDEqVx9C-DRbeCVxf7an+Zw@HIDDEN>
X-Gnu-PR-Message: ack 29224
X-Gnu-PR-Package: libtool
Reply-To: 29224 <at> debbugs.gnu.org
Date: Thu, 09 Nov 2017 05:21: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 29224 <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
29224: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D29224
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-libtool@HIDDEN:

Subject: bug#29224: Solaris, lost mapfiles and silent failures
Resent-From: Peter Rosin <peda@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Tue, 21 Nov 2017 15:38:01 +0000
Resent-Message-ID: <handler.29224.B29224.15112786723920 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: noloader@HIDDEN, 29224 <at> debbugs.gnu.org
References: <CAH8yC8mhLyzAMgRkycWgsT8V-98WDEqVx9C-DRbeCVxf7an+Zw@HIDDEN>
From: Peter Rosin <peda@HIDDEN>
Message-ID: <a2db71df-1179-9bf1-2d27-3c267dc92bda@HIDDEN>
Date: Tue, 21 Nov 2017 16:37:44 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CAH8yC8mhLyzAMgRkycWgsT8V-98WDEqVx9C-DRbeCVxf7an+Zw@HIDDEN>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

On 2017-11-09 06:19, Jeffrey Walton wrote:
> I've been tracking an Autotools issue on Solaris 11.3 x86_64 (fully
> patched). The project is a C++ library, and it uses a mapfile to set
> capabilities on executables and shared objects.
> 
> The mapfile specifies SSE and SSE2 capabilities. The mapfile is added
> with the linker option '-M mylib.mapfile'. There are no long forms of
> the command. Confer,
> https://docs.oracle.com/cd/E26502_01/html/E29030/ld-1.html.
> 
> When the Autotools project builds the library and test program,
> libtool silently drops the mapfile when linking the shared object. It
> just vanishes into the ether. The mapfile is present when building
> test program. Its only missing when building the shared object.
> 
> Subsequently, trying to run the test program results in:
> 
>    $ ./cryptestcwd v
>    ld.so.1: cryptestcwd: fatal:
>    /export/home/cryptopp/.libs/libcryptopp.so.6: hardware capability
>    (CA_SUNW_HW_1) unsupported: 0x4800000  [ AES SSE4.1 ]
>    Killed
> 
> The failure is silent. libtool does not produce a warning or error
> message stating its removing the option. The documentation does not
> discuss libtool's behavior on Solaris. There's a warning for -M
> options on Cygwin, and I believe that is the extent of it. Solaris is
> certainly not Cygwin. Confer,
> https://www.gnu.org/software/libtool/manual/libtool.html.
> 
> We spent the better part of a day trying to trouble shoot the issue.
> Our attention was focused on Automake, and trying to untangle things
> that result in missing AM_LDFLAGS options when linking the shared
> object. The lack of a message probably wasted 6 to 10 man hours.
> 
> Please stop removing important options needed to link programs and
> shared objects. The  options were specified for a reason and they are
> necessary. If libtool cannot stop removing necessary options, then we
> need (1) a clear message stating what is happening; (2) documentation
> on the behavior; and (3) a way to override the default behavior.
> 
> An example of working around the problem would be nice since Autotools
> does not appear to have a post-build or post-link hook. We cut-in an
> awful hack, but it probably runs afoul of Autotools or libtool.
> Confer, https://github.com/noloader/cryptopp-autotools/commit/61828068c6ab.

Your mail is a bit poisonous and seeks to blame others, so I'm not
sure I want to respond. I actually don't know why I'm spending time
on your problem...

But ok, I feel your pain. So, defending Libtool, I don't think the
manual states that linker options are supposed to be transparent. The
whole point of libtool is to hide the particulars of the specific
linker, especially when creating shared libraries. I.e. when using
Lintool, you get to use the options mentioned in the Libtool manual.
Sure, a lot of them are similar and in many cases equivalent to
options for "the real linkers", but it is an error to expect Libtool
to accept the union of all options of all linkers.

BTW, the first (and only) entry in the FAQ is:

    "Why does libtool strip link flags when creating a library?"

I suggest you read it. In short, research the -Wc and the -Wl options.

Perhaps "-Wc,-M,mylib.mapfile" or "-Wl,-M,mylib.mapfile" will do?

Cheers,
Peter

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.