c++ - libtool 是否使用 -M 删除所有选项？

Question

我正试图找出与 Solaris 上的映射文件链接失败的原因。当我尝试运行我们的自检时，缺少的 mapfile 导致以下错误:

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

我已经了解了这条 Automake 规则。 libcryptopp_la_LINK ，我认为是共享对象，丢失了 AM_LDFLAGS . AM_LDFLAGS持有-M cryptopp.mapfile选项。

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

我尝试用 sed 修补它在 configure 之后运行:

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

我确认了 sed是成功的，但同样的测试再次失败。调用命令时 -M <mapfile>丢失了。

libtool manual谈论-M Cygwin 上的参数，但不适用于 Solaris(并且讨论仅适用于 GCC，而不适用于其他编译器，如 IBM XL C/C++、Sun C/C++ 和 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.

没有其他提及 -M .

并且没有诊断，例如“正在删除 Sun 链接器的 -M <mapfile> 选项” 或 “警告:libtool 不理解选项 -M <mapfile>”。

我的问题是，libtool丢弃 -M及其出于某种原因的论点？

Answer 1

Libtool 在创建库时确实会删除一些链接选项。 The manual explains :

When creating a shared library, but not when compiling or creating aprogram, libtool drops some flags from the command line provided bythe user. This is done because flags unknown to libtool may interferewith library creation or require additional support from libtool, andbecause omitting flags is usually the conservative choice for asuccessful build.

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

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

$ make LDFLAGS="-M mapfile"

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

libtool: link: gcc -shared -fPIC -DPIC .libs/x.o .libs/y.o -O2 -Wl,-soname -Wl,libmylib.so.0 -o .libs/libmylib.so.0.0.0

libtool 文档提出了两种解决方法来传递链接选项，否则将被删除:

• 对于 bona fide 链接器选项，您可以使用一个或多个 -Wl, 或 -Xlinker 选项来传递您的选项通过 libtool 和链接器驱动程序到链接器本身。例如，

   LDFLAGS=-Wl,-M,cryptopp.mapfile
  

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

不过，还有

• -XCClinker 选项可以将选项传递给链接器驱动程序(而不是链接器本身)，但它的行为似乎有点古怪:它似乎忽略了不不要以连字符开头(例如 map 文件的名称)。