C++ fedora中静态和动态库的混合

关于如何混合二进制文件的动态链接和静态链接，已经有了一些答案。 就像我读到的anwers一样，我编译如下：

gcc main.cpp -static-libstdc++ -static-libgcc -Wl,-Bstatic -lm -lstdc++ -lpthread -lrt -lc -Wl,-Bdynamic -lmyshared_lib -L. libx.a liby.a

但是我得到了一个错误：

/usr/lib/gcc/i686-redhat-linux/4.7.2/../../../libpthread.a(libpthread.o): In function `sem_open':
(.text+0x6407): warning: the use of `mktemp' is dangerous, better use `mkstemp'
/bin/ld: dynamic STT_GNU_IFUNC symbol `strcmp' with pointer equality in `/usr/lib/gcc/i686-redhat-linux/4.7.2/../../../libc.a(strcmp.o)' can not be used when making an executable; recompile with -fPIE and relink with -pie
collect2: error: ld returned 1 exit status

第三方lib本身依赖于libc.so.6，因此我猜这与我的静态链接libc冲突。 如果我使用下面的-fPIE和-pie参数进行编译，应用程序会立即发生故障：

gcc main.cpp -fPIE -static-libstdc++ -static-libgcc -Wl,-Bstatic -lm -lstdc++ -lpthread -lrt -lc -Wl,-Bdynamic -lmyshared_lib -L. libx.a liby.a -Wl,-pie

它甚至可以编译几乎完全静态的对象，并且只额外链接一个共享对象吗

---

我之所以尝试这样做，是因为我想使用32位第三方共享对象在x64系统上运行一个特定的32位二进制文件…

1可能会有一个混合链接2似乎您正在尝试动态链接libx.a和liby.a静态库，可能会将它们移动到静态部分？3尝试将pthread移动到dynamic-这是一个非常复杂的问题。1没错2如果指定静态库的绝对路径，它将以静态方式链接。3多亏了这一点-如果我将pthread和libc移动到dynamic linking，我没有收到任何错误，但最初我想删除应用程序的那些DEP。再想一想，这没有多大意义，因为.so无论如何都有一个libc.so依赖项。