TDM-GCC 4.5 series (Latest: 4.5.2 - 2011-03-27)

[TDragon]

For wxWidgets, I added RCFLAGS to makefile.gcc per the attached patch and then added RCFLAGS="-F pe-i386" to the wxWidgets make command. This is the equivalent of "-m32" for windres, the resource compiler.

For Code::Blocks, there is no RCFLAGS equivalent so I had to use a custom build command for the .rc files: $rescomp -F pe-i386 -i $file -J rc -o $resource_output -O coff $res_includes

[attachment deleted by admin]

[billyonthemountain]

Thanks, it works correctly now... both wx and C::B
There one issue remaining :
In the binutils bundled with the mingw64/multilib version, the strip utility doesn't accept wildcards but the mingw32 one does, which can be problematic when running the update.bat script... An easy workaround is of course to keep a copy of that 2nd strip.exe somewhere in the PATH, but not really elegant...  :?

[sankarbose]

might explain why it works here my binutils where patched to allways use runtime-pseudo-reloc-v2 as default.

xerces examples work with that.

can you tell me how should i do it ??

[reckless]

LDFLAGS="-Wl,--enable-runtime-pseudo-reloc-v2".

the l is not a 1 (lowercase L) that one had me stomped for a while  :lol:

[sankarbose]

Hi reckless
thanks for the answer but i like to know where should i add the ld flag so that it uses the --enable-runtime-pseudo-reloc-v2 option all the time ?
 is it in the ldscripts files if yes where should i add the line ?

the l is not a 1 (lowercase L) that one had me stomped for a while  Laughing

Ha ha i had also quite a Time with this one. :lol:

[reckless]

got the patch from here http://195.135.221.130/pub/opensuse/repositories/windows:/mingw:/win32/openSUSE_Factory/src/ you need to rebuild binutils with the patch in there binutils src rpm, but tbh its just as easy just doing LDFLAGS="-Wl,--enable-runtime-pseudo-reloc-v2" ./configure --blah and you might run into problems with other stuff with runtime pseudo relocation allways on.

[Max]

I have two questions about the latest TDM GCC (4.5.0)

1) In the download page the 32 bit binutils is linked to the 2.20.1 version. The 64 bit version is linked to the latest 2.20.51 instead. Becasue the 2.20.51 is enable the pseudo-reloc-v2  by default I'm wondering why the 32 bit is still using the old one. Is there any reason for that?

2) I'm using the TDM-GCC 4.4.1 but I'm getting trouble throwing an exception from a thread and catching it in another thread. My understanding is that the exception mechanism is not thread safe in 4.4.1. Is this bug fixed in the 4.5.0 (that is really using TLS now). This bug is the only reason that is pushing me to upgrade. So I need to know if 4.5.0 has a a thread safe exception handling.

Thx

max

[reckless]

might just not have been updated yet, mingw64 is normally heaps and bounds ahead of normal mingw in implementing new tech.

and gcc-4.5.0 supports thread local storage, how stable it is i cant vote for though but it works ok here

[TDragon]

1) In the download page the 32 bit binutils is linked to the 2.20.1 version. The 64 bit version is linked to the latest 2.20.51 instead. Becasue the 2.20.51 is enable the pseudo-reloc-v2  by default I'm wondering why the 32 bit is still using the old one. Is there any reason for that?

For the 32-bit edition I elect to provide only GCC's own binaries and use the MinGW project's official releases for the other packages. At the time that TDM-GCC 4.5.0 was released, the latest MinGW binutils release was 2.20.1. A newer version has since been released, and as soon as I'm convinced it has no severe regressions, I'll update the links and the installer.

2) I'm using the TDM-GCC 4.4.1 but I'm getting trouble throwing an exception from a thread and catching it in another thread. My understanding is that the exception mechanism is not thread safe in 4.4.1. Is this bug fixed in the 4.5.0 (that is really using TLS now). This bug is the only reason that is pushing me to upgrade. So I need to know if 4.5.0 has a a thread safe exception handling.

All recent TDM-GCC releases have been tested to work correctly throwing exceptions within threads, but trying to throw an exception in one thread and catch it in another is just asking for trouble, particularly as Windows has no concept of a true "joinable" thread. You should instead catch the exception in your thread function, convert it to heap memory if it isn't there already, and transfer it to your other thread via some synchronization function.

