libtool是否使用-M去除所有选项? [英] Does libtool strip all options with -M?

问题描述

我正在尝试查找与Solaris上的映射文件链接失败的方法.当我尝试运行自检时，缺少的映射文件会导致以下错误:

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

我已经了解了这个Automake规则.我认为是共享对象的libcryptopp_la_LINK丢失了AM_LDFLAGS. AM_LDFLAGS保留-M cryptopp.mapfile选项.

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 $@

我尝试在configure运行后用sed对其进行修补:

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 $@

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

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

libtool手册讨论有关Cygwin的-M参数，但不适用于Solaris(并且讨论仅适用于GCC，不适用于其他编译器，如IBM XL C/C ++，Sun C/C ++和LLVM Clang):

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):

请注意，您还需要确保标准Unix目录(例如/bin，/lib，/usr，/etc)出现在驱动器的根目录中.这意味着您必须将Cygwin本身安装到C:/根目录(或D:/或E:/等)中，而不是建议将其安装到C:/cygwin/中.此外，构建系统中使用的所有文件名都必须是相对的，在源目录或构建目录树中不应使用符号链接，并且必须避免gcc的所有-M *选项(除了-MMD之外).

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>" .

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

我的问题是，libtool是否出于某种原因而放弃了-M及其参数?

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

推荐答案

Libtool在创建库时会删除某些链接选项. 手册说明:

Libtool does drop some link options when creating a library. The manual explains:

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

When creating a shared library, but not when compiling or creating a program, libtool drops some flags from the command line provided by the user. This is done because flags unknown to libtool may interfere with library creation or require additional support from libtool, and because omitting flags is usually the conservative choice for a successful build.

我个人认为，此行为的理由有些轻率，而且我认为它值得libtool在发生时发出警告，但除非您对此提出问题，否则这几乎没有任何意义.

Personally, I find the justification for this behavior to be a bit cavalier, and I furthermore think it warrants a warning from libtool when it occurs, but unless you care to raise an issue against it, that's pretty much moot.

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

Experimentation shows that -M is indeed among the options that libtool strips. In particular, if I specify LDFLAGS containing an -M option on the make command line then I can observe it echoed in the make output when it runs the libtool link, but not in libtool's own echo of the link command that is actually executed:

$ make LDFLAGS =-M映射文件"

$ make LDFLAGS="-M mapfile"

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

/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: 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文档建议了两种解决方法来传递否则将被剥离的链接选项:

The libtool docs suggest two workarounds to pass link options that otherwise would be stripped:

• 对于善意链接器选项，可以使用一个或多个-Wl,或-Xlinker选项将选项通过libtool和链接器驱动程序传递给链接器本身.例如，

• For bona fide linker options, you can use one or more -Wl, or -Xlinker options to pass your options through libtool and the linker driver to the linker itself. For example,

 LDFLAGS=-Wl,-M,cryptopp.mapfile

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

For options directed specifically to the linker driver, the docs suggest adding the flags to the compiler driver command (CC="gcc -M mapfile"), but this is ineffective because the $(CC) variable is expanded by make to form the libtool command line, leaving any options expressed in it exposed to libtool for stripping.

此外，还有

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

• The -XCClinker option by which options can be passed through to the linker driver (as opposed to the linker itself), but its behavior seems a bit quirky: it seems to ignore options that don't start with a hyphen (such as the name of your map file).

这篇关于libtool是否使用-M去除所有选项?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！