我已经阅读了GCC的代码生成约定选项,但无法理解"生成与位置无关的代码(PIC)"的作用.请举例说明一下这是什么意思.
我已经阅读了gcc手册页,但我还是不明白之间的差别-fpic和-fPIC.有人可以用一种非常简单明了的方式解释它吗？
相关问题:
我试图在我的ARM Ubuntu机器上按照本指南重新安装我的ffmpeg .不幸的是,当我编译一个使用这个lib的程序时,我得到以下失败:
/usr/bin/ld: /usr/local/lib/libavcodec.a(amrnbdec.o): relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/libavcodec.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
现在我想像-fPIC编译器建议的那样重新编译它,但我不知道如何.任何帮助表示赞赏.
如何使用类似的东西来判断objdump是否已经构建了一个目标文件-fPIC？
至少在Linux和Solaris上,静态库实际上只是一堆编译好的.o文件被扔进一个大文件中.编译静态库时,通常会忽略-fpic标志,因此生成的代码与位置有关.
现在说我的静态库是B.我已经构建了它并且得到了.a文件,它实际上只是所有位置相关的.o文件的全局.现在我有一个我想构建的共享库,A,我希望它静态链接B.当我构建A时,我自然会使用-fpic标志使生成的代码位置独立.但是,如果我链接B,我不是混合位置依赖和位置独立的目标文件？
除非我还指定-mimpure-text,否则我会收到很多文本重定位错误,我认为这可能是原因.看来,当我编译一个库时,我真的需要编译它3次,共享版本,静态版本和静态 - 可以使用的共享库版本.我对吗？我可以继续使用-mimpure-text,但g ++手册页说如果你这样做,对象实际上并没有最终被共享(不清楚它是否全部未被共享,或者仅仅是静态链接的部分,有人知道吗？) .
我最近收到了:
...在创建共享对象时,不能使用"对本地符号"重定位R_X86_64_32; 用-fPIC重新编译
尝试将程序编译为共享库时出错.
现在解决这个问题并不太困难(使用-fPIC重新编译所有依赖项),但经过一些研究后发现这个问题只出现在x86-64平台上.在32位上,任何依赖于位置的代码仍可由动态加载程序重新定位.
我能找到的最佳答案是:
x86支持.text重定位(当你有位置依赖代码时会发生这种情况).这种支持是有代价的,即包含这种重定位的每个页面基本上都不共享,即使它位于共享库中,从而破坏了共享库的概念.因此我们决定在amd64上禁止这个(如果值需要超过32位,它会产生问题,因为所有.text relocs只有'word32'大小)
但我觉得这还不够.如果重定位破坏了共享库的概念,为什么可以在32位平台上完成？此外,如果需要对ELF格式进行更改以支持64位,那么为什么并非所有字段的大小都增加以容纳？
这可能是一个小问题,但它的动机是这样一个事实:a)所讨论的代码是一个科学的代码,如果不必受到性能影响就很好b)这个信息很难在第一名!
[编辑:'答案'
@awoodlands的回答可能是最好的'字面答案',@ iservn 补充了一些很好的信息.
在搜索中找到有关不同类型重定位的更多信息时,我发现了这个并最终发现了x86_64 ABI参考(参见第68页)]
我正在尝试在Fedora中安装带有-fPIC支持的GHC.我已经抓住了一个源tarball,因为它似乎没有二进制文件.
在Build.mk中,我已将快速构建类型更改为
ifeq "$(BuildFlavour)" "quick"
SRC_HC_OPTS = -H64m -O0 -fasm -fPIC
GhcStage1HcOpts = -O -fasm -fPIC
GhcStage2HcOpts = -O0 -fasm -fPIC
GhcLibHcOpts = -O -fasm -fPIC
SplitObjs = NO
HADDOCK_DOCS = NO
BUILD_DOCBOOK_HTML = NO
BUILD_DOCBOOK_PS = NO
BUILD_DOCBOOK_PDF = NO
endif
不幸的是,在编译时我仍然得到ld错误
ghc -fglasgow-exts --make -shared -oHs2lib.a /tmp/Hs2lib924498/Hs2lib.hs dllmain.o -static -fno-warn-deprecated-flags -O2 -package ghc -package Hs2lib -i/home/phyx/Documents/Haskell/Hs2lib -optl-Wl,-s -funfolding-use-threshold=16 -optc-O3 -optc-ffast-math
Linking a.out ...
/usr/bin/ld: /tmp/Hs2lib924498/Hs2lib.o: relocation R_X86_64_32 against `ghczmprim_GHCziUnit_Z0T_closure' can not be used when making a shared object; …我做make时遇到这个错误:
relocation R_X86_64_32 against `vtable for Torch::MemoryDataSet' can not be used
when making a shared object; recompile with -fPIC
它说我应该重新编译-fPIC选项.我这样做,将-fPIC选项添加到CFLAGS和CXXFLAGS,但我仍然得到相同的错误.有什么方法可以解决这个问题吗？我已经看到这个问题与使用64位机器有关,而且我确实使用了一个.
我在针对lapack编译numpy库时遇到链接错误,表明我需要使用-fPIC编译lapack.我以为我做到了那一点.有没有办法确定生成的lapack库是否与位置无关？