SFML community forums
Help => General => Topic started by: amhndu on June 01, 2016, 07:27:33 am
-
Compiling the library with SHARED=TRUE/FALSE works and the examples compile/run when built with SHARED=FALSE but when linked dynamically, the following error comes up:
/usr/bin/ld: opengl: hidden symbol `__cpu_model' in /usr/lib/gcc/x86_64-linux-gnu/5/libgcc.a(cpuinfo.o) is referenced by DSO
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
examples/opengl/CMakeFiles/opengl.dir/build.make:111: recipe for target 'examples/opengl/opengl' failed
make[2]: *** [examples/opengl/opengl] Error 1
CMakeFiles/Makefile2:494: recipe for target 'examples/opengl/CMakeFiles/opengl.dir/all' failed
make[1]: *** [examples/opengl/CMakeFiles/opengl.dir/all] Error 2
This is pretty much the same error that comes up when linking any other SFML project.
g++ version: 5.3.1 (5.3.1-14ubuntu2)
-
It's unfortunately a bug in GCC 5.x (https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1568899). They say that it's fixed upstream and they'll most likely back-port it.
In the meantime there's this workaround (https://web.archive.org/web/20160509014317/https://gitlab.peach-bun.com/pinion/SFML/commit/3383b4a472f0bd16a8161fb8760cd3e6333f1782.patch) provided by someone in the comments.
-
Thanks, that worked!
As a side question/request, could we have a wiki page or something which details these kind of workarounds and gotchas for compiling SFML ? IIRC, I had to manually edit some header file (I think something related to std image...) under Ubuntu 15.04 ...
Also, are you guys not involved in packaging SFML 2.3 in the SFML repos ? It also had this same problem with dynamic linking and also all the header files it installed were `.h` instead of `.hpp`, that would break every SFML project.
-
The wiki is an open place, so anyone can start something like that. Thing is these kinds of bugs appear and disappear, thus having to maintain it can be a bit time consuming, plus in many cases it's rather hard to track down the actual issue or to differentiate between user error and actual bug. Also how far would one want to track third-party bugs? ;)
-
The wiki is an open place, so anyone can start something like that. Thing is these kinds of bugs appear and disappear, thus having to maintain it can be a bit time consuming, plus in many cases it's rather hard to track down the actual issue or to differentiate between user error and actual bug. Also how far would one want to track third-party bugs?
You are right, it could get tedious, but if there were already some base I will have no problem contributing, since I'm not sure how would I start such a page.
Also, my other question:
Also, are you guys not involved in packaging SFML 2.3 in the SFML repos ? It also had this same problem with dynamic linking and also all the header files it installed were `.h` instead of `.hpp`, that would break every SFML project.
-
Oh right, I forgot about the second question. No we're not involved in that. Do they really pack .h headers? That sounds quite odd.
What package did you actually use? libsfml-dev for example (http://packages.ubuntu.com/yakkety/i386/libsfml-dev/filelist) comes with hpp headers on newer Ubuntu distributions.
-
That's odd.. xenial (http://packages.ubuntu.com/xenial/amd64/libsfml-dev/filelist) also lists hpps.. I could've sworn I saw .hs when I installed it. Although, I had already installed sfml using make before that, I found both .hpps and .hs in the include directory and after I removed the package, only the .hs were gone...
You know what, never mind this..
And thanks again for your help and indulging me
-
Is there any way to use this workaround with a command line build, eg
g++ main.o -lsfml-graphics -lsfml-window -lsfml-system -o a.out
Can I modify the above command to "make my sfml program link properly with g++5"?
-
This bug also shows up in g++-4.9 under ubuntu 16.04 by the way
-
This is still an issue with fresh Ubuntu 16.04.4, gcc 5.4.0, fresh clone of SFML. Error I get when running compiled example now is:
/usr/bin/ld: a.out: hidden symbol `__cpu_model' in /usr/lib/gcc/x86_64-linux-gnu/5/libgcc.a(cpuinfo.o) is referenced by DSO
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
Is there any fix for this? The CMakeLists.txt file no longer has the lines the aforementioned patch affects.
-
Have you tried adding -lgcc_s -lgcc to your linker command line?
-
I ended up grabbing g++-6 and using it to build SFML and my test project, that seems to work.