Cannot install TGUI as STATIC library
« on: 09 April 2019, 16:58:06 »
Hi!
I managed to install TGUI as Dynamic Library on my Raspberry PI 386 Debian Linux.
But, DLL dependencies in Windows and .so dependencies in Linux I do not like. In the long run it creates a lot of support issues. Therefore, I try to install TGUI as STATIC library, i.e. making a .a file. But I am running into a problem when running "cmake ." on the TGUI 0.84 source. I get this message:

SFML found but some of its dependencies are missing ( xcb-image)
CMake Error at CMakeLists.txt:206 (message):
  CMake couldn't find SFML.

The problem, I think, is finding the libxcb_image.a library. The .so library files are there:

pi@raspberry:~/TGUI-0.8.4 $ locate libxcb-image
/usr/lib/i386-linux-gnu/libxcb-image.so.0
/usr/lib/i386-linux-gnu/libxcb-image.so.0.0.0

So my question is:
1: How can I get hold of a libxcb-image.a file?
2: Or perhaps I can do something else?

Regards,
Ingar Steinsland
ingar@labelcraft.net


Re: Cannot install TGUI as STATIC library
« Reply #1 on: 09 April 2019, 18:00:06 »
Hi again,

I have now come a bit further:

After 5-6 hours I finally found libxcb-image.a on the net in a .deb file. I manually copied into /usr/lib..
And then "cmake ." worked. But now I get this error when I run "make":

