Undefined symbol "__cpu_model" in librenderdoc.so

[Corralx]

Using GCC 6.1.1 on Fedora 24 I can compile RenderDoc and all of its target just fine, but as soon as I start QRenderDoc I get the following error:
qrenderdoc: symbol lookup error: /home/mbertello/Projects/renderdoc/build/bin/librenderdoc.so: undefined symbol: __cpu_model

This is apparently an issue since GCC 5.4 because those symbol are now hidden.
To fix this issue one can simply explicitly links against libgcc which provides the needed symbols.

I have attached a patch with the fix for this issue.
gcc6_patch.txt

Matteo

[baldurk]

From google it seems like this is a bug in GCC 5 and should be fixed in GCC 6, although it's not entirely clear. Do you know when this behaviour will be fixed?

I'm a little hesitant to add a workaround for a compiler bug without understanding what impact it would have on forward/backward compatibility. At least I presume it would need to be limited to only builds with gcc (not clang), but will it work fine on older GCC versions, or newer? There's also the issue that making binaries to distribute on linux is dicey enough already, and I don't know what the ABI compatibility implications are of linking directly to libgcc.

[Corralx]

I've read it should be fixed in GCC 6 too, but I'm using GCC 6.1.1 as of now and the symbol is still hidden.
Afaik libgcc is always linked by default by GCC, if you don't specify -nostdlibs or -nodefaultlibs. This is because it contains several subroutines needed by the tipical application or common languages like C++.
The difference is that g++ will try to tipically link against the shared version, instead of the static one that is the preferred choice for gcc.
This is needed if you want to throw/catch exceptions crossing the library boundaries, otherwise linking statically is perfectly fine.
You are correct stating that those changes should be applied only to GCC and not to Clang, tho.
Another option (probably more safe and "correct") instead of explicitly linking libgcc.a, is to ask the compiler to link the static version for us using the -static-libgcc flag.

Matteo

[baldurk]

Right, GCC will link in libgcc when necessary automatically which is why the bug is a weird one. But I'm not sure what exactly will happen if libgcc is linked in explicitly, or if that will cause portability/clash issues when compiled on one distribution and run on another. I'm just a little concerned about understanding the potential impact of a change like that before making it.

Tracing back the problem it seems like the bug is triggered from a call to __builtin_cpu_supports in stb_image.h. This is used to check if SSE2 is present on GCC > 4.8.

Given that on linux I only really plan to ever support x64 builds, and x64 CPUs are all SSE2, I will try just changing this function so that it returns 1 on x64 and (just for safety) returns 0 on x86.

That way hopefully we avoid invoking the GCC bug but without any serious fallout elsewhere.

[Corralx]

This looks fine (and safe) to me.
Thanks for the quick answer.

[baldurk]

Applied the fix in 953ebe0 which accidentally referred to the wrong issue. It all compiles and runs for me though - please let me know if it does for you as I was testing on gcc 5.4 on ubuntu.

[Corralx]

Thanks for the quick fix, can confirm that it is working fine on Fedora 24 using GCC 6.1.1.