[Top][All Lists]

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

Re: Mapfile missing from shared object artifact?

From: Thomas Jahns
Subject: Re: Mapfile missing from shared object artifact?
Date: Thu, 9 Nov 2017 10:37:28 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

On 11/09/17 05:10, Jeffrey Walton wrote:
On Wed, Nov 8, 2017 at 3:53 PM, Jeffrey Walton <address@hidden> wrote:
On Tue, Nov 7, 2017 at 12:33 PM, Jeffrey Walton <address@hidden> wrote:
I'm trying to run 'make check' on Solaris. It results in:

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

Any thoughts on this issue?

I gave up trying to have Automake use the flag. When I finally got it
applied using 'sed' on 'libtool', libtool choked on the option.

We ended up hijacking libtool's postlink_cmds (which was empty), and
inserting a script that used elfedit to insert the capabilities we

     elfedit -e 'cap:hw1 0x1800' .libs/

Libtool probably should have warned it was discarding an important
f**k'ing option instead of trying to sneak it by. Silent failures
waste everyone's time and make my blood boil.

Also see

Our[1] solution to the problem of libtool swallowing options is to escape known problematic options with -Xlinker or -Xcompiler prior to emitting the Makfiles. And since we run configure tests with libtool already active, that happens relatively early. We have more problems with Fortran compilers, so that's reflected in the corresponding macro _ACX_LT_FORT_FLAGS_MANGLE in m4/acx_use_libtool_configuration.m4 but the idea equally applies to C/C++ compiler options.

Regards, Thomas


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

reply via email to

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