0

I'm trying to track down a failure to link with a mapfile on Solaris. The missing mapfile causes the following error when I try to run our self tests:

$ ./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

I've gotten as far as this Automake rule. libcryptopp_la_LINK, which I believe is the shared object, is missing AM_LDFLAGS. AM_LDFLAGS holds the -M cryptopp.mapfile option.

libcryptopp_la_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) \
    $(LIBTOOLFLAGS) --mode=link $(CXXLD) $(AM_CXXFLAGS) \
    $(CXXFLAGS) $(libcryptopp_la_LDFLAGS) $(LDFLAGS) -o $@

I tried to patch it with sed after configure runs:

libcryptopp_la_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) \
    $(LIBTOOLFLAGS) --mode=link $(CXXLD) $(AM_CXXFLAGS) \
    $(CXXFLAGS) $(libcryptopp_la_LDFLAGS) -M cryptopp.mapfile $(LDFLAGS) -o $@

I confirmed the sed is successful, but the same test fails again. When the commands are invoked -M <mapfile> is missing.

The libtool manual talks about -M arguments on Cygwin, but not Solaris (and the discussion only applies to GCC, and not other compilers like IBM XL C/C++, Sun C/C++ and LLVM Clang):

Note that you also need to ensure that the standard Unix directories (like /bin, /lib, /usr, /etc) appear in the root of a drive. This means that you must install Cygwin itself into the C:/ root directory (or D:/, or E:/, etc)—instead of the recommended installation into C:/cygwin/. In addition, all file names used in the build system must be relative, symlinks should not be used within the source or build directory trees, and all -M* options to gcc except -MMD must be avoided.

There is no other mention of -M.

And there is no diagnostic, like "Removing -M <mapfile> options to Sun linker" or "Warning: libtool does not understand option -M <mapfile>".

My question is, does libtool discard -M and its arguments for some reason?

4

1 回答 1

1

Libtool 在创建库时会删除一些链接选项。 手册解释：

在创建共享库时，而不是在编译或创建程序时，libtool 从用户提供的命令行中删除一些标志。这样做是因为 libtool 未知的标志可能会干扰库的创建或需要 libtool 的额外支持，并且因为省略标志通常是成功构建的保守选择。

就个人而言，我发现这种行为的理由有点漫不经心，而且我还认为它需要libtool在它发生时发出警告，但除非你愿意提出反对它的问题，否则这几乎没有实际意义。

实验表明，这-M确实是libtool剥离的选项之一。特别是，如果我在命令行上指定LDFLAGS包含一个-M选项，make那么我可以观察到它在make运行libtool链接时在输出中回显，但不是在实际执行的链接命令libtool的自己的回显中：

$ 使 LDFLAGS="-M 映射文件"

/bin/sh ./libtool --tag=CC --mode=link gcc -g -O2 -M mapfile -o libmylib.la -rpath /usr/local/lib x.lo y.lo

libtool：链接：gcc -shared -fPIC -DPIC .libs/xo .libs/yo -O2 -Wl,-soname -Wl,libmylib.so.0 -o .libs/libmylib.so.0.0.0

libtool文档提出了两种解决方法来传递链接选项，否则这些选项将被剥离：

  • 对于真正的链接器选项，您可以使用一个或多个-Wl,or-Xlinker选项将您的选项libtool和链接器驱动程序传递给链接器本身。例如，

     LDFLAGS=-Wl,-M,cryptopp.mapfile

  • 对于专门针对链接器驱动程序的选项，文档建议将标志添加到编译器驱动程序命令（CC =“gcc -M mapfile”），但这 是无效的，因为$(CC)变量被扩展make以形成libtool命令行，留下任何选项表示在它暴露libtool于剥离。

然而，此外，还有

  • -XCClinker选项可以传递给链接器驱动程序的选项（而不是链接器本身），但它的行为似乎有点古怪：它似乎忽略了不以连字符开头的选项（例如您的名称地图文件）。
于 2017-11-09T18:25:20.947 回答