问题描述
我正在尝试查找与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 throughlibtool
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去除所有选项?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!