Ogre 1.4 Code::Blocks + MinGW SDK maintainer needed

[nfz]

A new maintainer for the Code::Blocks + MinGW SDK is required in order for this SDK to continue to be offered to the community. I had mentioned to Sinbad that I would take a crack at updating it for Ogre 1.4 (Eihort) this weekend but I didn't get a chance to yet. I probably won't get a chance until end of March now. If people want an SDK before then, someone needs to update the SDK and the MinGW C++ Toolbox.

A few general notes on what needs to be updated. All the dependencies need to be updated. I do have all the dependencies built but they were built with MinGW gcc 4.2. Some .cbp files need updating based on the new dependencies. The .cbp project files for the SDK demos also need updating. Then the biggest hurtle is for the community to decide what todo about MinGW wide string/Unicode support. I already made my decision as to what I am doing but I don't think the rest of the community will follow.

MinGW gcc 3.4.5 or earlier builds do not support unicode, wstring, or wide string stream out of the box, a large amount of the implementation had not been ported from the POSIX code to windows ie using the msvcrt.dll. The headers have the definition and you can get things to compile by defining _GLIBCXX_USE_WCHAR_T (an internal define that the user should not fiddle with ) but it doesn't solve the problem that MinGW libstdc++ wasn't built with full proper support for unicode. At link time you will get undefined references. This is one of the reasons why I had gone the STLPort route back in Jan 2006 but I reverted back to a modified libstdc++ build since there were a lot of complaints about having to use STLPort. STLPort is still a good option if you don't mind the huge debug builds and long debug link times.

Some links about the MinGW wide character issues:

MinGW Wiki

MinGW user post about using wchar.


At the end of December 2006, I rebuilt MinGW gcc 3.4.5 with libiconv so that I would have basic unicode support for Eihort. This works fine but locale support is very limited. In mid January I changed over to MinGW build of gcc 4.1.1 and then at the end of January migrated to MinGW build of gcc 4.2. Ogre 1.4 will compile and link with gcc 4.1.1, 4.1.2 and 4.2, there is no need to define _GLIBCXX_USE_WCHAR_T. Be warned that the gcc 4.1 debug build of OgreMain (148MB) is about double the size the gcc 3.4.5 (74MB) debug build of OgreMain.

If you decide to use gcc 4.1 with SJSL exceptions, the patch for MinGW g++ 3.4.5 to allow SJSL exceptions to cross dll boundries did not get applied to gcc 4.1 svn so you need to do that otherwise a crash will most likely occur on start up. The crash occurs in OIS when it throws an exception when an input device (in my case a joystick) is not found. If you have a joystick plugged in then you'll get a little farther . The staticaly linked in libgcc is the root cause of the termination since no exception handler traps the exception inside the OIS dll and libgcc doesn't pass it out. In the Ogre demos the exception is normaly caught but since the exception doesn't get passed out of the OIS dll, the runtime library decides to halt things.

Using gcc 4.2 with DWARF2 exception handling instead of SJSL exception handling and building libgcc and libstdc++ as dll's fixes the problem and no patch is required. Search through the MinGW user and dev mailing lists for info on how to do the 4.2 builds. Ogre 1.4 (release build -O2) built with MinGW gcc 4.2 runs about the same speed as a VC8 release build. Ogre 1.4 built with MinGW gcc 3.4.5 (rebuilt with libiconv for basic wstring support) runs about 20% slower than a VC8 build.

Take note that visibility rules changed in gcc 4.0 and higher. In gcc 3.4.5 we didn't have to worry about exporting public names for dlls since they all got exported by default. In gcc 4.0 and higher, the default behaviour is not to export all which means that __declspec(dllexport) for MinGW builds does have to be used so Ogre platform header and the other dll prerequisite headers had to be modified to support this.

If you decide to use MinGW gcc 4.1 or higher with codeblocks, you will get a huge number of warnings about using the deprecated -I- instead of -iquote. Its an easy fix in codeblocks source if you build codeblocks from source.

