SFML community forums
General => General discussions => Topic started by: Silvah on September 06, 2010, 12:25:33 am
-
I think I'm posting in appropriate place, please move it if I'm wrong.
As we all (?) know, SFML (I'm talking about version 1.6 here) uses standard C++ locales in some places. And we all (???) know that libstdc++ (the standard C++ library that comes by default with GCC) is inherently broken, because its support for locales is virtually nonexistent on Windows (Cygwin does not count). So, SFML has some workarounds here and there just because of that.
The problem lies in checking if we have a working locales - it's done by checking whether __MINGW32__ (I'm not sure how this macro is called) exists, and if it does, then the library assumes that locales are broken.
This approach seemed to work just fine hitherto. However, the idyllic world shattered when I tried to compile SFML with STLPort as a standard C++ library, rather than the default libstdc++. Of course, SFML thought that I don't have working locales and workarounds were compiled instead. I do have working locales, why not use them?
My question is: can SFML check the standard library itself instead of relying on just a compiler check in order to test for locales? Of course, it is certainly possible for a user to modify these checks manually (or simply delete them), but it's not very convenient solution, as it has to be done for each new version of the library.
Yours faithfully,
Silvah.
-
My question is: can SFML check the standard library itself
Apparently, yes:
http://predef.sourceforge.net/prelib.html#sec9
I'll see if it works as expected.
-
Well, maybe you can check before I make the modification, as you already have everything setup to do the tests :)
Can you replace these lines
#ifdef __MINGW32__
With this:
#if defined(SFML_SYSTEM_WINDOWS) && (defined(__GLIBCPP__) || defined (__GLIBCXX__))
...and see if it works as expected?
-
I've tested it right now, unfortunately it does not work:
G:\sfml\src\SFML\System >> g++ -c unicode.cpp -IG:/sfml/include -o - # original source
Assembler messages:
Fatal error: can't open a bfd on stdout -
G:\sfml\src\SFML\System >> g++ -c unicode.cpp -IG:/sfml/include -o - # changed the condition and added an #error there
In file included from G:/sfml/include/SFML/System/Unicode.hpp:285:0,
from unicode.cpp:28:
G:/sfml/include/SFML/System/Unicode.inl:34:8: error: #error libstdc++ detected
After looking at the list of files being included, it's easy to see that STLPort depends on the previous standard library (libstdc++ in this case), mainly on the "new" C library headers (cstdlib, cstddef and so on), and some of them in turn include bits/c++config.h, which defines __GLIBCXX__, even though we're not using libstdc++ anymore.
-
If STLPort includes the standard library of the compiler, I don't see how to properly detect that. I could detect STLPort directly, but then I would have to do the same for all other STLs, and it would become messy... :?
-
According to boost, no other standard library sits on top of another standard library, thus it's safe to check for STLPort first (__SGI_STL_PORT or _STLPORT_VERSION will be defined), and if the check fails, then check for other standard libraries.
-
According to boost, no other standard library sits on top of another standard library
Where did you find that?
thus it's safe to check for STLPort first (__SGI_STL_PORT or _STLPORT_VERSION will be defined), and if the check fails, then check for other standard libraries
If no other SL sits on top of another SL, wouldn't it be safe to simply check for "glibc++ && !stlport"?
-
Where did you find that?
boost/config/select_stdlib_config.hpp
If no other SL sits on top of another SL, wouldn't it be safe to simply check for "glibc++ && !stlport"?
It's what I meant :) "The other standard libraries" are (is?) libstdc++ in our case :)
-
boost/config/select_stdlib_config.hpp
Ah! Yesterday I searched into the boost headers for this thing, and I couldn't find it.
It's what I meant :) "The other standard libraries" are (is?) libstdc++ in our case
Ok, I misunderstood your first answer :)
So, can you make sure that everything works as expected before I commit the modification?
#if defined(SFML_SYSTEM_WINDOWS) && (defined(__GLIBCPP__) || defined (__GLIBCXX__)) && !(defined(__SGI_STL_PORT) || defined(_STLPORT_VERSION))
... workaround
#endif
-
I did the same thing as before, this time #error didn't fire, so... it works :)
By the way, how your name is pronounced? ;)
-
I did the same thing as before, this time #error didn't fire, so... it works
Great :)
By the way, how your name is pronounced?
Hum... how can I tell you that? Just pronounce it like you want ;)
-
Ahem, when the fix will be committed? ;)
-
Done.