TDM's unofficial GCC 4.2.0 for MinGW (now with OpenMP, Fortran and Obj-C)

[eloj]

Something definitely changed with tdm-2, because when I put it over my tdm-1 installation I too started getting missing includes when compiling from another drive:

Code

C:\>cat dummy.c
#include <stdlib.h>

int main(int argc, char* argv[])
{
  char* c = malloc(10);
  free(c);
}

C:\>gcc dummy.c

C:\>copy dummy.c h:\dev\WORK
        1 file(s) copied.

C:\>h:

H:\dev\WORK>gcc dummy.c
dummy.c:1:20: error: stdlib.h: No such file or directory
dummy.c: In function 'main':
dummy.c:5: warning: incompatible implicit declaration of built-in function 'malloc'

edit: The above is a cc1.exe issue, because if I install TDM-2 and replace the cc1.exe with the one from TDM-1, it works again.

I should also say that with TDM-1 I was getting some annoying message box sometime since cc1.exe or the driver tried to access a volume (my CDROM) which had no disc. Cancelling the msgbox would allow the compilation to continue, but in the end I simply put a CD or DVD in to get rid of it. Never really tried to debug the issue. I assume this has to do with the "relocatable installation directory" modifications.

[Zoinky]

patlecat:
I'm unable to reproduce the problem, and have never encountered a similar one. I recommend you check your Windows environment variables to make sure that no strange GCC-related ones are messing things up -- all you should have is "H:\MinGW\bin" (or wherever you chose to put it) in your PATH variable -- and completely clean out your MinGW directory, reinstalling from scratch. As always, install my GCC 4.2.0 package last and overwrite any duplicated files.

In case you're interested, here is the source I used to try to duplicate it:

Code

#include <wx/wx.h>

int main()
{
	return 0;
}

... and here is the command line:

Code

g++.exe -c -o test.o -fno-rtti -fno-pcc-struct-return -fstrict-aliasing -Wall -D__WXMSW__ -D__GNUWIN32__ -D__WIN95__ -DUNICODE -O -Wall -I"G:\Libraries\wxMSW-2.8.4\include" -I"G:\Libraries\wxMSW-2.8.4\lib\gcc_dll\mswu" test.cpp

Cheers,
John E. / TDM

I receive similar errors when using gcc 4.2.0 (thanks for providing it, by the way) to build wxWidgets 2.8.4, and I'm wondering if it's because of the include directories that it's looking in (since it can't find <string>):

Code

C:\MinGW\libexec\gcc\mingw32\4.2.0>cc1plus -v
ignoring nonexistent directory "i:/MinGW/include/c++/4.2.0"
ignoring nonexistent directory "i:/MinGW/include/c++/4.2.0/mingw32"
ignoring nonexistent directory "i:/MinGW/include/c++/4.2.0/backward"
ignoring nonexistent directory "i:/MinGW/include"
ignoring nonexistent directory "i:/MinGW/lib/gcc/mingw32/4.2.0/include"
ignoring nonexistent directory "i:/MinGW/mingw32/include"
#include "..." search starts here:
#include <...> search starts here:
 /mingw/include
 /mingw/include
End of search list.

[nenin]

Problems with cc1.exe and cc1plus.exe from tdm-2 confirmed. They can not find standard "include" path.

[eloj]

Here's the difference in plain text, tdm-1 first, tdm-2 second:

Code

C:\MinGW\libexec\gcc\mingw32\4.2.0>cc1.exe -v
ignoring nonexistent directory "/extra/crossgcc/win-gcc/include"
ignoring nonexistent directory "/extra/crossgcc/win-gcc/include"
ignoring nonexistent directory "/extra/crossgcc/win-gcc/lib/gcc/mingw32/4.2.0/include"
ignoring nonexistent directory "/extra/crossgcc/win-gcc/mingw32/include"
#include "..." search starts here:
#include <...> search starts here:
 /mingw/include
End of search list.
C:\MinGW\libexec\gcc\mingw32\4.2.0>cc1.exe -v
ignoring nonexistent directory "i:/MinGW/include"
ignoring nonexistent directory "i:/MinGW/lib/gcc/mingw32/4.2.0/include"
ignoring nonexistent directory "i:/MinGW/mingw32/include"
#include "..." search starts here:
#include <...> search starts here:
 /mingw/include
 /mingw/include
End of search list.

Since I have my installation in c:/mingw anyhow, I simply hex-edited cc1.exe and cc1plus.exe and changed "i:/MinGW" to "c:/MinGW", which seems to have solved the problem. I guess a "subst I: C:\" would work too, if you don't mind the extra mapping and if I: is available.

[nenin]

eloj, it work. I also have mingw in c:/mingw, and correction of cc1 and cc1plus resolve problem, at least on simple project. 

[TDragon]

There are some strange things going on here -- fortunately, I'm now able to reproduce the problem. One note before I start looking for a good solution: the "nonexistent directory" messages are to be expected, because GCC is running on a system other than the one it was compiled on. Unfortunately the "-v" option doesn't show what's happening during the relative-to-self search which, for Windows systems, is supposed to (and usually does) turn up the correct location to find the file. I can speculate that the problem is directly tied to a lack of awareness of Windows' "current volume" concept.

