On 11/09/17 05:10, Jeffrey Walton wrote:
On Wed, Nov 8, 2017 at 3:53 PM, Jeffrey Walton <noloa...@gmail.com> wrote:On Tue, Nov 7, 2017 at 12:33 PM, Jeffrey Walton <noloa...@gmail.com> 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 ] KilledAny 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