Generation of binaries compatible with most Linux distributions #38
Comments
|
I have spent a lot of time trying to get |
|
Hi! I'm having an issue running todds release binary I'm running it on Pop!_OS 22.04 LTS x86_64. I can compile and run the built target myself, but I want to get it work inside RimSort, which downloads the latest release from github. I find this issue and I know it is not easy to resolve, I'm wondering are there any solutions / ideas now about static linking with libstdc++? I personally tried to add the static linking flags to every target_link_libraries possible in the I could not verify this because I don't have a machine that I can test it on. ( On my machine it will always build with the correct ABI, but not sure if it's built somewhere else and run on my system. I want to know if those dependencies are purely from Boost and OpenCV, is it possible to run on my machine with the static linked built binary from another machine? ) I think the release binary is compiled using a VM in CentOS 7? Am I correct? |
|
@lisanhu Which todds release binary are you running? Is it https://github.com/todds-encoder/todds/releases/download/0.4.1/todds_Linux_x86_64_0.4.1.zip? If that is the case, what happens if you try with https://github.com/todds-encoder/todds/releases/download/0.0.0/todds_Linux_x86_64_0.0.0.zip? Regarding static linking, it is a very complex issue. My comments above are an incomplete summary of the different attempts I made at resolving this problem. Other attempts included using a musl based toolchain (see https://build-your-own.org/blog/20221229_alpine/ for details), building with increasingly newer Ubuntu versions starting at 14.04 LTS, and so on. As you mentioned, part of the difficulty comes from dependencies such as Boost and OpenCV. These are huge libraries with complex build systems that were developed long before these static linking solutions were developed. After all of the time I spent trying to fix this issue without success, I decided it was more cost-effective to just build using a relatively old Linux distro using vcpkg. vcpkg takes care of linking almost every dependency statically, while the old version of glibc provided by the Linux distribution that is dynamically linked against todds keeps compatibility as high as possible. The |
Yes, this is the version I was using.
It's still not working for me. And I realized both versions are reporting the same error messages, it's very strange to see behaviours like this. So I dig a little bit more into this and I realized that the release binaries are using new ABIs and my system is only supporting older versions. The system compiler on my system is gnu c++ 11, and glibcxx versions supported by my system is: The strings output for both 0.4.1 and 0.0.0: [ lisanhu@system76 : ~/Downloads/todds_Linux_x86_64_0.4.1 ]
todds_Linux_x86_64_0.4.1 $ strings todds | grep GLIBCXX_3.4.32
GLIBCXX_3.4.32
_ZSt21ios_base_library_initv@@GLIBCXX_3.4.32
[ lisanhu@system76 : ~/Downloads/todds_Linux_x86_64_0.4.1 ]
todds_Linux_x86_64_0.4.1 $ strings todds | grep GLIBCXX_3.4.31
GLIBCXX_3.4.31
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE15_M_replace_coldEPcmPKcmm@@GLIBCXX_3.4.31
[ lisanhu@system76 : ~/Downloads/todds_Linux_x86_64_0.4.1 ]
todds_Linux_x86_64_0.4.1 $ cd ../todds_Linux_x86_64_0.0.0/
[ lisanhu@system76 : ~/Downloads/todds_Linux_x86_64_0.0.0 ]
todds_Linux_x86_64_0.0.0 $ strings todds | grep GLIBCXX_3.4.31
GLIBCXX_3.4.31
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE15_M_replace_coldEPcmPKcmm@GLIBCXX_3.4.31
[ lisanhu@system76 : ~/Downloads/todds_Linux_x86_64_0.0.0 ]
todds_Linux_x86_64_0.0.0 $ strings todds | grep GLIBCXX_3.4.32
GLIBCXX_3.4.32
_ZSt21ios_base_library_initv@GLIBCXX_3.4.32 |
|
Thank you for looking into it! That information is very useful. I am seeing similar results after analyzing todds with As you mentioned, libstdc++.so.6 is bringing a newer glibc version; other libraries are using the expected, older version. The issue seems related to the problem mentioned in this StackOverflow post, where the prebuilt package of g++-13 brings in a version of libstdc++.so that requires a newer glibc version. I do not see any way around this issue except for replacing the g++ package with a self-compiled version built against an older glibc version. I also noticed that I forgot to answer your question about static linking and glibc. todds is linked statically against every dependency with just two exceptions, the C standard library (glibc) and the C++ standard library (in this case, libstdc++). In the case of libstdc++, this happens because it also uses glibc. In the case of glibc, dynamic linking is used because this library is not designed to be linked statically. Attempting to do so will generate a binary that fails to run in the best case, or has subtle bugs in the worst case. A more in-depth explanation can be found here: https://stackoverflow.com/questions/57476533/why-is-statically-linking-glibc-discouraged I am going to spend some additional time trying to find out another solution to this issue, there might be something I have not tried yet. If this fails, I will fall back to getting an older Ubuntu LTS and compiling all dependencies manually. |
|
Hi! Thanks for your reply! I just found this: https://stackoverflow.com/questions/13636513/linking-libstdc-statically-any-gotchas The choosen answer suggested a different approach (in the last paragraph): include the libstdc++.so with the binary, and use RPATH to make sure the linker is linking to relative path. I think this might be a better and easier solution? |
|
That included libstdc++.so file would still depend on the newer glibc version, as mentioned in one of the follow-up answers on that post (https://stackoverflow.com/a/13636770/7001854). |
|
@lisanhu I just realized that I was looking for glibc errors, while the errors you are experiencing are glibc++ errors; I am sorry about the confusion. In this case the solution you suggest should work, as long as I can coerce vcpkg to statically link against libstdc++. I will investigate more into this and try to generate a binary that does this. |
|
While searching for ways to make vcpkg handle and respect the A similar issue happens with distributing libstdc++.so. Although distributing a dinamically linked GPL file along with a MPL2 binary seems to be allowed, if I am understanding the legalese language correctly then the GPL would require me to also distribute the source of libstdc++.so as well. In principle I am not opposed to relicensing todds under the terms of the GPL but it is something I need to consider. Besides thinking about the pros and cons, this will involve checking every dependency for GPL compatibility and so on. All of these are quite complex factors that will require some time to think about on my part. For now I would recommend trying to self-compile todds and using the resulting binary to replace the one provided by RimSort. |
|
Thanks for your reply! Yes, license could be really tricky. I think that, for GPL as long as you didn't modify libstdc++.so, and include it (the binary not the source) exactly as it is, it should be fine, which is the case for QT. Also QT is doing dual licensing, and the user can choose either GPL or commercial license. I'm not an expert of GPL, just hope this information might help. No worries about my case, I can compile and run it on my system. Really thank you for your help! |
Since todds supports static builds, it is possible to generate a binary that contains all of the dependencies. The remaining issue has always been glibc. So far, we have been building binaries using increasingly older Linux distributions, in the hopes of finally finding a combination that works for everyone.
This is time consuming, as it requires setting up a new VM and figuring out how to compile todds in that case. Also, lately we have been reaching a point where using even older distros would mean switching from GCC 13 to older versions, which could potentially cause performance impacts. We need an alternative which addresses these problems.
One potential way to address all of this would be to use crosstool-ng. This is explained in the "Setup 2" part of this excellent Stackoverflow response: https://stackoverflow.com/a/52550158
This setup should give us freedom to choose which glibc version to use without requiring a VM.
The text was updated successfully, but these errors were encountered: