[Solved]build won't read symbols from libX11.so

[bvanevery]

I'm building both CEGUI 0.8.2 and also the repo version, on Ubuntu 13.04 (Linux). I disabled CEGUI_SAMPLES_USE_DIRECTFB to work aroud 2 build bugs I previously reported. I enabled CEGUI_SAMPLES_USE_OPENGL3 because that's what I'm interested in developing. Inexplicably, the samples cannot find libX11.so. This is a library so fundamental and basic to everything working right, that I'm wondering if nobody is doing any test coverage for Linux releases.

Either that, or, this is some kind of Debian "multiarch aware" issue? Please note the /usr/lib/x86_64-linux-gnu/ directories in the output. This is where the libs are supposed to live nowadays on a 64-bit Debian system, and builds that assume other things for other distros are known to cause problems. I don't know if this is the actual problem, I'm making a totally unsubstantiated and unresearched guess. CMake has X11_X11_LIB set correctly to /usr/lib/x86_64-linux-gnu/libX11.so.

Or is it specific to CEGUI_SAMPLES_USE_OPENGL3 ? Another guess.

Or can my libX11.so have weirdness due to NVIDIA driver (mis)configuration? Another guess.

Code: Select all

Linking CXX executable ../bin/CEGUISampleFramework-9999.0
/usr/bin/ld: /usr/local/lib/libglfw.a(x11_window.o): undefined reference to symbol 'XSetWMHints'
/usr/bin/ld: note: 'XSetWMHints' is defined in DSO /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libX11.so so try adding it to the linker command line
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libX11.so: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
make[2]: *** [bin/CEGUISampleFramework-9999.0] Error 1
make[1]: *** [samples_framework/CMakeFiles/CEGUISampleFramework-9999.0.dir/all] Error 2
make: *** [all] Error 2
bvanevery@nomad:~/devel/build/cegui$


[Kulik]

DirectFB is known to be broken, nobody wants to maintain it and we probably should have dropped it from the release.

You make a lot of assumptions, let me dispel some of them:
- the CEGUI team is using GNU/Linux, namely Fedora (me) and Debian (CrazyEddie)
- therefore, we do a lot of testing there
- NVIDIA binary blob doesn't do anything to libX11.so

I don't think it's a multiarch issue, in fact, the linker tells you that undefined ref is in /usr/local/lib/libglfw.a. The error is not coming from CEGUI but from glfw of unknown origin.

[bvanevery]

Ok that's good to know about your Linux developmet, and you're right, my home-built GLFW must suck. I was flustered by the DirectFB errors and simply didn't notice. Looks like I didn't do BUILD_SHARED_LIBS when I built GLFW, and providing them wasn't the default. I find that odd, but I know it's a common practice. I think it's better for a lib to build both shared and static libs and install both, but that's not the GLFW drill. Got GLFW 3.0.1 shared installed now. Will rebuild CEGUI 0.8.2 and see what happens.

I am not surprised about DirectFB and deduced lack of support / interest in that as one of the possible explanations, not lack of Linux development per se. What *does* surprise me greatly though, is why a default Linux CMake build of 0.8.2 would offer to build the DirectFB samples if they don't basically work. They do block "make install" from working. Perhaps you guys test on Linux plenty, but you didn't test the "pure out of the box" 0.8.2 release candidate on a machine that has DirectFB, with CMake cache files deleted and such? I could see that happening if nobody really cares about DirectFB, although it would be a bad build practice. CEGUI_SAMPLES_USE_DIRECTFB is defined by default in both 0.8.2 and the Mercurial repository, so if DirectFB sample bugs are going to be allowed to live, then this setting should be turned off.

Ok, I had to drop GLFW back to version 2.7.2, the standard package in Ubuntu 13.04. CEGUI doesn't support GLFW 3.x at present. Things build now though.