The two options that I didn't try is putting in an option to not use wide string support in UTFString for a MinGW build or use an external unicode library. Those two options are short term options until a decision is made on how to proceed with proper unicode support for MinGW.

My choice was to go with gcc 4.2 but 4.2 has not been released yet so I will not make an Ogre SDK for it.

[irrdev]

More 10 hour work days are looming, right? I hadn't realised the complications of Mingw and Unicode. It provides a daunting task for integration with Ogre. I was wondering, but how much work would it be to remove the current Unicode support? I don't have any use for it myself, as CEGUI provides the extra support for extended international characters. I must add that I would be happy to work with GCC 4.2, although the increased dll size is annoying. How are other gcc ported Windows compilers like djgpp? I have found that the djgpp compiler and linker work in many cases where mingw has altogether failed.
My Vote overall would be for using GCC 4.2. It is fast and provides full Unicode support. However, it is up to the rest of the community to come to a final decision on this. Maybe there could be an official vote?

[irrdev]

Would you mind putting up your pre-compiled GCC 4.2 for download, nfz? That would be greatly appreciated, so that I can try and get Eihort compiled.

[steven]

I vote for 4.2.

Using gcc 4.2 with DWARF2 exception handling instead of SJSL exception handling and building libgcc and libstdc++ as dll's fixes the problem and no patch is required. Search through the MinGW user and dev mailing lists for info on how to do the 4.2 builds.

Could we create a wiki page on how to build mingw-gcc 4.2 ?

In my experience searching the mingw forum is ... tedious.
With a wiki page we could learn rapidly from each other if we encounter difficulties.

... so Ogre platform header and the other dll prerequisite headers had to be modified to support this

I suppose that you proposed a patch, no?

If you decide to use MinGW gcc 4.1 or higher with codeblocks, you will get a huge number of warnings about using the deprecated -I- instead of -iquote. Its an easy fix in codeblocks source if you build codeblocks from source.

Nfz, did you inform the CB forum of this problem?

Be warned that the gcc 4.1 debug build of OgreMain (148MB) is about double the size the gcc 3.4.5 (74MB) debug build of OgreMain.

Ouch. Also with 4.2 ?

[sinbad]

Thanks for the detailed info nfz.

Any volunteers?

[Beliar]

Well, at least we know how to theoretically solve the problem.

Well, until a new Code::Blocks SDK for Eihort is out i think i'll have to stay with linux(which is not the bad part - the problem is booting to windows again - it takes ages )

I would be interested how to compile/get a windows version of gcc4.1/2 though.

[big_o]

Sorry to hear that it might be awhile before the next sdk is released. I don't have the time or experience to work on it, but I will gladly test stuff sent my way.

[irrdev]

I have done some researching; here is what I found...
Mingw currently only support GCC 3.4.5- as a candidate release too! In contrast, the latest "stable" version of GCC is 4.1.2. That is a big difference. I don't expect the mingw team will have GCC 4.2 out for another year! So... we have to choose between using 3.4.5 with libiconv or using GCC 4.2. It appears that there wouldn't be that many changes necessary to make GCC 4.2 fully compatible with Windows. The biggest change is switching Posix paths on the command line to Windows paths. Other than that, I couldn't find any major differences. What remains is for someone to do the actual coding... I myself might take a try at it this weekend. However, I am quite unfamiliar with the GCC source code, so I may not get very far. It appears that nfz already has a working version. It would save a lot of time if we could use his version. I'll PM him about obtaining it.
In the meantime, it would be great if someone could compile the dependencies. These don't require Unicode support, and so should work fine with the current modified version of GCC. The only dilemma might be later linking, but it might work. Anyways, let's see what other users make of this problem. Of course, there is always the simple route of adding libiconv to GCC 3.4.5. It might be a consideration to do just that for RC1 and RC2 of Eihort. It's important that GCC users can test out Eihort before it is committed to the first release.

