GCC 4.2.1 binary release for mingw is available from MINGW

[OLDSCHOOL]

It's mostly about WXDLLEXPORT, WXDLLIMPEXP, WXDLLIMPEXP_SCI, and WXDLLIMPEXP_PG.

I have no idea what we need them for, anyway (or if at all?). Since we don't do any dynamic loading, I think those should be not needed at all? The linker should figure out a symbol if it's not exported, too... shouldn't it?

Anyway, that's what triggers the "attribute blah blah cannot blah" style error.

Hello, this is why mingw.org call 4.2.1  a Technology Preview.  There are  a stack of issues about c++ dll's   We can get them to work, no problem, now,  but, tomorrow ...  there are libstdc++ versioning  issues (has anybody read the MSDN article entitled something like ("Building DLL's is easy, maintaining them is the problem")  there is the question about how do we canonicalize gcc's  -Bstatic  vs -Bdynamic   diff into preprocessor defines that turn on/off dllimport/dllexport attributes (can we just use the MSVC++ precedent of -D_DLL  ...  well maybe, if we we are C/C++ centric and don't care about languages like Fortran/Ada that don't use a preprocessors), there are issues with .rdata and (yuck) --enable-auto-import  vs typeinfo data.

Hacks work today. Hubris is a nice feeling too, today.     I see all these smiley faces above me as I type.  I prefer  the spirit of the GPL that says download the source and submit a patch.  Or at least raise the question in a forum where a long-term solution is the focus.

Please help.

Wow, that was heavy.

In the event, when you hit an internal compiler error, please do read the instructions and submit a **useful** bug report .

No fault.
Perseverance Furthers.

Here is a picture of my long-ago  friends from another time thinking about Further ...

http://www.lib.virginia.edu/cgi-bin/imgload.cgi/53


OS

[pir]

Having a problem getting version 4.2.1 working! (Strictly a mingw/gcc problem, not a CodeBlocks problem but...)
 
When I try to invoke the compiler (from the command line or from C::B), I get a message:
 
"mingw32-g++.exe: CreateProcess: No such file or directory"
 
Here I've renamed the .exe by removing the "-dw2" bits but it makes no difference leaving the "-dw2" naming as is - same error. Flipping the toolchain back to 3.4.5, the thing runs fine with no changes.
 
Since you guys seem to have got it working OK, any suggestions welcome.

BTW: WinXP-SP2

[stahta01]

Having a problem getting version 4.2.1 working! (Strictly a mingw/gcc problem, not a CodeBlocks problem but...)
 
When I try to invoke the compiler (from the command line or from C::B), I get a message:
 
"mingw32-g++.exe: CreateProcess: No such file or directory"
 
Here I've renamed the .exe by removing the "-dw2" bits but it makes no difference leaving the "-dw2" naming as is - same error. Flipping the toolchain back to 3.4.5, the thing runs fine with no changes.
 
Since you guys seem to have got it working OK, any suggestions welcome.

BTW: WinXP-SP2

Try changing the file name in C::B compiler settings

Under tab "Toolchain Executables" I have
C Compiler:  mingw32-gcc.exe
C++ Compiler: mingw32-g++.exe
Linker for Dyn Libs: mingw32-g++.exe

[pir]

Try changing the file name in C::B compiler settings

Under tab "Toolchain Executables" I have
C Compiler:  mingw32-gcc.exe
C++ Compiler: mingw32-g++.exe
Linker for Dyn Libs: mingw32-g++.exe

Thanks, but I have tried that already. The problem still occurs running the compiler from the command line so it's not really a C::B problem.

[thomas]

Do you have the C++ compiler installed at all? This sounds like a stupid question, but it can actually happen.

gcc (or mingw-gcc) is no compiler, you know. It is only a frontend to about half a dozen different compilers that all work via one common interface, and g++ being one of these compilers.
If gcc complains that there is no such file as mingw32-g++.exe, this suggests that you have downloaded the base package, but not the C++ package (or, it could be that paths are set up badly).

[pir]

Do you have the C++ compiler installed at all? This sounds like a stupid question, but it can actually happen.

gcc (or mingw-gcc) is no compiler, you know. It is only a frontend to about half a dozen different compilers that all work via one common interface, and g++ being one of these compilers.
If gcc complains that there is no such file as mingw32-g++.exe, this suggests that you have downloaded the base package, but not the C++ package (or, it could be that paths are set up badly).

I installed gcc-core and the g++ frontend together with the runtime and win32api stuff. Am I forgetting something? The path contains c:\mingw\bin. The compiler seems to be starting but but bails with an internal error. Basically, I have installed 3.4.5 in exactly the same way and that works fine. I can't see what I'm doing differently.

BTW: 'Stupid' questions are often very good questions!

[thomas]

Hmm... I have done the exact same (even the install path and the OS are incidentally the same).

