Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Locales, MinGW and SFML  (Read 4034 times)

0 Members and 3 Guests are viewing this topic.

Silvah

  • Guest
Locales, MinGW and SFML
« 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.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Locales, MinGW and SFML
« Reply #1 on: September 06, 2010, 08:25:10 am »
Quote
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.
Laurent Gomila - SFML developer

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Locales, MinGW and SFML
« Reply #2 on: September 06, 2010, 06:31:29 pm »
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
Code: [Select]
#ifdef __MINGW32__
With this:
Code: [Select]
#if defined(SFML_SYSTEM_WINDOWS) && (defined(__GLIBCPP__) || defined (__GLIBCXX__))
...and see if it works as expected?
Laurent Gomila - SFML developer

Silvah

  • Guest
Locales, MinGW and SFML
« Reply #3 on: September 06, 2010, 08:39:29 pm »
I've tested it right now, unfortunately it does not work:

Code: [Select]
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.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Locales, MinGW and SFML
« Reply #4 on: September 06, 2010, 10:13:36 pm »
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... :?
Laurent Gomila - SFML developer

Silvah

  • Guest
Locales, MinGW and SFML
« Reply #5 on: September 07, 2010, 04:54:39 pm »
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.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Locales, MinGW and SFML
« Reply #6 on: September 07, 2010, 05:11:18 pm »
Quote
According to boost, no other standard library sits on top of another standard library

Where did you find that?

Quote
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"?
Laurent Gomila - SFML developer

Silvah

  • Guest
Locales, MinGW and SFML
« Reply #7 on: September 07, 2010, 05:22:38 pm »
Quote from: "Laurent"
Where did you find that?
boost/config/select_stdlib_config.hpp

Quote
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 :)

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Locales, MinGW and SFML
« Reply #8 on: September 07, 2010, 06:13:55 pm »
Quote
boost/config/select_stdlib_config.hpp

Ah! Yesterday I searched into the boost headers for this thing, and I couldn't find it.

Quote
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?

Code: [Select]
#if defined(SFML_SYSTEM_WINDOWS) && (defined(__GLIBCPP__) || defined (__GLIBCXX__)) && !(defined(__SGI_STL_PORT) || defined(_STLPORT_VERSION))

    ... workaround

#endif
Laurent Gomila - SFML developer

Silvah

  • Guest
Locales, MinGW and SFML
« Reply #9 on: September 07, 2010, 06:41:48 pm »
I did the same thing as before, this time #error didn't fire, so... it works :)

By the way, how your name is pronounced? ;)

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Locales, MinGW and SFML
« Reply #10 on: September 07, 2010, 10:10:13 pm »
Quote
I did the same thing as before, this time #error didn't fire, so... it works

Great :)

Quote
By the way, how your name is pronounced?

Hum... how can I tell you that? Just pronounce it like you want ;)
Laurent Gomila - SFML developer

Silvah

  • Guest
Locales, MinGW and SFML
« Reply #11 on: September 08, 2010, 07:26:56 pm »
Ahem, when the fix will be committed? ;)

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Locales, MinGW and SFML
« Reply #12 on: September 08, 2010, 08:52:48 pm »
Done.
Laurent Gomila - SFML developer

 

anything