Does not compile on OSX with Base SDK 10.9

[martinpfannemueller]

Using Xcode on Mac OSX 10.9 with base SDK 10.9 I get the following error. With base SDK 10.8 everything works.

Undefined symbols for architecture x86_64: "sf::SoundBuffer::LoadFromFile(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&)", referenced from: OT::SoundManager::load(OT::Path, sf::SoundBuffer&) in SoundManager.o "sf::Font::LoadFromFile(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, unsigned int, sf::Unicode::Text const&)", referenced from: OT::FontManager::load(OT::Path, sf::Font&) in FontManager.o "sf::Image::LoadFromFile(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&)", referenced from: OT::BitmapManager::load(OT::Path, sf::Image&) in BitmapManager.o "sf::Window::Create(sf::VideoMode, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, unsigned long, sf::WindowSettings const&)", referenced from: OT::Application::init() in Application.o "Rocket::Core::Element::GetElementsByTagName(std::__1::vector<Rocket::Core::Element*, std::__1::allocatorRocket::Core::Element* >&, Rocket::Core::StringBase const&)", referenced from: OT::ToolboxWindow::reload() in ToolboxWindow.o "sf::SoundBuffer::SaveToFile(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&) const", referenced from: OT::SimTowerLoader::dump(OT::Path) in SimTowerLoader.o "sf::Image::SaveToFile(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&) const", referenced from: OT::SimTowerLoader::dump(OT::Path) in SimTowerLoader.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation)

[fabianschuiki]

I haven't tried Mavericks yet, but it seems like the SFML binary is missing the x86_64 architecture. Why the base SDK would have an influence on the SFML version being linked is beyond me.

Have you tried running the ci/ci_macosx.sh script? It installs most dependencies to a temporary location which work around the problem.

[martinpfannemueller]

I tried your build_macosx.sh script, which works perfectly fine until the same linking step. Only that now i386 is supposed to be missing. Very strange.

Linking CXX executable OpenSkyscraper.app/Contents/MacOS/OpenSkyscraper Undefined symbols for architecture i386: "sf::SoundBuffer::LoadFromFile(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&)", referenced from: OT::SoundManager::load(OT::Path, sf::SoundBuffer&) in SoundManager.cpp.o "sf::Font::LoadFromFile(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, unsigned int, sf::Unicode::Text const&)", referenced from: OT::FontManager::load(OT::Path, sf::Font&) in FontManager.cpp.o "sf::Image::LoadFromFile(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&)", referenced from: OT::BitmapManager::load(OT::Path, sf::Image&) in BitmapManager.cpp.o "sf::Window::Create(sf::VideoMode, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, unsigned long, sf::WindowSettings const&)", referenced from: OT::Application::init() in Application.cpp.o "sf::SoundBuffer::SaveToFile(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&) const", referenced from: OT::SimTowerLoader::dump(OT::Path) in SimTowerLoader.cpp.o "sf::Image::SaveToFile(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&) const", referenced from: OT::SimTowerLoader::dump(OT::Path) in SimTowerLoader.cpp.o ld: symbol(s) not found for architecture i386

[fabianschuiki]

Very peculiar, especially since there's only a small subset of functions missing. I'll give this a spin as soon as I upgrade to Mavericks.

[mlegenhausen]

+1

[fabianschuiki]

I ran into the same issue after upgrading to Mavericks. Interestingly enough, the compiled binary available from openskyscraper.org works perfectly fine on Mavericks (compiled on a 10.8 machine). I'm curious why this handful of symbols is missing on the i386 architecture.