Tag: fpic

全局变量，共享库和-fPIC效果

我制作了一段代码，它包含一个动态库（ lib.c ）和一个主可执行文件（ main.c ）。 在这两个文件中，我定义了一个名为： int global的全局变量。 不是很聪明，但这不是问题。 当我编译动态库时， -fPIC选项似乎是强制性的： gcc lib.c -fPIC -shared -o lib.so 否则我得到： /usr/bin/ld: /tmp/ccpUvIPj.o: relocation R_X86_64_32 against ‘.rodata’ can not be used when making a shared object; recompile with -fPIC 当我编译可执行文件时，它不是。 gcc main.c -fPIC -ldl gcc main.c -ldl 两者都有效，但有不同的行为，我无法解释，是吗？ ： 使用-fPIC，main.c中的global和lib.c中的global是相同的变量： global main: 23 (0x601050) global lib: 23 (0x601050) […]

将共享库与静态库链接：静态库的编译方式必须与应用程序链接它的方式不同吗？

至少在Linux和Solaris上，静态库实际上只是一堆编译好的.o文件被扔进一个大文件中。 编译静态库时，通常会忽略-fpic标志，因此生成的代码与位置有关。 现在说我的静态库是B.我已经构建了它并且得到了.a文件，它实际上只是所有位置相关的.o文件的全局。 现在我有一个我想构建的共享库，A，我希望它静态链接B.当我构建A时，我自然会使用-fpic标志使生成的代码位置独立。 但是，如果我链接B，我不是混合位置依赖和位置独立的目标文件？ 除非我还指定-mimpure-text，否则我会收到很多文本重定位错误，我认为这可能是原因。 看来，当我编译一个库时，我真的需要编译它3次，共享版本，静态版本和静态 – 可以使用的共享库版本。 我对吗？ 我可以继续使用-mimpure-text但g ++手册页说如果你这样做，对象实际上并没有最终被共享（不清楚它是否全部未被共享，或者仅仅是静态链接的部分，有人知道吗？） 。

共享库和.h文件

我对程序如何使用共享库有一些疑问。 当我构建一个共享库（使用-shared -fPIC开关）时，我可以从外部程序中获取一些函数。 通常我会使用dlopen（）来加载库，然后使用dlsym（）将所述函数链接到某些函数指针。 此方法不涉及任何.h文件。 有没有办法避免做dlopen（）和dlsym（），只包括共享库的.h？ 我想这可能是c ++程序如何使用存储在系统共享库中的代码。 即仅包括stdlib.h等