Using minGW with STLport to compile wxWidgets anyone want the steps?

[stahta01]

I am compiling wxWidgets both 2.6 and 2.8 using minGW with STLport with wxUSE_STL=1.
Anyone want the steps I followed to do it?

Tim S

[RJP Computing]

Sure. Information is always helpful. Please share.

[stahta01]

Sure. Information is always helpful. Please share.

OK, once I reach a stopping post I will add entries to this thread and later to the WiKi.
Working in trying to get C::B compiling against it. A lot of changes needed.

To many changes I gave up getting C::B to use the wxWidgets using STLport.

Tim S

[stahta01]

Note, STLport-5.1.0 had problems for me it may work for you, but 5.0.3 worked to build 2.6 CVS branch.
Note, follow the readme for cygwin without the vb6 option and it worked for me to build STLport the first time. Note, I have notice some things (not STLport but other things) do NOT like make version 3.81 or 3.79 so use make version 3.80 if you can.

Step 1 download STLport-5.0.3 from http://sourceforge.net/projects/stlport

Step 2 extract files

Step 3 copy the deepest STLport-5.0.3 folder which contains sub-folders build, stlport, test and etc. to your mingw folder.

This should result in a path like below, you can rename STLport-5.0.3 if you want, but all directories below it can NOT be renamed.
c:\mingw\STLport-5.0.3\build\lib

My mingw is the candidate version with GCC 3.4.5 and mingw32-make.exe version of 3.80
My MSys is from MSYS-1.0.11-2004.04.30-1.exe

Step 4A Open MSys
Step 4B cd /mingw/STLport-5.0.3/build/lib
Note: It worked for me without doing configure, but another post had it and it makes sense to do it.
STEP 4B2 configure -c gcc
Step 4C mingw32-make.exe -f gcc.mak depend
Step 4D mingw32-make.exe -f gcc.mak install

Step 5A cd ..
Step 5B cd test/unit
Step 5C mingw32-make.exe -f gcc.mak
Warnings are normal; errors are NOT!
"undefined references" should not happen either but they did for me on the test.

Note: You need to copy the DLLs in the STLport-5.0.3/bin to were the exe files are.

The commands to compile wxWidgets 2.6 is below

Code

SET PATH=C:\MinGW\bin;C:\MinGW\mingw32\bin
CD wxWidgets-2.6_BRANCH\build\msw
mingw32-make -f makefile.gcc VENDOR=branch-26-stlport USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 CLEAN
mingw32-make -f makefile.gcc VENDOR=branch-26-stlport USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 CPPFLAGS="-DWINVER=0x0600 -isystem C:\apps\MinGW_GCC_3.4.5_API_3_8_STLport\STLport\stlport -isystem C:\apps\MinGW_GCC_3.4.5_API_3_8_STLport\include" LDFLAGS="-LC:\apps\MinGW_GCC_3.4.5_API_3_8_STLport\STLport\lib -lstlport.5.0.dll -lstlportg.5.0.dll -lstlportstlg.5.0.dll"

Meaning of some of the build options
  VENDOR=branch-26-stlport set the DLL to have branch-26-stlport in the name (This is optional)
  CPPFLAGS set Preprocessor flags to define WINVER=0x0600 (this is the value for windows vista and is the default value used by wxWidgets, therefore it can be removed but it helps to make bad code in wxWidgets work so if compiling against CVS it is highly recommened.)
  CPPFLAGS is also used to set the system include directories using the -isystem option.
  Note, the stlport must be the first system include directory.

  LDFLAGS is used to pass linker options the order of libraries was random it worked for me building wxWidgets building something else the order my need correction.

Tim S

[stahta01]

The setting in code::blocks needed to compile and link a program that uses STLport.

[Global Compiler Settings]

Compiler -> Other Options
  -isystem C:\MinGW\STLport\stlport
  -isystem C:\MinGW\include

Linker (note the order was random no idea if it is correct.)
  stlport.5.0.dll
  stlportg.5.0.dll
  stlportstlg.5.0.dll

Directories

  Compiler (this is a folder that does not exist to prevent a value from being set on C::B startup.)
     C:\null

  Linker
     C:\MinGW\STLport\lib
     C:\MinGW\lib

   Resource Compiler
     C:\MinGW\include

Tim S

[RJP Computing]

Thanks for sharing.

[BjoernP]

Great, thanks!
I've been looking for exactly this some time ago, now this is a very good starting-point.
Just a few more questions:

- What was actually your motivation for using the stlport/wxSTL setup?
For myself, I was interested in this solution when I found some musings in the wiki of OGRE about the gcc-stl not working nicely... sharing data across shared libraries will easily corrupt the data, something like that.
See http://www.ogre3d.org/wiki/index.php/CodeBlocks_MingW_STLPort
That gave me a faint desperate hope tracking down some spooky bugs in my project (turned out to come from a different direction after all, as usual).

