Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 3 years ago.
Improve this question
I'm trying to port a simple program code.cpp linked to a couple of shared libraries libA.so and libB.so from my personal computer (running up-to-date Arch Linux installation) on a machine with Ubuntu 16.04 LTS. Compiling the libraries works just fine, but I get a lot undefined reference errors when compiling code.cpp.
I suspect this is being caused by the fact that libA.so is linked to libB.so, and while both libA.so and libB.so compile OK on Ubuntu 16.04, strangely libA.so does not get linked against libB.so, despite the compilation flag -lB, which in turns causes undefined references when generating the binary. On the other hand, on Arch Linux libA.so does get linked against libB.so, or so ldd tells me.
I initially though the problem could be mismatched GCC versions, but even after installing and using GCC 8 on Ubuntu 16.04 the problem persists.
No one guarantees the complete compatibility not only between different Linux distributions, but even between different versions of the same Linux distribution. There was an attempt to unify it called LSB, but unfortunately it failed dramatically.
Different C++ compilers often have incompatible C++ libraries. This is also a big pain.
I will strongly recommend to recommend you to recompile everything on the target platform.
There is ambiguity about loading shared libraries. For some systems if you link a library A which is linked with library B will make symbols of the library B available for your program. For some systems it is not so.
Related
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 5 years ago.
Improve this question
I'm trying to create a C++ application with SFML. Followed the tutorial, installed MinGW for Windows. My project has a main.cpp file in its root folder, and SFML is included in lib/sfml (relative to main.cpp).
I can compile without problems with the command g++ -c main.cpp -g -o build/debug/game.o -Ilib/sfml/include
But I get undefined references when I try to link wit the command g++ build/debug/game.o -o build/debug/game.exe -Llib/sfml/lib -lsfml-graphics-d -lsfml-window-d -lsfml-system-d
Some of the errors:
C:\Users\andre\Documents\Repos\Game/main.cpp:5: undefined reference to `_imp___ZN2sf6StringC1EPKcRKSt6locale'
C:\Users\andre\Documents\Repos\Game/main.cpp:5: undefined reference to `_imp___ZN2sf9VideoModeC1Ejjj'
C:\Users\andre\Documents\Repos\Game/main.cpp:5: undefined reference to `_imp___ZN2sf12RenderWindowC1ENS_9VideoModeERKNS_6StringEjRKNS_15ContextSettingsE'
I've searched already and nothing seems to help me. What I found strange is that in some previous versions of SFML it came with more libs inside the lib folder, like opengl32.lib. Still, it says that, for example, sfml-graphics I need:
sfml-window-s.lib
sfml-system-s.lib
opengl32.lib
freetype.lib
jpeg.lib
The only one missing is opengl32.lib. If I consider sfml-system and sfml-window, it is missing too winmm.lib, gdi32.lib. I don't know if this has something to do with the errors, but any help is welcome.
Solved, my mistake. I downloaded some days ago the SFML version for Visual C++ compiler, but then I gave up on Visual Studio 2017 and decided to use Visual Studio Code with GCC. So I tried to use the SFML I had thinking it was the right one. Now I've downloaded the right version and it is working perfectly.
If you're linking the static version of SFML, SFML's header files have to know about this (since the function signature changes slightly). As such you'll have to define SFML_STATIC somewhere before you include any SFML header, ideally as part of your project, make files, or build system.
In addition, you'll have to make sure to link the proper versions of the libraries and those you actually want to use.
As an example for the system library:
sfml-system is the shared release build of the library.
sfml-system-d is the shared debug build of the library.
sfml-system-s is the static release build of the library.
sfml-system-s-d is the static debug build of the library.
You'll only have to link SFML's dependencies (such as OpenGL), if you're linking the static version of SFML.
SFML never shipped with OpenGL, you're probably confusing it with OpenAL-soft. Either way, the additional library files you're missing are either provided by your toolchain/system (like OpenGL or mmsystem) or can be found precompiled in SFML's extlibs/libs folder (depending on whether you've downloaded or compiled SFML yourself).
I am trying to get my program working in another machine where libstdc++ versions is different. I am developing and compiling it on netbeans. I have specified the option -static-libstdc++ but the program continues trying to load libstdc++.so.6 in the local machine.
How can I get a fully static libstdc++ link?
Thanks.
Not sure of the exact circumstances here, but I ran into a similar problem just now with different versions of Mac OS X and gcc. I worked around it by copying the actual dylib I wanted into the same directory as the executable and changing DYLD_LIBRARY_PATH to have it search there first before /usr/lib.
I wrote some custom c++ code and it works fine in ubuntu, but when I upload it to my server (which uses centos 5) its fails and says library is out of date. I googled all around and centos cannot use the latest libraries. How can I compile against the stl so that it is included in the binary and it doesn't matter that centos uses an old library?
P.S. I don't want to upload the source to the server and compile there.
In your linking step, you can simply add the "-static" flag to gcc:
http://gcc.gnu.org/onlinedocs/gcc-4.4.1/gcc/Link-Options.html#Link-Options
You may install on your Ubuntu box the compiler that fits the version of the library on your server.
You may ship your application with libstdc++.so taken from the system you compiled it at, provided you tune the linking so it gets loaded instead of centos' one.
You may compile it statically. To do this, you should switch your compiler from g++ to
gcc -lgcc_s -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic
Choose whatever you like. Note that approaches (2) and (3) may arise the problem of dependencies: your project (particularly, the stdc++ implementation that, being statically linked, is now a part of your app) may require some functions to present in the system libraries on centos. If there are no such functions, your application won't start. The reason why it can happen is that ubuntu system you're compiling at is newer, and forward compatibility is not preserved in linux libraries.
Can an application depend on two different versions of libstdc++ at the same time? (e.g.: libstdc++5 and libstdc++6)? The scenario being - some binary depends on libstdc++ 6 but loads an .so that depends on libstdc++5...
Will that have any chance of working?
Most importantly, you need to check if those two versions of the library are binary compatible or not. G++ 3.3 and 3.4 are not, for example.
And even if they are:
* There can be name mangling issues
* You cannot do cross module allocation/deallocation (a bad idea anyway)
* You probably can't work around modules with STL
I just recently ported a C++ application from AS3/GCC323 to AS4/GCC346. Although the app itself linked to libstdc++.so.6 some of the libraries it linked to were still linking to libstdc++.so.5. Depsite building successfully it SEGV'ed when i tried to run it.
Once I recompiled the libraries on AS4/GCC346 as well, the app and the libraries only linked to libstdc++.so.6 and the SEGV's no longer occurred.
So i would say the answer is no you can't link to both.
Jon
I've been trying to move a project over from Xcode to Linux (Ubuntu x86 for now, but hopefully the statically-linked executable will run on an x86 CentOS machine? I hope I hope?). I have the whole project compiling but it fails at the linking stage-- it's giving me undefined references for all functions defined by IPP. This is probably something really small and silly but I've been beating my head over this for a couple days now and I can't get it to work.
Here's the compile statement (I also have a makefile that's generating the same errors):
g++ -static
/opt/intel/ipp/6.0.1.071/ia32/lib/libippiemerged.a
/opt/intel/ipp/6.0.1.071/ia32/lib/libippimerged.a
/opt/intel/ipp/6.0.1.071/ia32/lib/libippsemerged.a
/opt/intel/ipp/6.0.1.071/ia32/lib/libippsmerged.a
/opt/intel/ipp/6.0.1.071/ia32/lib/libippcore.a
-pthread -I /opt/intel/ipp/6.0.1.071/ia32/include
-I tools/include -o main main.cpp pick_peak.cpp
get_starting_segments.cpp
get_segment_timing_differences.cpp
recast_and_normalize_wave_file.cpp
rhythm_score.cpp pitch_score.cpp
pitch_curve.cpp
tools/source/LocalBuffer.cpp
tools/source/wave.cpp distance.cpp
...and here is the beginning of the long list of linker errors:
./main.o: In function `main':
main.cpp:(.text+0x13f): undefined reference to `ippsMalloc_16s'
main.cpp:(.text+0x166): undefined reference to `ippsMalloc_32f'
main.cpp:(.text+0x213): undefined reference to `ippsMalloc_16s'
Any ideas? FWIW, these are the IPP dependencies in my Xcode project that builds, links, and runs without a problem: "-lippiemerged",
"-lippimerged",
"-lippsemerged",
"-lippsmerged",
"-lippcore",
Thanks!
Your linking problem is likely due to the fact that your link line is completely backwards: archive libraries should follow source and object files on command line, not precede them. To understand why the order matters, read this.
Also note that on Linux statically linked executables are significantly less portable than dynamically linked ones. In general, if you link system libraries dynamically on an older Linux system, it will work on all newer systems (I use ancient RedHat 6.2, and I haven't seen a system on which my executable will not run). This is not true for completely static executables; they may crash in all kinds of "interesting" ways when moved to a system with a different libc from the one against which they were linked.
I had problems with linking code with the v 6 of the ipp; using the v11 version of the compiler (with the included updates to the ipp) mysteriously fixed them. Granted, that was with a windows platform, but I was getting 8u versions of functions to compile and no 32f versions, despite both being listed as valid in the documentation.