Re: Mapfile missing from shared object artifact?

[Thomas Jahns]

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
> > > ld.so.1: cryptestcwd: fatal:
> > > /export/home/cryptopp/.libs/libcryptopp.so.6: hardware capability
> > > (CA_SUNW_HW_1) unsupported: 0x4800000  [ AES SSE4.1 ]
> > > Killed
> >
> > 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
> wanted:
>
>      elfedit -e 'cap:hw1 0x1800' .libs/libcryptopp.so.6.0.0
>
> 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 https://github.com/noloader/cryptopp-autotools/commit/61828068c6ab.

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

[1] https://www.dkrz.de/redmine/projects/scales-ppm

smime.p7s
Description: S/MIME Cryptographic Signature