- What is different with these settings, what is working (better) now than with a plain gcc-stl and plain wx?
I still don't get the picture on what exactly is possible with the wx-Containers when having wxSTL set. A code sample would be helpful here. Can you then do things like create a wxArray from std::vector or even give a vector<>& where wxArray is expected?
That would be a neat thing indeed!

[stahta01]

Great, thanks!
I've been looking for exactly this some time ago, now this is a very good starting-point.
Just a few more questions:

- What was actually your motivation for using the stlport/wxSTL setup?
For myself, I was interested in this solution when I found some musings in the wiki of OGRE about the gcc-stl not working nicely... sharing data across shared libraries will easily corrupt the data, something like that.
See http://www.ogre3d.org/wiki/index.php/CodeBlocks_MingW_STLPort
That gave me a faint desperate hope tracking down some spooky bugs in my project (turned out to come from a different direction after all, as usual).

My motivation was reading about OGRE and Boost, I want to try to use Boost with MinGW and it requires STLport. Also, I wish to use STL with wxWidgets.

- What is different with these settings, what is working (better) now than with a plain gcc-stl and plain wx?
I still don't get the picture on what exactly is possible with the wx-Containers when having wxSTL set. A code sample would be helpful here. Can you then do things like create a wxArray from std::vector or even give a vector<>& where wxArray is expected?
That would be a neat thing indeed!

So far, I have not found anything that works better. But, wxWidgets is the only thing I have used it for.
I did find that Code::Blocks needs a lot of code changes to use wxWidgets with STL.

Tim S

[BjoernP]

Yea, same for me - here it's Boost with mingw too that gives me the jitters.

I don't get it running without optimizing less than -O2 (and -g) -- which makes debugging/stepping a somewhat funny procedure... you never know where the next step will take you.
But on the other hand it's fun for watching the compiler's optimizing at work - reordering,inlining, all that.

Without I get gcc-errors like "sorry, unimplemented: inlining failed in call to 'bla foo(whatever)'" with Boost::assign, Boost::date_time and the like. But these do also come up within STL headers but only when Boost is part of the game.

Another possible solution I had in mind was switching to a homebrew mingw gcc-4.1, not sure wether gcc-4-series would do better.

 -- Now - do you guess stlport will give me better results on this?
 -- And where did you hear it is required with mingw?

I will try the procedure the other day or after that and report where it took me.

For CB compilation I always used the standard wx setup, 2.6.3-2-unicode. For my own stuff i recently switched to wx-2.8/wx-head (is 2.9 now) from CVS.
But if CB needs a lot of adjustments, as you report, then other programs/libraries are not likely to run off-the-shelf with a wxSTL setup. I guess that's the problem with all setups/solutions that are slightly off the mainstream. Steeper roads to climb.

Bjoern

[stahta01]

Yea, same for me - here it's Boost with mingw too that gives me the jitters.

I don't get it running without optimizing less than -O2 (and -g) -- which makes debugging/stepping a somewhat funny procedure... you never know where the next step will take you.
But on the other hand it's fun for watching the compiler's optimizing at work - reordering,inlining, all that.

Without I get gcc-errors like "sorry, unimplemented: inlining failed in call to 'bla foo(whatever)'" with Boost::assign, Boost::date_time and the like. But these do also come up within STL headers but only when Boost is part of the game.

Another possible solution I had in mind was switching to a homebrew mingw gcc-4.1, not sure wether gcc-4-series would do better.

 -- Now - do you guess stlport will give me better results on this?
 -- And where did you hear it is required with mingw?

The boost directions I found said it needed STLport for use with mingw.

I will try the procedure the other day or after that and report where it took me.

For CB compilation I always used the standard wx setup, 2.6.3-2-unicode. For my own stuff i recently switched to wx-2.8/wx-head (is 2.9 now) from CVS.
But if CB needs a lot of adjustments, as you report, then other programs/libraries are not likely to run off-the-shelf with a wxSTL setup. I guess that's the problem with all setups/solutions that are slightly off the mainstream. Steeper roads to climb.
Bjoern

Most of the C::B changes are needed because wx 2.4 style code was used and 2.4 code was not written to work with STL. So, if your project was written using the suggested wx 2.6 way it could work with STL OK.

wxList::Node* needs replaced with wxList::compatibility_iterator, note I am just guessing that wxList::Node* is the 2.4 way, I can find no documentation to confirm this. For that matter I can NOT even find wxList::compatibility_iterator in the 2.6 or 2.8 docs.

Found in changes.txt for 2.5.0
- Added wxList::compatibility_iterator. Can be used like wxNode* (except
  it can't be delete()d). It permits writing code which will work
  both with wxUSE_STL==1 and wxUSE_STL==0.

Tim S