[steven]

@irrdev : You can obtain a compiled version here : http://gda.utp.edu.co/%7Eceniza/GCC-4.1.0/

However I didn't have time to test it with Heihort as I would prefer to build it myself. Btw if I succeed I wiki an Howtodo.

[irrdev]

@steven I already know about that version, along with another for 4.2. However, neither of them are compiled with the DWARF2 flag, so they won't work with Eihort. Thanks for the suggestion anyways.

[sinbad]

For speed, for the moment I am going to disable unicode support in MingW when STLport is not in use. This should be enough to get C::B and MingW working. Those who want to use unicode in MingW can either build with STLport or upgrade to a newer version themselves. But the number of custom build elements required to get regular MingW and C::B working with unicode seems to be far too much hassle than it's worth right now.

[irrdev]

Thank you Sinbad! I have no need for direct Unicode support; I can use CEGUI for that. It will make Ogre and GCC easy to compile now, and keep the SDK size down to a minimum.

[steven]

Thank you Sinbad!

@Sinbad: As the cegui unicode support works with gcc 3.4.5 why not use it as inspiration for the ogre one? Is there a catch in the cegui approach?

Anway it will save me hours: building gcc 4.2 seems not to be simply "configure & make"

I nearly build 4.2 using Scott Meyers How-to: http://www.aristeia.com/Misc/gcc4ForWindows_frames.html
However the last step "make install" stop and here I am stuck:

Code: Select all

GST@PS839 /gcc-work/source/gcc
$ make install
make[1]: Entering directory `/gcc-work/source/gcc'
/bin/sh ./mkinstalldirs /mingw /mingw
/bin/sh: line 3: cd: host-mingw32/fixincludes: No such file or directory
make[1]: *** [install-fixincludes] Error 1
make[1]: Leaving directory `/gcc-work/source/gcc'
make: *** [install] Error 2