Everything just works, did not have to configure a single thing... this makes it kind of hard 

[pir]

Right then!

I have installed version 4.2.1 on another machine and it (nominally!) works - more on this below. Therefore I conclude that part of the OS on the first machine I tried and which gave the CreateProcess problem has got mangled. In fact, I have seen this before with XP - strange, illogical things start creeping in. I will repair over the weekend and see if that makes a difference. Other than that, a fresh install. (Oh joy!)

I say 4.2.1 nominally works. I can build the "Hello world!" program from the command line, no problem. But when I try to build it from C::B, I get loads of weird linker errors: undefined references to __gxx_personality_v0, _Unwind_SjLj_Register, _Unwind_SjLj_Unregister, etc. The last ones puzzle me big time! I have absolutely definitely installed both the core and g++ dw2 variants. (Very sure. Double-checked, repeated install.) But the linker seems to be looking for bits from the other sjlj variant of version 4.2.1? Or might it be from 3.4.5 which co-exists on the machine but obviously in a different directory. Very sure I have the toolchain exe location/filenames correct. Nonetheless the program builds successfully from the command line!

Doh!

[RJP Computing]

I have built wxWidgets with MinGW Gcc_v4.2.1-dw2 and created a custom "unofficial" installer for MinGW Gcc 4.2.1-dw2. Please see if these help you get it working. I have had really good luck using this method. That is why I shared.

http://wxpack.sf.net/Main/Downloads

[pir]

Interesting. But building wxWidgets invokes the compiler from the command line via make. Have you managed to build anything by spawning 4.2.1 from within CodeBlocks? Like "Hello world", for example? It would be helpful to know if someone else can do this without problems.

[RJP Computing]

Interesting. But building wxWidgets invokes the compiler from the command line via make. Have you managed to build anything by spawning 4.2.1 from within CodeBlocks? Like "Hello world", for example? It would be helpful to know if someone else can do this without problems.

Of coarse. I build all my projects with MinGW 4.2.1. It works fine in Code::Blocks and make.


NOTE: These instructions are assuming you are using the simple installer for MinGW v4.2.1 from http://wxpack.sf.net/Main/Downloads
You need to make sure if you installed MinGW to a different directory, other than 'C:\MinGW', that you change four directory paths in Code::Blocks. You need to change the 'Settings->Compiler and Debugger...->Toolchain Executables->Compiler's installation directory' to your custom path (e.g C:\MinGW4). I also must mention that you should NOT install MinGW in a path with spaces. At least until I hear differently. This is the official release and I don't believe it will handle this well, so don't do it. Then you need to change the three directories under 'Settings->Compiler and Debugger...->Search Directories->Compiler', 'Settings->Compiler and Debugger...->Search Directories->Linker', and 'Settings->Compiler and Debugger...->Search Directories->Resource Compiler' to match your installation of MinGW (e.g. 'C:\MinGW4\include).

That is all you should need to do. Hope this helps.

[Conan Kudo]

I have built C::B and wxWidgets 2.8.4 built using GCC 4.2.1-sjlj. The dw2 version doesnt seem to work as well as the sjlj version. However, I have noticed that not all the plugins are set to build when I tell the workspace to build, and the envvars plugin cannot handle long file names when linking the DLL...

[pir]

Then you need to change the three directories under 'Settings->Compiler and Debugger...->Search Directories->Compiler', 'Settings->Compiler and Debugger...->Search Directories->Linker', and 'Settings->Compiler and Debugger...->Search Directories->Resource Compiler' to match your installation of MinGW (e.g. 'C:\MinGW4\include).

Ho-hum! Missed that bit... I was only setting the toolchain directories, which may explain why I was getting link errors (although still puzzled that the supposedly distinct "dw2" variant was looking for "sjlj" things?)

Thanks - works fine now. I'll just place my tail between my legs and skulk off into a corner...

[ingenuus]

The libgcc dll (sjlj or dw2) is a separate download.  See the MinGW GCC Version 4 package download page on SourceForge:

http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=241304

Also, does anyone know if the dw2 version is safe on win32?  Everyone seems to be using it but I thought that dw2 couldn't unwind foreign frames and so couldn't handle exceptions in the OS or callbacks.  Are they just betting that exceptions won't occur or has something changed?

[RJP Computing]

...
Also, does anyone know if the dw2 version is safe on win32?  Everyone seems to be using it but I thought that dw2 couldn't unwind foreign frames and so couldn't handle exceptions in the OS or callbacks.  Are they just betting that exceptions won't occur or has something changed?

It is working great for me. Actually it fixes a bug in the 3.4.5 sjlj model. It now can properly catch an exception passing the Compiled as C throwing to my C++ main program barrier (I don't know if there is a technical term for that ). The exceptions seem to be working as good as Visual C++. I have compiled and use wxWidgets 2.8.4 with it as well.