[ 95%] Built target tgui
[ 96%] Linking CXX executable gui-builder
/usr/local/sfml_251/lib/libsfml-window-s.a(WindowImplX11.cpp.o): In function `sf::priv::WindowImplX11::resetVideoMode() [clone .part.12]':
WindowImplX11.cpp:(.text+0x1a1c): undefined reference to `XRRQueryVersion'
WindowImplX11.cpp:(.text+0x1ac1): undefined reference to `XRRGetScreenResources'
.....
And a lit of undefined X functions.

I guess this is X11 not linked in. So somewhere in the many Makefile(s) I need to put "-lX11".
But the question is WHERE? These files are unreadable for me (I am fairly new in this game - previously
brainwashed by Microsoft...).

Any help appreciated.

Ingar

*

texus

  • *****
  • 1342
    • View Profile
    • Texus's Blog
Re: Cannot install TGUI as STATIC library
« Reply #2 on: 09 April 2019, 19:01:02 »
Quote
I managed to install TGUI as Dynamic Library on my Raspberry PI 386 Debian Linux.
Did you encounter any issues in doing this? It's been a few years since I tested TGUI on a Respberry Pi, so I'm interested to hear whether or not it still works without manual changes.

Quote
In the long run it creates a lot of support issues.
What kind of problems would you expect? I know it is possible to bundle the .so files with the application. It takes a lot of experimenting and you missed a file which causes it to break on newer linux systems several years later then you just need to ship that extra file. But I would consider the issues with .so files more on a short term, once you figure out how to do it properly it should continue to work on newer systems.

I've never build statically on linux so I can't help much. How did you get the other .a files? I'm not sure if they are all going to be compatible with each other when you download some random versions, but building them yourself is probably too difficult.

XRRQueryVersion and XRRGetScreenResources are part of the xrandr library. So maybe you have an incompatible libxrandr.a file or something?

I don't think this is specific to TGUI, if you reproduce it with only SFML then maybe you could ask it on their forum. Hopefully someone on the SFML forum would be able to help you further. You should try to make your own simple cmake project (which only uses SFML and not TGUI) and see if the issue still occurs, e.g. something like this:
cmake_minimum_required(VERSION 3.5)
project(CMake-test)

add_executable(Test main.cpp)

set(SFML_STATIC_LIBRARIES TRUE)
find_package(SFML 2 COMPONENTS graphics window system REQUIRED)
target_link_libraries(Test PRIVATE sfml-graphics)

*

texus

  • *****
  • 1342
    • View Profile
    • Texus's Blog
Re: Cannot install TGUI as STATIC library
« Reply #3 on: 09 April 2019, 19:09:56 »
I didn't notice earlier that your last error was after the TGUI library was already build. Try disabling TGUI_BUILD_GUI_BUILDER when building TGUI. In the cmake gui uncheck the option or in the command line pass -DTGUI_BUILD_GUI_BUILDER=FALSE
This might be a problem with how the gui builder is linked.

Update:
I just tested it here and I also get these errors when TGUI_BUILD_GUI_BUILDER is on (default). I'll look into it.
Disabling the TGUI_BUILD_GUI_BUILDER fixes the issue.

Update 2:
I figured out why the gui-builder is giving these undefined reference errors.

SFML radically changed their cmake script in SFML 2.5 but in order to remain compatible with older SFML versions I added a compatibility layer. Since SFML_DIR is not defined, TGUI is using it's own way to find SFML which was apparently broken for static linking. This has now been fixed in the latest version on github.

However it turns out that if the compatibility layer isn't used (by setting SFML_DIR to /usr/local/lib/cmake/SFML/ or wherever SFML is installed), it will give undefined references to GLX functions instead. I had to manually link to GLX to build statically. This does look like an issue with SFML itself. I'll try to investigate it further in the next few days.
« Last Edit: 09 April 2019, 20:10:31 by texus »

Re: Cannot install TGUI as STATIC library
« Reply #4 on: 11 April 2019, 10:51:52 »
Hi again,
As soon as I also did the dynamic SFML libraries, TGUI installed fine. Also the tgui-builder was made.


Quote
I managed to install TGUI as Dynamic Library on my Raspberry PI 386 Debian Linux.
Did you encounter any issues in doing this? It's been a few years since I tested TGUI on a Respberry Pi, so I'm interested to hear whether or not it still works without manual changes.

Quote
In the long run it creates a lot of support issues.
What kind of problems would you expect? I know it is possible to bundle the .so files with the application. It takes a lot of experimenting and you missed a file which causes it to break on newer linux systems several years later then you just need to ship that extra file. But I would consider the issues with .so files more on a short term, once you figure out how to do it properly it should continue to work on newer systems.

I've never build statically on linux so I can't help much. How did you get the other .a files? I'm not sure if they are all going to be compatible with each other when you download some random versions, but building them yourself is probably too difficult.

XRRQueryVersion and XRRGetScreenResources are part of the xrandr library. So maybe you have an incompatible libxrandr.a file or something?

I don't think this is specific to TGUI, if you reproduce it with only SFML then maybe you could ask it on their forum. Hopefully someone on the SFML forum would be able to help you further. You should try to make your own simple cmake project (which only uses SFML and not TGUI) and see if the issue still occurs, e.g. something like this:
cmake_minimum_required(VERSION 3.5)
project(CMake-test)

add_executable(Test main.cpp)

set(SFML_STATIC_LIBRARIES TRUE)
find_package(SFML 2 COMPONENTS graphics window system REQUIRED)
target_link_libraries(Test PRIVATE sfml-graphics)

Re: Cannot install TGUI as STATIC library
« Reply #5 on: 11 April 2019, 11:53:04 »
Hi again,

WORKED! Thanks a lot. :)

Ingar


I didn't notice earlier that your last error was after the TGUI library was already build. Try disabling TGUI_BUILD_GUI_BUILDER when building TGUI. In the cmake gui uncheck the option or in the command line pass -DTGUI_BUILD_GUI_BUILDER=FALSE
This might be a problem with how the gui builder is linked.

Update:
I just tested it here and I also get these errors when TGUI_BUILD_GUI_BUILDER is on (default). I'll look into it.
Disabling the TGUI_BUILD_GUI_BUILDER fixes the issue.

Update 2:
I figured out why the gui-builder is giving these undefined reference errors.

SFML radically changed their cmake script in SFML 2.5 but in order to remain compatible with older SFML versions I added a compatibility layer. Since SFML_DIR is not defined, TGUI is using it's own way to find SFML which was apparently broken for static linking. This has now been fixed in the latest version on github.

However it turns out that if the compatibility layer isn't used (by setting SFML_DIR to /usr/local/lib/cmake/SFML/ or wherever SFML is installed), it will give undefined references to GLX functions instead. I had to manually link to GLX to build statically. This does look like an issue with SFML itself. I'll try to investigate it further in the next few days.