[keke]

I'm trying to build TDM-GCC 4.5.0 32 bits from the sources using the provided makefile and scripts. I think I correctly followed the instructions but I'm stuck somewhere (during the compilation of the ppl lib I think). It says:

Code

/bin/sh ../libtool --tag=CXX   --mode=link g++  -g -O2 -frounding-math -O2 -I/cr
ossdev/support-stage-tdm32/gmp/include -W -Wall  -version-info 8:0:1 -no-undefin
ed -s -L/crossdev/support-stage-tdm32/gmp/lib -o libppl.la -rpath /crossdev/supp
ort-stage-tdm32/ppl/lib Box.lo checked.lo Checked_Number.lo Float.lo fpu-ia32.lo
 Constraint.lo Constraint_System.lo Congruence.lo Congruence_System.lo Generator
_System.lo Grid_Generator_System.lo Generator.lo Grid_Generator.lo Init.lo Coeff
icient.lo Linear_Expression.lo Linear_System.lo Matrix.lo Scalar_Products.lo MIP
_Problem.lo Poly_Con_Relation.lo Poly_Gen_Relation.lo BHRZ03_Certificate.lo H79_
Certificate.lo Grid_Certificate.lo Polyhedron_nonpublic.lo Polyhedron_public.lo
Polyhedron_chdims.lo Polyhedron_widenings.lo C_Polyhedron.lo NNC_Polyhedron.lo G
rid_nonpublic.lo Grid_public.lo Grid_chdims.lo Grid_widenings.lo BD_Shape.lo Oct
agonal_Shape.lo Pointset_Powerset.lo Row.lo Linear_Row.lo Bit_Matrix.lo Bit_Row.
lo Ph_Status.lo Grid_Status.lo Variable.lo Variables_Set.lo conversion.lo minimi
ze.lo simplify.lo Grid_conversion.lo Grid_simplify.lo stdiobuf.lo c_streambuf.lo
 globals.lo mp_std_bits.lo version.lo    wrap.lo -lm -lgmpxx -lgmp
/bin/grep: /mingw/lib/gcc/mingw32/4.5.0/libstdc++.la: No such file or directory
/bin/sed: can't read /mingw/lib/gcc/mingw32/4.5.0/libstdc++.la: No such file or
directory
libtool: link: `/mingw/lib/gcc/mingw32/4.5.0/libstdc++.la' is not a valid libtoo
l archive
make[4]: *** [libppl.la] Error 1
make[4]: Leaving directory `/crossdev/build/ppl-tdm32/src'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/crossdev/build/ppl-tdm32/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/crossdev/build/ppl-tdm32'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/crossdev/build/ppl-tdm32'
make: *** [ppl] Error 2

I see it can't find libstdc++.la but according to the building instructions  (unless I didn't understand them correctly) provided in the TDM release, /mingw should be empty at this point. Then it's normal it can't find libstdc++.la in this path.

Any Idea?

Thanks

[TDragon]

No, I've never seen that error before.

[keke]

@TDragon:

Is /mingw/lib/gcc/mingw32/4.5.0/libstdc++.la supposed to exist at this point of the building process or not?
If I understand the instructions correctly /mingw should be empty before I start the script.

[a14331990]

Is the patch auto-import.diff from dave korn (and slightly modified by me) already applied?
Have a look at here.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
This patch will enable auto-import by default in binutils and works well.
Best Regards.
a14331990 a.k.a Leo  

[TDragon]

It shouldn't matter whether or not there is a MinGW installation in /mingw when you build the dependencies. I've done it both ways myself. Again, I have no idea why you would be seeing that error.

To be clear, I have even less time to support building GCC from source than I have to support the use of the TDM-GCC binaries. Building non-Windows-specific software from source, particularly GCC, is *not* a straightforward process on Windows. It requires a lot of trial and error, stubbornness, and the willingness to dig as deeply as necessary into the sources to figure out the problem yourself. Don't expect much help from me.

[thomas]

cc1plus.exe: error: LTO support has not been enabled in this configuration

Any chance for that to happen in a future release, pretty please?