[SOLVED] Weird error in sf::Font initialization

[Anrock]

@Nexus,
Reordering libs gives no effect.
SFML_LIBRARIES contain /usr/local/lib64/libsfml-graphics.so/usr/local/lib64/libsfml-window.so/usr/local/lib64/libsfml-system.so
Minimal example was compiling with -g and -O0 already.


Now things i did (note it's 4:49 am here, maybe i missed something):
1. I removed libsfml package in my package manager, deleted libsfml* in usr/local/lib64. Installed libsfml back in package manager. To get a fresh start, yeah.

2. Rerunned cmake and somehow it still find libsfml in /usr/local/lib64. Of course build failing as there is no such files. I've exported SFML_ROOT=/usr/lib64/ where .so really are. Cmake still finds libsfml in /usr/local/lib64.

3. Okay, i'll try other way. Commented out lines with find_package and related checks, replaced target_link_libraries with that:

target_link_libraries("Test" /usr/lib64/libsfml-graphics.so
        /usr/lib64/libsfml-window.so /usr/lib64/libsfml-system.so)

to eliminate any FindSFML module influence.

With libs specified explicitly, font initialised fine.

I guess i had leftovers of libsfml 1.6 in /usr/local/lib64 and at the same time FindSFML wasn't checking /usr/lib sticking to /usr/local/lib instead and linking with libs of 1.6 version. Now leftovers gone and i'm sure libs installed are fine and not corrupted and code okay and cmake okay too. FindSFML is probably guilty of all that, what do you think? 

[Nexus]

It's indeed not ideal, but I wonder whether FindSFML can do something about it.

In general, CMake is a bit annoying when it comes to maintaining/deleting state, you have to explicitly clear the cache (and sometimes even more) when you reconfigure an existing CMakeLists.txt and want to link to different libraries.

Is there a mechanism to check binary compatibility of a SO library other than just having undefined behavior? The API and implementation of SFML 1.6 and 2.x differ so massively that nothing can possibly go right, and with static libraries you would have immediately noticed the error, because the linker wouldn't even find the symbols...

[Anrock]

@Nexus, i mean, FindSFML.cmake doesn't even check that lib-files exist. Does it just assemble library path based on include path instead of actually looking for libs?

[Laurent]

No, it does search for the files, and reports an error if they are not found. That's of course upon the initial configuration; when the CMake cache is populated, and you change things in your file system, everything is messed up and you must clear the CMake cache and restart.

[Anrock]

Ah yes, cache! Now works.