Bug#853394: extremetuxracer: ftbfs with GCC-7

[Marko Lindqvist]

On 31 January 2017 at 11:31, Matthias Klose <doko at debian.org> wrote:
> event.o: In function `CEvent::Enter()':
> ./src/event.cpp:160: undefined reference to `sf::String::operator std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >() const'
> ./src/event.cpp:166: undefined reference to `sf::String::operator std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >() const'
> ./src/event.cpp:170: undefined reference to `sf::String::operator std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >() const'
> game_over.o: In function `GameOverMessage(CControl const*)':
> ./src/game_over.cpp:91: undefined reference to `sf::String::operator std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >() const'
> ./src/game_over.cpp:97: undefined reference to `sf::String::operator std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >() const'
> game_over.o:./src/game_over.cpp:107: more undefined references to `sf::String::operator std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >() const' follow
> collect2: error: ld returned 1 exit status
> Makefile:474: recipe for target 'etr' failed
> make[3]: *** [etr] Error 1

 I see that error with g++7 on both etr-0.7 branch (where release used
by Debian is from) and development version. We saw similar problem on
etr development version with earlier version of clang++, but with
current Debian Testing (Stretch) etr development version compiles fine
with clang++. etr-0.7 branch does not compile with clang++ for
unrelated reasons.
 This seems like a sort of incompatibility problem between c++11
std::string and SFML string class. I don't know if we can do anything
to it in etr upstream. Could Debian accept a version that specifically
requires clang++ to be used, and cannot be compiled with g++7? There
is no such release at the moment, but etr-0.8 could be like that.
Another option is to just wait if g++8 will fix the problem, like
clang++ upgrade apparently did.


 - ML