TDM's GCC 4.2.1 (now with iconv, Obj-C++ and Treelang)

[TDragon]

GCC 4.2.1 TDM-2 is now available! Objective-C++ and Treelang packages have been added, and GCC now uses libiconv for support for non-UTF-8 charsets (see -finput-charset, etc.). As always, you should be able to install in almost any directory, and use it from almost any directory (unless you're running Vista).

See http://www.tdragon.net/recentgcc/ for details.


====== Older =======

GCC 4.2.1 is out, I'm back from a trip to the mountains (and looking at another next week ), and it's time for another TDM GCC binary release! Drop-in replacements are available for the official MinGW gcc-core, gcc-g++, gcc-objc, and gcc-g77 packages. As always, core/g++ are tested working for wxWidgets and C::B. See http://www.tdragon.net/recentgcc/ for download links, installation information, and any further details you might need.

-John E. / TDM

[JGM]

Cool!

[jsibarani]

  still in honeymoon with your 4.2.0, and now i have to check for other..
 
 

[patlecat]

Kool man, I'll check it out asap! I just fear that 4.2.1 might be a show stopper  :? Because they removed a lot of deprecated code ... we'll see. Thanks a lot TD

[imbaczek]

This and previous version breaks when a directory of the same name as a standard include is on the include path:

Code

In file included from rts\System\Demo.cpp:12:
rts/Game/GameSetup.h:5:15: error: rts/map: Permission denied

line 5 is #include <map> and rts/Map is a directory. Workaround is to add -I/standard/include/dir as a first command line option, so it's not critical, but quite annoying.

[Ramazan Kartal]

Hi,

I have a problem with gcc 4.2.1. Whenever I try to compile one of my source files I get:

error: no iconv implementation, cannot convert from latin5 to UTF-8

Command line is as follows:

mingw32-g++.exe -DWINVER=0x0500 -g -O0 -fno-inline -DDEBUG1 -Wall -fexceptions -mthreads -finput-charset=latin5  -IC:\MinGW\include -c K.cpp -o K.o

I guess this is related to "-finput-charset=latin5". I have to use this parameter since my sources have some Turkish characters. Can I correct this problem by copying "libiconv*.dll" from my Gnu Win32 utilities to somewhere in Mingw tree?

Regards
Ramazan Kartal
 

[TDragon]

This and previous version breaks when a directory of the same name as a standard include is on the include path:

Code

In file included from rts\System\Demo.cpp:12:
rts/Game/GameSetup.h:5:15: error: rts/map: Permission denied

line 5 is #include <map> and rts/Map is a directory. Workaround is to add -I/standard/include/dir as a first command line option, so it's not critical, but quite annoying.

Confirmed. I'll see about creating a GCC bug report.

Can I correct this problem by copying "libiconv*.dll" from my Gnu Win32 utilities to somewhere in Mingw tree?

No, I'm pretty sure GCC has to be linked to libiconv when built. Look for another release in the near future that is!

-John E. / TDM

[prilenko]

i installed the gcc 4.2.1,it worked well,but i found that the dbg can not work.just as follow:

int main()
{
  int i=8,j=9;
  int k=i+j;
  cout<<"k="<<k<<endl;
  return 0;
}
when i debug ,the watch window should show the values of i,j and k,but valued showed in the window are obviously wrong .but when i replaced Gcc by 3.4.5,it can correctly show the values.i can not understand why?

[TDragon]

The format of the debugging information produced by GCC has probably changed since 3.4.5. Have you tried upgrading to MinGW's GDB 6.6?

[Ramazan Kartal]

Hi,

error: no iconv implementation, cannot convert from latin5 to UTF-8

Best solution is to compile one by yourself in msys/mingw. UTF-8 conversion depends on many things (mingw-runtime and winapi), so - it's more a problem of platform's subsystem (MinGW is "under" Windows, he isn't standalone, right?). BTW, compiler itself can be linked without any problems with static libiconv.a and I suggest you to avoid dll-hell doing the same. Libiconv has nasty circular dependency with libintl from gettext /chicken or egg situation/ and because of that (and many other things) iconv has never ever been properly compiled for MinGW.

Actually I don't use libiconv.dll in my programs, it is only required by gcc itself if I specify "-finput-charset=latin5" as a parameter, which I should. However, I use libpng.dll and zlib1.dll. You're right,  it can cause "dll hells", for that I am planning to use "LoadLibrary".

Quote from: Ramazan Kartal on 26 July 2007, 22:12:00
Can I correct this problem by copying "libiconv*.dll" from my Gnu Win32 utilities to somewhere in Mingw tree?
No, I'm pretty sure GCC has to be linked to libiconv when built. Look for another release in the near future that is!

I would be grateful if you provide one.

Regards,
Ramazan Kartal

[Ramazan Kartal]

-------------- my man. If you download my gettext-iconv-expat rar archive, you can try it... it's gcc version independent and newest one. If it doesn't work, take plan B.

I don't use any function from gettext, iconv or expat, why should I try it? Also do you really know what "g--- k--------" means?

Regards,
Ramazan Kartal

[thomas]

Huh... looks like self denial. It means "to get free of something troublesome (e.g., a job) with very little damage" (Turkish phrase I've used and picked up earlier god knows where).

The phrase you used is an off-colour idiom which may be quite offensive to people. Please don't use non-english phrases on this board (even more so if you are not sure about their implication).

[roland]

can anyone compile allegro 4.2.2 with this?

It fails for me with this error some time into compilation:

Code

gcc -DALLEGRO_LIB_BUILD -Wall -Wno-unused -mtune=i586 -O2 -funroll-loops -ffast-math  -fomit-frame-p
ointer -DSETUP_USE_COMPILED_DATAFILES -I. -I./include -o obj/mingw32/alleg/setup.o -c setup/setup.c
setup/setup.c: In function 'joystick_handler':
setup/setup.c:2483: error: unrecognizable insn:
(insn 138 136 139 11 (set (reg:SI 182)
        (const:SI (plus:SI (mem:SI (symbol_ref:SI ("#i.joy") <var_decl 015DC4D0 joy>) [0 S4 A8])
                (const_int 312 [0x138])))) -1 (nil)
    (nil))
setup/setup.c:2483: internal compiler error: in extract_insn, at recog.c:2077
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
mingw32-make: *** [obj/mingw32/alleg/setup.o] Error 1

*edit*
I've posted about it on the Allegro forums. The response I got indicates it may be bugs in the compiler. I'm just curious if anyone else would mind trying, and see what kind of headway you can get in case it is something wrong with my config. All the details are in this post:
http://www.allegro.cc/forums/thread/592549

[jimmyo]

Hello,

I get an error while build binutils.
i use Build.txt description to install and run scripts under mSYS/mingw.

/bin/sh ./libtool --mode=link gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -g -O2   -o                                      ar.exe  arparse.o arlex.o ar.o not-ranlib.o arsup.o rename.o binemul.o emul_vanilla.o bucomm.o version.o                                      filemode.o ../bfd/libbfd.la ../libiberty/libiberty.a   
gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -g -O2 -o ar.exe arparse.o arlex.o ar.o no                                     t-ranlib.o arsup.o rename.o binemul.o emul_vanilla.o bucomm.o version.o filemode.o  ../bfd/.libs/libbfd.                                     a ../libiberty/libiberty.a
arlex.o: In function `main':C:/msys/1.0/extra/crossgcc/cross-binutils-build/binutils/arlex.c:1: multiple                                      definition of `main'
arparse.o:C:/msys/1.0/extra/crossgcc/cross-binutils-build/binutils/arparse.c:1: first defined here
ar.o: In function `main':C:/msys/1.0/extra/crossgcc/cross-binutils-build/binutils/../../binutils-2.17.50                                     -20060824-1-src/binutils/ar.c:337: multiple definition of `main'
arparse.o:C:/msys/1.0/extra/crossgcc/cross-binutils-build/binutils/arparse.c:1: first defined here
ar.o: In function `mri_emul':C:/msys/1.0/extra/crossgcc/cross-binutils-build/binutils/../../binutils-2.1                                     7.50-20060824-1-src/binutils/ar.c:141: undefined reference to `yyparse'
collect2: ld returned 1 exit status
make[4]: *** [ar.exe] Error 1
make[4]: Leaving directory `/extra/crossgcc/cross-binutils-build/binutils'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/extra/crossgcc/cross-binutils-build/binutils'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/extra/crossgcc/cross-binutils-build/binutils'
make[1]: *** [all-binutils] Error 2
make[1]: Leaving directory `/extra/crossgcc/cross-binutils-build'
make: *** [all] Error 2


Any solution ?

  Jimmy

[tyrus]

Very good work TDM. I have compiled lots of libraries and programs here and everything looks fine. The only problem that I found was in some .la in the lib directory that was pointing to yours cross-compile directory.