SFGUI (0.4.0 released)

[binary1248]

I can't use GCC 4.8+ (bug with one library I use)

And that bug would be...? I highly doubt that it is GCC's fault. If it is released, then it is in a really stable state. If this library you use is open source you could try to fix the problem yourself, or if the developers care enough about GCC compatibility in case it is closed source you could try to convince them to fix the bug.

Not being able to use a standard conforming compiler because some library doesn't work (anymore) must be one of the sadder reasons I've seen.

[Dragonic]

Little mistake ! With GCC 4.8+ it's not a problem with a library, but directly with my IDE >< !

I use Eclipse CDT and I tried many months ago but couldn't build a program with c++11 or c++0x activated with GCC 4.8+ (don't remember all the errors ^^, but because of that I switched to GCC 4.7.3) !
Maybe I can now try to rebuild everything with all the last versions !

Not being able to use a standard conforming compiler because some library doesn't work (anymore) must be one of the sadder reasons I've seen.

I can understand ! It's just that I'm really a beginner when it comes to Makefile, Lib, or everything else that don't work at first try ^^ !

[binary1248]

I don't know exactly when and with what version you last tried, but a simple search on Google showed that a lot of people were already able to get Eclipse CDT working with C++11.

https://www.google.com/search?q=Eclipse+CDT+GCC+4.8
http://wiki.eclipse.org/CDT/User/FAQ#CDT_does_not_recognize_C.2B.2B11_features

[Lolilolight]

I use code::blocks and c++11 works, Eclipse is a bit more complicated to use I think, because there are more menus.

The only inconvenient is that I have to switch of compilator if I want to compile in 32 bits or in 64 bits.
(With tdm-gcc the flag -m32 doesn't work, maybe there's another way to configure this with code::block but all the method I tested when I've checked on the forum didn't work so...)

I keep going to use two compilator. (tdm-gcc-32 and tdm-gcc-64 version 4.

Have you a 32 bits or a 64 bits compilators of tdm gcc ? (It's very possible that you have an incompatibility, I also had problems)

But What error messages did you have ?

[Dragonic]

But What error messages did you have ?

I don't remember, it was so much time ago ^^ !
But I'll see if there are any problem, I'll try to use the last version of MinGW and rebuild all the libs. It will take some time, so this weekend I think ^^ !

[Dragonic]

Well, already one problem with this new MinGW (GCC 4.8.1) installation :

- LibOVR (OculusRift SDK) : unrecognized command line option "-municode" when building (using Msys1.0)
I don't found the solution for now !

That's not the error I mentioned earlier !

EDIT : just tried to delete "-municode" to see what happen, and now it's "localtime_s was not declared in this scope" for one file of the lib (don't know if it's linked) ! Why is it always so complicated to build a lib >< ?

Sorry, this LibOVR has nothing to do with your SFGUI, but I really want to test and use your work ^^ ! And this first approach with the last MinGW distribution is not very pleasant ^^' !

Also I have a question about boxes design for SFGUI : we have to use images in order to use a special background ? If yes, does it have some kind of 9-patch (9-slice-scaling) support ?

[binary1248]

- LibOVR (OculusRift SDK) : unrecognized command line option "-municode" when building (using Msys1.0)
I don't found the solution for now !

The solution is... install the same kind of MinGW as you had before. -municode is a mingw-w64 flag which obviously won't be present on mingw32. You can't just replace something with something else just because it has a greater version number. MinGW is, believe it or not, quite easy to upgrade. You just replace all files and rebuild everything. The hard part is figuring out what you actually have on your hard disk to replace...

http://sourceforge.net/apps/trac/mingw-w64/wiki/Unicode%20apps#Issues

[Dragonic]

- LibOVR (OculusRift SDK) : unrecognized command line option "-municode" when building (using Msys1.0)
I don't found the solution for now !

The solution is... install the same kind of MinGW as you had before. -municode is a mingw-w64 flag which obviously won't be present on mingw32. You can't just replace something with something else just because it has a greater version number. MinGW is, believe it or not, quite easy to upgrade. You just replace all files and rebuild everything. The hard part is figuring out what you actually have on your hard disk to replace...

I know that it's really simple to use any version of MinGW ^^ ! But really I don't know which one I need to choose now ^^ ! I can't use my older version where everything works fine because it's GCC 4.7 and can't use it with SFGUI ! Also there are MinGW, MingW-w64, TDM-GCC, ... !
(I tried last version of TDM-GCC, no Msys installed with it, I don't know if it has to be a linked module)

Oh, and I need to use and build libs for win32 (not x64) ! About that, I don't understand why I succesfully built the LibOVR with this older version of MinGW when I think about it !

[eXpl0it3r]

I usually go with one of these: http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8.1/32-bit/threads-posix/

I choose posix since the win32 thread model doesn't support std::thread, where as the posix one makes it possible via winpthread.

[Dragonic]

I usually go with one of these: http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8.1/32-bit/threads-posix/

I choose posix since the win32 thread model doesn't support std::thread, where as the posix one makes it possible via winpthread.

LibOVR : successful build with this version !


This is a mingw-w64 version, how can I use it for x86 only ? Do I need to add to path "i686-w64-mingw32\bin" ?

[eXpl0it3r]

While the name is MinGW-w64 and the origin of it is that they wanted a MinGW version for x64 applications, but the MinGW-w64 can still be used as x86 compiler, in fact if you had looked closely at the URL above, you'd have noticed that you're already in the 32-bit sub-directory, thus your compiler is already producing x86 applications only.

[Dragonic]

While the name is MinGW-w64 and the origin of it is that they wanted a MinGW version for x64 applications, but the MinGW-w64 can still be used as x86 compiler, in fact if you had looked closely at the URL above, you'd have noticed that you're already in the 32-bit sub-directory, thus your compiler is already producing x86 applications only.

Ohh right, thank you (I'm really lost for everything unless programming with C++ and my IDE ^^') !

[Dragonic]

Do you know how to build Glew Static with MinGW ? It produce only the shared by default, and it failed to build SFGUI with this libglew32.a !

[binary1248]

So... why can't you just use the one provided with SFML?

[Dragonic]

So... why can't you just use the one provided with SFML?

I think that's a really great question xD !

I didn't know that SFML already had a mingw precompiled version of glew ^^ !

Everything seems to be Ok now ! There is only one lib that I can't rebuild now because I need his creator (NazaraEngine), but everything else has been built with this new GCC version !

Thank you for your help !

Now it's time to test this interesting SFGUI ^^ !
I asked a question about SFGUI boxes earlier : we have to use images in order to have a special background ? If yes, does it have some kind of 9-patch (9-slice-scaling) support ?