multilib mingw-w64 TDM compiler

[reckless]

Since TDM seems to have dissapeared     i decided to make a new build of his multilib compiler for mingw-w64.
gcc version is at 6.4.0 and since im using the mingw-builds build scripts as a base, it follows the mingw-builds directory structure (so no lib something _64).
This means that it is quite a bit easier to work with, the downside is that you will have dll's in some odd places like /mingw32/i686-w64-mingw32/lib.

The compiler defaults to linking statically to libgcc / libstdc++ and still supports throwing exceptions from static libgcc / libstdc++ like TDM's.
The packaged gdb uses mingw-w64 built python for pretty printing via a wrapper for gdb.

I will upload my gcc-6.4.0 builds shortly + build scripts. Just laying the final hand on the build scripts for previous versions of gcc for good measure .
Earlier versions of gcc might not sound like something that will be used much, but in some cases you run into sources that only build with earlier versions of gcc, in which case this comes in handy indeed.

Links will be posted in this thread when done.

[BlueHazzard]

and i am sitting here with gcc4.9 xD

[reckless]

Time for an upgrade then !  .

gcc-6.4.0 dual target should soon be up. atm i have problems building gnat due to the bootstrap compiler being to old (gcc-4.9.2) but c,c++,fortran,lto all work.
And yes you can cross build from a 32 bit OS to a 64 bit one and vice versa with these , but its kinda moot if you cannot test your 64 bit builds on a 64 bit machine i think.

Also be aware that g++'s std changed quite a bit since version 4 or 5 for that matter, it now defaults to c++14 in version 6.

packages should be up by tomorrow. You can also use these as replacements for Msys2's mingw-w64 compilers if you like .

[reckless]

https://sourceforge.net/projects/cbadvanced/files/MinGW%20Builds/TDM/

build scripts will be up later, takes some time to adjust TDM's patchsets for every concievable gcc version out there 

[BlueHazzard]

The naming is quite odd... Is the "i686-w64-" part really needed?

[reckless]

Could shorten it but i had complaints about it earlier (folks even complained about me using 7zip earlier), seems you cannot satisfy everyone .
As long as it works i don't really see what the naming convention matter, don't you agree ? 

[BlueHazzard]

Could shorten it but i had complaints about it earlier , seems you cannot satisfy everyone .

true that.
i was only complaining, because the other TDM versions didn't had this naming and i could change compiler by simply changing paths (exactly only one number) but i found out that i simply can rename the executable and they still work, so no problem for me anymore

OT:

(folks even complained about me using 7zip earlier)

How can this be a reason for complaining? 

[reckless]

Guess some old school guys got offended that i used it instead of tar

The long name was adapted because of that, it seems some people want to have the entire description in the archive name  so i686 for arch w64 descriptor and mingw32 to tell them its mingw for 32 bits. Tbh i found it a bit easier to read just mingw32 or mingw64 but im obviously in the minority in that regard hehe.

[gd_on]

Hi,
I tried these versions to build wxwidgets 2.8.12 and C::B in 32 and 64 bits.
I just met a small problem with 32 bits version. I had to add explicitely the -m32 option when using mingw32 (from gcc-6.4.0-posix-TDM-mingw32-w64-multilib.tar), as a CXXFLAGS to build wxwidgets and a default flag in C::B for gcc. I'm on Windows 7 Pro 64 bits.
This was not necessary with TDM original versions.
Despite this small problem, it works well as far as I have tested.
Thanks,

gd_on

[gd_on]

May be a problem not seen before.
My path is C:\MinGW32;C:\MinGW64;...
When I launch C::B in 64 bits, its loads and seems to run. But when I look at the loaded modules with "Dependancy Walker" a problem is identified with libwinpthread-1.dll : it is the version in C:\MinGW32 which is loaded, so a 32 bits version. 2 possible workarounds : invert MinGW* in path or add explicitely the 64 bits dll in the C::B 64 bits folder.
This was not a problem with TDM official (old) version because dll names were not the same (added a _64 string).

gd_on

[reckless]

Only use exactly one of these compilers, if you are on a 32 bit windows use the 32 bit version if on 64 bit then both versions are ok to use, but pick one and please don't add both to path, it confuses the compilers. If you follow these instructions then no additional flags like -m32 should be needed unless you intend to cross compile 32 bit binaries using the 64 bit compiler. 

Yeah its rather confusing and also why i newer used the multilib versions myself, but codeblocks expects a multilib version for development unless you hack around in the xml configuration files (unless that has been changed with newer versions ?).

[stahta01]

I find that if I wish to use two different MinGW GCC compilers, it is best to add neither to the system path variable.

Tim S.

[gd_on]

OK.
But with "old" TDM versions (4.9.2 or 5.1) this configuration was OK for many years ! No confusion between compilers versions 32/64. May be because TDM add a _64 to specific 64 bits dll version !
gd_on

[reckless]

It has nothing to do with the dll suffixes, its because you have two versions of the compilers on PATH with different switches for what to build.
Say for instance that the 32 bit gcc is first on PATH, it will expect flags like -m64 to cross compile a 64 bit binary but does not expect -m32 because its a 32 bit compiler. And the reverse is true for the 64 bit version if that one is first on PATH.

Also TDM newer had multilib compilers for both arch's which i suspect is what is causing confusion.

As a rule of thumb newer mix compilers even if they seem to work, in most cases you end up having something that does not .
Also it's totally unnessesary since both versions can create both 32 and 64 bit executables.

If you do end up with something depending on say the libwinpthread.dll then you can find both the 32 and 64 bit version's of these dll's in
/mingw32/i686-w64-mingw32/lib (for 32 bit) and /mingw32/i686-w64-mingw32/lib64 (for 64 bit) or in
/mingw64/x86_64-w64-mingw32/lib (for 64 bit) and /mingw64/x86_64-w64-mingw32/lib32 (for 32 bit).

[stahta01]

Also TDM never had multilib compilers for both arch's which i suspect is what is causing confusion.

The TDM's 32 bit build was always built from mingw.org instead of MinGW64 code base.

Tim S.