如何解决系统和库依赖项之间的C ++冲突 [英] How to solve C++ conflicts between system and library dependencies

问题描述

我的问题比较具体，但请耐心等待. 最终这是一种反向工程，但是这个问题似乎更适合于此板.

My problem is rather specific, but bear with me. This in the end is kinda reverse engineering, but this problem in particular seems to fit more this board.

因此，我有一个为用C ++编写的MIPS编译的共享库.我没有lib的源代码. lib是使用GCC 4.3.3编译的.我想在运行基本OS的amd64计算机中使用此共享库中存在的功能.为此，我使用了源代码交叉编译器将一些C ++代码交叉编译为使用该对象的MIPS.

So, I have a shared object compiled for MIPS written in C++. I don't have the source code of the lib. The lib is compiled using GCC 4.3.3. I want to use functions present in this shared object in my amd64 computer running elementary OS. To do this, I used the sourcery cross compiler to cross compile some C++ code to MIPS, that would use this object.

到目前为止，除了一个编译错误(我无法弄清楚)以外，我已经对此进行了管理.该库称为libdvl.so，并用作libc.so.0依赖项(两者都与cpp代码位于同一文件夹中).

So far I managed this except for this one compile error, which I cannot figure out. The lib is called libdvl.so, and uses as dependency libc.so.0 (and both are in the same folder as the cpp code).

mips-linux-gnu-g++ -g -L/path/to/lib -Wl,-rpath,/path/to/lib -o verifier verifier.cpp -ldvl

这给了我

(...)/mgc/embedded/codebench/bin/../lib/gcc/mips-linux-gnu/4.9.1/../../../../mips-linux-gnu/bin/ld: warning: libc.so.0, needed by /path/to/lib/libdvl.so, may conflict with libc.so.6
(...)/mgc/embedded/codebench/bin/../lib/gcc/mips-linux-gnu/4.9.1/../../../../mips-linux-gnu/bin/ld: errno@@GLIBC_PRIVATE: TLS definition in (...)/mgc/embedded/codebench/bin/../mips-linux-gnu/libc/lib/libc.so.6 section .tbss mismatches non-TLS definition in /path/to/lib/libc.so.0 section .bss
/path/to/lib/libc.so.0: error adding symbols: Bad value
collect2: error: ld returned 1 exit status

所以我添加了"-l:libc.so.0"并得到了

So I added "-l:libc.so.0" and got this

(...)/mgc/embedded/codebench/bin/../lib/gcc/mips-linux-gnu/4.9.1/../../../../mips-linux-gnu/bin/ld: errno: TLS definition in (...)/mgc/embedded/codebench/bin/../mips-linux-gnu/libc/lib/libc.so.6 section .tbss mismatches non-TLS definition in libc.so.0 section .bss
(...)/mgc/embedded/codebench/bin/../mips-linux-gnu/libc/lib/libc.so.6: error adding symbols: Bad value
collect2: error: ld returned 1 exit status

有什么办法解决这个问题吗?我知道我正在使用GCC 4.9.1，但是我已经下载了使用GCC 4.3.154的旧代码源版本，并得到了完全相同的错误.

Any idea how to solve this? I know I am using GCC 4.9.1, but I already downloaded the older code sourcery version which uses GCC 4.3.154 and got the exact same error.

就像Lol4t0所说的那样，使用c ++ filt过滤后，它给出了来自stdc ++的实际函数名称.使用

EDIT 1: Exactly as Lol4t0 said, filtered using c++filt it gives an actual function name from stdc++. Using

mips-linux-gnu-g++ -g -L/path/to/lib -Wl,-rpath,/path/to/lib -I/path/to/lib -o verifier verifier.cpp -ldvl -l:libuClibc++.so.0 -l:libutil.so.0 -l:libc.so.0 -l:ld-uClibc.so.0 -nodefaultlibs

赋予libdvl自己的权限(因为我不会重写stdc ++:p)，我得到以下编译错误:

to give to libdvl its depencies (as I will not rewrite stdc++ :p), I get the following compile error:

(...)/mgc/embedded/codebench/bin/../lib/gcc/mips-linux-gnu/4.9.1/../../../../mips-linux-gnu/bin/ld: /tmp/cc66DLda.o: undefined reference to symbol '_Unwind_Resume@@GCC_3.0'
(...)/mgc/embedded/codebench/bin/../mips-linux-gnu/libc/lib/libgcc_s.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

我已经确认了lib依赖及其出现的顺序. 有什么想法吗?

I already confirmed lib dependencies and the order in which they appear. Any thoughts on this?

感谢所有帮助.

推荐答案

您正在针对GLIBC(libc.so.6)和其他libc(libc.so.0)进行链接.

You are linking against GLIBC (libc.so.6) and some other libc (libc.so.0).

这可能永远不起作用:您必须将所有内容编译并链接到单一，一致 libc.

That could never work: you have to have everything compiled and linked against a single, consistent libc.

由于您的libdvl.so用作依赖项libc.so.0，并且假设您无法重建libdvl.so，因此您必须使用针对libc.so.0的交叉编译器(可能是Dietlibc，或者uClibc)，并使用该工具链编译和链接其他所有内容.另一方面，您的交叉编译器似乎以GLIBC为目标，对您没有任何好处.

Since your libdvl.so uses as dependency libc.so.0, and assuming you can't rebuild libdvl.so, you have to use crosscompiler that targets libc.so.0 (which is possibly dietlibc, or uClibc), and compile and link everything else using that toolchain. Your crosscompiler on the other hand appears to target GLIBC, and will not do you any good.

经过大量的试验和错误，您也许可以使用不一致的版本链接最终的二进制文件，并且您的二进制文件甚至可能到达main(这是不太可能的).但是，这种二进制文件实际上可以正常工作的可能性很小.

After a lot of trial and error, you may be able to link the final binary using inconsistent builds, and your binary may even get to main (that is very unlikely). But chances of such binary actually working correctly are minuscule.

这篇关于如何解决系统和库依赖项之间的C ++冲突的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！