Linking error with TGUI 0.8.6 on OSX using Clang

Started by N0things, 07 January 2020, 07:18:43

N0things

Hello,

I am currently making a little project using SFML (2.5.1) and TGUI (0.8, the current stable one) with CMake. I am building SFML and TGUI from sources before building my project, however I can't manage to build TGUI 0.8 correctly on OSX (macOS Mojave 10.14.6) using Clang.

I figured out that, by changing the branch from 0.8 to 0.7, TGUI compiles successfully. I can not get satisfied with this however because I am using some 0.8 features. Here is the piece of log that describes my error :


[ 95%] Linking CXX shared library ../../lib/libtgui.dylib
Undefined symbols for architecture x86_64:
  "std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::operator<<<char, std::__1::char_traits<char>, std::__1::allocator<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)", referenced from:
      tgui::operator<<(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, tgui::String const&) in String.cpp.o
  "std::__1::basic_ostream<wchar_t, std::__1::char_traits<wchar_t> >& std::__1::operator<<<wchar_t, std::__1::char_traits<wchar_t>, std::__1::allocator<wchar_t> >(std::__1::basic_ostream<wchar_t, std::__1::char_traits<wchar_t> >&, std::__1::basic_string<wchar_t, std::__1::char_traits<wchar_t>, std::__1::allocator<wchar_t> > const&)", referenced from:
      tgui::operator<<(std::__1::basic_ostream<wchar_t, std::__1::char_traits<wchar_t> >&, tgui::String const&) in String.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [lib/libtgui.0.8.6.dylib] Error 1
make[1]: *** [src/TGUI/CMakeFiles/tgui.dir/all] Error 2
make: *** [all] Error 2


I don't know if I did something wrong, but I developed this project few months ago and everything worked fine with TGUI 0.8 back in this time. Now, I just wanted to add a bit of continuous integration to the project with linux (works fine with Gitlab-CI) and osx (fails with Travis-CI).

Here is my Travis-CI log for OSX : https://travis-ci.com/matthieu-locussol/golPlayground/jobs/272932475, interesting log informations are under the (line 88) $ sudo ./INSTALL.sh command. The source code for my project is therefore on Github (you can access it using Travis) if you need to look at the CMake files / Installation file.

If you need any other information let me know, I am a bit desperate as I've been investigating this issue for a few days now. Thank you in advance for your time :)

texus

I test TGUI with a CI on mac and that build is still working: https://travis-ci.org/texus/TGUI/jobs/632626868
I'm not sure what the difference with your build is (and I don't have enough time to look at it right now), but maybe you can already check what you did differently which could narrow down the issue.

The String class is actually a class that shouldn't really have been added to 0.8. The file can't be removed, but almost none of these functions are used. So maybe you can also check if you can compile it if you put String.cpp#L2284-L2294 and String.hpp#L843-L844 in comments. I find it weird that it is giving a linking error for it though, that would imply that those operator<< functions are declared in the std headers but not in the standard library itself.

I'll try having a look at this tonight, but  I unfortunately no longer have a working mac VM to test on, so it might take a couple days before I can run tests here locally.

N0things

I followed your advice regarding the String class, I then made a patch to remove the useless methods and it is now working well, somehow.

Thanks for your help.

texus

I have solved the issue now in the latest 0.8 version that you can download from github.

I don't know why it gives a linking error for this instead of a compile error, but I was just missing an "ostream" include.

The reason why my CI tests never failed was because I am doing a unity build to speed things up and it must have gotten the ostream include via another source file.