[dwmcqueen]

Well, it also fails if you don't use MinGW as your directory.  I needed to revert to the earlier one, since I use C:\MinGW-4.2

[dwmcqueen]

That is true.  Two seconds to rename, two seconds to rename back, and so on.  However, if the compiler needs to be in non-standard I:\MingW then that is okay.  Really no reason for me to have that old compiler on there anyways - is there?

Why are we on a death wish wanting to use our own folder names for the compiler??  That I do not understand.

I think the problem is the earlier release did not have this issue, and could be located wherever.  People get used to things when they work, and then don't like them when something changes that changes the whole schematic. 

TD has done wonderful work.  I just didn't expect to have to install his package in one location and one location only.

[TDragon]

I think the problem is the earlier release did not have this issue, and could be located wherever.  People get used to things when they work, and then don't like them when something changes that changes the whole schematic. 

TD has done wonderful work.  I just didn't expect to have to install his package in one location and one location only.

That is in fact one of my primary goals when creating these releases: to achieve the same amount of flexibility of location as the official MinGW packages. As far as I'm concerned, you should be able to install it in C:\MinGW or Q:\ZarkingFrood as you please.

So I've been digging to find out how exactly this is accomplished. My 4.1.2 builds all succeed in this, but only the first 4.2.0 build did, and it was crossed-native-compiled from Ubuntu Linux. So I'm going to go ahead and create a third and hopefully final 4.2.0 release, which will include the same optimizations I used for the second, but will be cross-native-compiled as the first one.

Keep your eyes peeled for it!
-John E. / TDM

Edit:
It's now here -- gcc-4.2.0-tdm-3: optimized but fully relocatable; install wherever you like! There should also be no more unnecessary accesses of your CD drives, etc. I have also made a build supporting OpenMP parallelization through the "-fopenmp" option.

[madd]

Is support for 64 bit included in these binaries?

Also it seems to use STL from v3.4.5.   
I.e. if I rename includes/c++/3.4.5 to something else it wont compile programs that use STL, unless I manually add 4.2.0 to the include dirs..

Am I the only one with this problem?

[nenin]

Now looks like OK!

[TDragon]

madd:
Nope, sorry. I'm not sure what the state of 64-bit support in MinGW is at the moment, actually. *Makes a mental note to look at the recent win64 releases*
For the problem with using the wrong STL: it seems like an older driver or other older file is being used incorrectly. You should probably try reinstalling from a "clean slate" -- i.e. install all your desired MinGW packages (except gcc-core and gcc-g++), and then install mine.

20-40:
It's hard to answer everything you've brought up (in fact it's hard to read and understand most of your posts in the first place), but in a general way I disagree with you. I do not provide a "crippled" compiler, nor am I aware that I have in any way "nullified" any "configure procedures" that would otherwise have worked with a distribution of GCC which used hard-coded paths for a single installation directory. One of my foremost aims as a software engineer is to provide software that "just works" -- so, if you can show me how the software I distribute fails to "just work" for a common scenario, I will try my hardest to correct it. Finally, I believe it's safe to say that in fact this is a compiler which needs nothing more than its "bin" directory in Windows' PATH.

Cheers,
John E. / TDM

[dwmcqueen]

Well, thanks again!

BTW, what bugs have you encountered with latest WinAPI and binutils?

[TDragon]

For kicks and giggles, and so everyone can see that flexibility of GCC's installation isn't a pie-in-the-sky dream, I installed MinGW's packages and mine in "C:\MinGW GCC in a path\with spaces", made sure that the only MinGW-related environment variable was "C:\MinGW GCC in a path\with spaces\bin" tacked onto the end of PATH, made sure that no directories named "mingw" or "MinGW" existed anywhere (or any of the directory names used when compiling on Ubuntu), and built wxWidgets 2.8.4 and Code::Blocks, both on drive G:\, completely without a hitch. That's what I call freedom, folks.

BTW, what bugs have you encountered with latest WinAPI and binutils?

The latest binutils' "windres" has a bug that shows up while building wxWidgets; it was mentioned on a MinGW mailing list and Danny Smith (I believe) had a fix for it that should appear in the next MinGW binutils release.

As far as the latest w32api package goes, I don't remember for sure when and how I encountered the bug, though I think it, also, occured while using or building wxWidgets. Since you asked, I'll see if I can track it down again.

Later edit:
I didn't encounter any bugs building with the latest version, so it may have been a bug in 3.8 that got ironed out in 3.9. I'll have to update my docs. Thanks for reminding me.

Cheers,
John E. / TDM

[blahhh]

TDM. The sources for GCC 4.2.0 are patched according to your site:
http://www.tdragon.net/recentgcc/

Why and what did you patch? The GCC 4.2 release compiles out of the box when I download it from gcc.gnu.org. I'm building a mingw compiler using a cygwin environment (hence it's not a cross compiler or something, I just like cygwin's environment more than msys).
I'm wandering what you are patching and also why it takes so long for MinGW to release an official Gcc 4 cause I see no bugs at all.

Thnx, blahhh