I tried to comment out the fixinclude part in the makefile (as there shouldn't be anything to fix hopefully).
But then I got the error that 'cat' command was not found!?


Btw I also tried "the official mingw way" using the x86-mingw32-build.sh :
http://sourceforge.net/project/showfile ... _id=461967
But it was far worse.

[irrdev]

Thanks for that tutorial, steven. I'll try it out when I have the chance, probably next week. Everything else that I have currently tried has failed with over 50 errors.

<EDIT>
Looked at the tutorial and noticed that it is for gcc 4.1. Maybe it doesn't work with 4.2? If that is the case, I am going to try and get the gcc 4.1 source. BTW, windows doesn't have the "cat" command. You have to download CoreUtils, which contains the textutils package that has the "cat" command. CoreUtils also comes with "install." Here is the link http://www.gnu.org/software/coreutils/
</EDIT>

[Kentamanos]

BTW, windows doesn't have the "cat" command. You have to download CoreUtils, which contains the textutils package that has the "cat" command.

Or you could replace it with "type"

[steven]

<EDIT>
BTW, windows doesn't have the "cat" command. You have to download CoreUtils, ...
</EDIT>

Thanks but I already have CoreUtils installed.
My Msys environment has a functional cat command: if I type cat it works correctly. I launch the make from the msys console but it can't find the cat !

I tried to copy the cat.exe in different folder /mingw/bin, source folder, etc but it didn't help.

Or you could replace it with "type" Smile

I don't think so because it is not a command in the makefile that calls cat. I tried to comment out all the cat in it to find the culprit but it wasn't one of the makefile cat...

Conclusion: until i can compile 4.2 I will comment out the UString class (and use the cegui one that works with 3.4.5 )

[sinbad]

The reason is that the CEGui version doesn't support wchar_t or std::wstring constructions / conversions, which is what MingW has a problem with - it only supports std::string inputs. I was considering being more selective and just removing the wstring support but I'm short of time and it was less clear cut when I didn't have a MingW build environment to test it with. If someone who regularly builds with MingW can try just removing those parts, then UTFString would work on MingW too I'm sure. Patches welcome - I may get time to do it myself later but this was a quick guaranteed-to-work kind of patch.

[steven]

If someone who regularly builds with MingW can try just removing those parts, then UTFString would work on MingW too I'm sure.

Replacing all UTFString by String works nearly.

The problem is in OgreTextAreaOverlayElement

Code: Select all

 Font::CodePoint character = j.getCharacter();

The String iterator doesn't have a getCharacter method.
Hence we must copy the 1.2 code for TextAreaOverlayElement::updatePositionGeometry().

Didn't have time to do that.

[sinbad]

No, no, wholesale replacement is already done - get CVS and you'll see I already addressed replacing UTFString entirely, including all the TextAreaGuiElement issues.

What I was referring to was that it's likely possible to use UTFString but with the stuff referring to wstring / wchar_t excluded via more specific preprocessor sections.

[nfz]

I'll be uploading a new MinGW 3.4.5 C++ Toolkit and a new dependency build sometime today which will allow Ogre src to be built and run as is, no need for special MinGW compile options. I've modified libstdc++ to provide very basic wchar and wstring support (just enough for Ogre use). The code was already there but needed some tinkering of defines and mods of headers to get it working properly. Locale support is not working 100% but for most users it should not be a problem. I will also commit to cvs HEAD the changes needed to build using MinGW gcc 4.2 but also works with the new MinGW gcc 3.4.5 Toolkit. The Code::Blocks project files will also get updated in cvs to bring them inline with the latest CB project format.

I've got the Ogre SDK ready but I may hold off on uploading it to Source Forge untill I have a chance to update the wiki which may not happen until next weekend. If I release it now there will be a ton of complaints about it not working because about 80% of the users of the previous SDK don't use the MinGW Toolkit but use either MinGW gcc 3.4.2 or 3.4.4. Have a look at the Toolkit download numbers and SDK download numbers to see what I mean. For Ogre 1.2 and earlier they could get away with it if they only did release builds and didn't have a lot of DLL string passing or exceptions across dll's going on but for Ogre 1.4 they won't be able to use 3.4.2 or 3.4.4 period.

As far as building gcc 4.x goes, I use Cygwin. Early last year I used Msys for gcc 4.0 but last month I started using Cygwin to do the 4.1 and 4.2 builds. By using Cygwin, some of the path issues can be solved by mounting C:/mingw to /mingw.

[sinbad]

Cool - sounds like a better solution. Will you make a patch available for libstdc++ so we can see what you did?

[irrdev]

Thanks nfz! I can't wait to use Eihort!

[Mouse]

I've created own build system for gcc to compile all library dependences, CEGUI and Ogre for Mingw32 target from Cygwin without installing Mingw/MSYS at all. At present time I have some issues with gcc-3.4.5.
I have question about lib's names. Libtool produces libs started with "lib". But Code::Blocks produces libs without "lib" prefix for CEGUI and OgreMain. In this case, Mingw32 port of CEGUI and OgreMain may have "lib" prefix. This is different to previous releases. Or we need to "hack" libtool of CEGUI/Ogre to produce dll's without "lib" prefix. Also, I don't know, how current maintainer produce debug libs with "_d" postfix for some dependences libraries. In libtool it's not possible. I have three additional directories: bin/debug , lib/debug and lib/pkgconfig-debug for debug binaries, pkgconfig files and libraries. It's necessary to build debug version of dependencies.
If we would solve lib's naming and debug-placing convention, I could try to help with maintaining of Mingw32/GCC port without using MSYS/Mingw toolbox. Also, I need to recompile gcc with `--enable-fully-dynamic-string' option. I'm trying to compile gcc 4.2.1, 4.1.1 and 3.4.5 but always miss /usr/include include directory in gcc/g++ binaries. And therefore, I couldn't compile gcc with new compiler. I didn't find any appropriate configure options to add /usr/include to gcc/g++ standard search path.