本文介绍了libtool是否使用-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):

没有其他提及-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在发生时发出警告,但除非您对此提出问题,否则这几乎没有任何意义.

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:

/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去除所有选项?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

  • 08-26 14:49
    查看更多