Code::Blocks Forums

User forums => General (but related to Code::Blocks) => Topic started by: reckless on August 24, 2017, 06:19:12 pm

Title: multilib mingw-w64 TDM compiler
Post by: reckless on August 24, 2017, 06:19:12 pm
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.
Title: Re: multilib mingw-w64 TDM compiler
Post by: BlueHazzard on August 25, 2017, 07:41:24 pm
and i am sitting here with gcc4.9 xD
Title: Re: multilib mingw-w64 TDM compiler
Post by: reckless on August 26, 2017, 02:58:10 am
Time for an upgrade then !  ;D .

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 :).
Title: Re: multilib mingw-w64 TDM compiler
Post by: reckless on August 26, 2017, 07:27:07 am
https://sourceforge.net/projects/cbadvanced/files/MinGW%20Builds/TDM/ (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  ;D
Title: Re: multilib mingw-w64 TDM compiler
Post by: BlueHazzard on August 26, 2017, 11:39:49 am
The naming is quite odd... Is the "i686-w64-" part really needed?
Title: Re: multilib mingw-w64 TDM compiler
Post by: reckless on August 27, 2017, 12:49:40 pm
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 ?  ;)
Title: Re: multilib mingw-w64 TDM compiler
Post by: BlueHazzard on August 27, 2017, 01:58:23 pm
Quote
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:
Quote
(folks even complained about me using 7zip earlier)
How can this be a reason for complaining?  :o
Title: Re: multilib mingw-w64 TDM compiler
Post by: reckless on August 28, 2017, 10:24:35 am
Guess some old school guys got offended that i used it instead of tar ;D

The long name was adapted because of that, it seems some people want to have the entire description in the archive name  :-X 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.
Title: Re: multilib mingw-w64 TDM compiler
Post by: gd_on on August 30, 2017, 04:54:48 pm
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
Title: Re: multilib mingw-w64 TDM compiler
Post by: gd_on on August 31, 2017, 09:19:00 am
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
Title: Re: multilib mingw-w64 TDM compiler
Post by: reckless on September 09, 2017, 10:21:05 pm
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 ?).
Title: Re: multilib mingw-w64 TDM compiler
Post by: stahta01 on September 10, 2017, 05:02:39 am
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.
Title: Re: multilib mingw-w64 TDM compiler
Post by: gd_on on September 10, 2017, 10:51:23 am
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
Title: Re: multilib mingw-w64 TDM compiler
Post by: reckless on September 10, 2017, 02:12:47 pm
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).



Title: Re: multilib mingw-w64 TDM compiler
Post by: stahta01 on September 10, 2017, 05:30:12 pm
Quote from: reckless on September 10, 2017, 02:12:47 pm
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.
Title: Re: multilib mingw-w64 TDM compiler
Post by: reckless on September 11, 2017, 10:49:22 am
Quote
The TDM's 32 bit build was always built from mingw.org instead of MinGW64 code base.

Exactly :). The feature with having distinct dll names is worth having though, so im working on it.
Main reason it's not in yet is that later gcc versions had some changes that require me to recreate the patch used for this feature. Also the mingw.builds script needs some adjustment so that it builds cleanly.
Title: Re: multilib mingw-w64 TDM compiler
Post by: oBFusCATed on September 17, 2017, 11:54:13 am
Have you tried to build wx3.0.3 with this compiler? I'm experimenting with mingw-w32 and mingw-w64 and they fail badly because of duplicate symbols. Which is known problem but mingw devs seem to not care too much about it.
Title: Re: multilib mingw-w64 TDM compiler
Post by: gd_on on September 17, 2017, 12:24:27 pm
A possible workaround is to add LDFLAGS="-Wl,--allow-multiple-definition" in your build command.
So in my case to build with MinGW32 I have :
mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 USE_OPENGL=1 VENDOR=cb CXXFLAGS="-fpermissive -fno-keep-inline-dllexport -std=gnu++11 -Wno-deprecated-declarations" LDFLAGS="-Wl,--allow-multiple-definition"

or with MinGW64 :
mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 USE_OPENGL=1 VENDOR=cb_64 CXXFLAGS="-fpermissive -fno-keep-inline-dllexport -std=gnu++11 -Wno-deprecated-declarations" LDFLAGS="-Wl,--allow-multiple-definition"

gd_on
Title: Re: multilib mingw-w64 TDM compiler
Post by: oBFusCATed on September 17, 2017, 02:52:21 pm
I know and I'm not doing this... The compiler (its libs to be precise) is just broken.
If they don't fix it, then we couldn't use it and we should not recommend it to people!

p.s. mingw compilers on windows are so broken... I'm trying the mingw installer and it just locked up...
Title: Re: multilib mingw-w64 TDM compiler
Post by: stahta01 on September 17, 2017, 03:44:56 pm
Quote from: oBFusCATed on September 17, 2017, 02:52:21 pm
I know and I'm not doing this... The compiler (its libs to be precise) is just broken.
If they don't fix it, then we couldn't use it and we should not recommend it to people!

I am planning on trying to fix the duplicate error; but, I have had issues of submitting my possible fix to the wrong git repo.
The last time they said not here (it turned out to be just an git mirror); and to delete the dups instead of commenting them out.

In the next few months, I plan to try once more.

Tim S.
Title: Re: multilib mingw-w64 TDM compiler
Post by: reckless on October 01, 2017, 05:10:24 pm
Hmm ? Though im using the Msys2 non multilib versions myself i used allmost all of they're patches in building this, not sure why it works with these or might this be a multilib only problem ? .

Might also explain why ada fails to build in the multilib versions since its giving me a lot of junk about missing or wrong library exports.

Title: Re: multilib mingw-w64 TDM compiler
Post by: reckless on October 03, 2017, 07:30:39 am
stahta, could you throw me a patch for the duplicate error ? ill try to get it accepted upstream.
Title: Re: multilib mingw-w64 TDM compiler
Post by: stahta01 on October 03, 2017, 08:34:33 am
Code
Subject: [PATCH] uuid.c: Removed DEFINE_GUID also in extras-uuid.c.

---
 mingw-w64-crt/libsrc/uuid.c | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/mingw-w64-crt/libsrc/uuid.c b/mingw-w64-crt/libsrc/uuid.c
index 481e6752..18cd1278 100644
--- a/mingw-w64-crt/libsrc/uuid.c
+++ b/mingw-w64-crt/libsrc/uuid.c
@@ -42,15 +42,9 @@ DEFINE_GUID(CLSID_CFontPropPage, 0x0be35200,0x8f91,0x11ce,0x9d,0xe3,0x00,0xaa,0x
 DEFINE_GUID(CLSID_CPicturePropPage,0xbe35202,0x8f91,0x11ce,0x9d,0xe3,0,0xaa,0,0x4b,0xb8,0x51);
 DEFINE_GUID(CLSID_ConvertVBX,0xfb8f0822,0x164,0x101b,0x84,0xed,0x8,0,0x2b,0x2e,0xc7,0x13);
 DEFINE_GUID(CLSID_CurrentUserClasses,0x332,0,0,0xc0,0,0,0,0,0,0,0x46);
-DEFINE_GUID(CLSID_FileProtocol,0x79eac9e7,0xbaf9,0x11ce,0x8c,0x82,0,0xaa,0,0x4b,0xa9,0xb);
-DEFINE_GUID(CLSID_FtpProtocol,0x79eac9e3,0xbaf9,0x11ce,0x8c,0x82,0,0xaa,0,0x4b,0xa9,0xb);
-DEFINE_GUID(CLSID_GopherProtocol,0x79eac9e4,0xbaf9,0x11ce,0x8c,0x82,0,0xaa,0,0x4b,0xa9,0xb);
-DEFINE_GUID(CLSID_HttpProtocol,0x79eac9e2,0xbaf9,0x11ce,0x8c,0x82,0,0xaa,0,0x4b,0xa9,0xb);
-DEFINE_GUID(CLSID_HttpSProtocol,0x79eac9e5,0xbaf9,0x11ce,0x8c,0x82,0,0xaa,0,0x4b,0xa9,0xb);
 DEFINE_GUID(CLSID_IdentityUnmarshal,0x1b,0,0,0xc0,0,0,0,0,0,0,0x46);
 DEFINE_GUID(CLSID_InProcFreeMarshaler,0x1c,0,0,0xc0,0,0,0,0,0,0,0x46);
 DEFINE_GUID(CLSID_LocalMachineClasses,0x331,0,0,0xc0,0,0,0,0,0,0,0x46);
-DEFINE_GUID(CLSID_MkProtocol,0x79eac9e6,0xbaf9,0x11ce,0x8c,0x82,0,0xaa,0,0x4b,0xa9,0xb);
 DEFINE_GUID(CLSID_PSBindCtx,0x312,0,0,0xc0,0,0,0,0,0,0,0x46);
 DEFINE_GUID(CLSID_PSClassObject,0x30E,0,0,0xc0,0,0,0,0,0,0,0x46);
 DEFINE_GUID(CLSID_PSClientSite,0x30d,0,0,0xc0,0,0,0,0,0,0,0x46);
@@ -59,7 +53,6 @@ DEFINE_GUID(CLSID_PSEnumerators,0x313,0,0,0xc0,0,0,0,0,0,0,0x46);
 DEFINE_GUID(CLSID_PSGenObject,0x30c,0,0,0xc0,0,0,0,0,0,0,0x46);
 DEFINE_GUID(CLSID_PSInPlaceActive,0x30f,0,0,0xc0,0,0,0,0,0,0,0x46);
 DEFINE_GUID(CLSID_PSInPlaceFrame,0x310,0,0,0xc0,0,0,0,0,0,0,0x46);
-DEFINE_GUID(CLSID_PSUrlMonProxy,0x79eac9f1,0xbaf9,0x11ce,0x8c,0x82,0,0xaa,0,0x4b,0xa9,0xb);
 DEFINE_GUID(CLSID_PersistPropset,0xfb8f0821,0x164,0x101b,0x84,0xed,0x8,0,0x2b,0x2e,0xc7,0x13);
 DEFINE_GUID(CLSID_Picture_Dib,0x316,0,0,0xc0,0,0,0,0,0,0,0x46);
 DEFINE_GUID(CLSID_Picture_EnhMetafile,0x319,0,0,0xc0,0,0,0,0,0,0,0x46);
@@ -71,7 +64,6 @@ DEFINE_GUID(CLSID_StdHlink,0x79eac9d0,0xbaf9,0x11ce,0x8c,0x82,0,0xaa,0,0x4b,0xa9
 DEFINE_GUID(CLSID_StdHlinkBrowseContext,0x79eac9d1,0xbaf9,0x11ce,0x8c,0x82,0,0xaa,0,0x4b,0xa9,0xb);
 DEFINE_GUID(CLSID_StdMarshal,0x17,0,0,0xc0,0,0,0,0,0,0,0x46);
 DEFINE_GUID(CLSID_StdPicture,0xbe35204,0x8f91,0x11ce,0x9d,0xe3,0,0xaa,0,0x4b,0xb8,0x51);
-DEFINE_GUID(CLSID_StdURLMoniker,0x79eac9e0,0xbaf9,0x11ce,0x8c,0x82,0,0xaa,0,0x4b,0xa9,0xb);
 DEFINE_GUID(CLSID_StdURLProtocol,0x79eac9e1,0xbaf9,0x11ce,0x8c,0x82,0,0xaa,0,0x4b,0xa9,0xb);
 DEFINE_GUID(FLAGID_Internet,0x96300da0,0x2bab,0x11cf,0xa2,0x29,0,0xaa,0,0x3d,0x73,0x52);
 DEFINE_GUID(FMTID_DocSummaryInformation,0xd5cdd502,0x2e9c,0x101b,0x93,0x97,0x8,0,0x2b,0x2c,0xf9,0xae);
@@ -113,7 +105,6 @@ DEFINE_GUID(CLSID_InternetZoneManager, 0x7B8A2D95,0x0AC9,0x11D1,0x89,0x6C,0x00,0
 DEFINE_GUID(IID_IClassActivator,0x140,0,0,0xc0,0,0,0,0,0,0,0x46);
 DEFINE_GUID(IID_IClassFactory2,0xb196b28f,0xbab4,0x101a,0xb6,0x9c,0,0xaa,0,0x34,0x1d,0x7);
 DEFINE_GUID(IID_IClientSecurity,0x13D,0,0,0xc0,0,0,0,0,0,0,0x46);*/
-DEFINE_GUID(IID_IClientSiteHandler,0xf4f569d1,0x593b,0x101a,0xb5,0x69,0x8,0,0x2b,0x2d,0xbf,0x7a);
 /*DEFINE_GUID(IID_ICodeInstall,0x79eac9d1,0xbaf9,0x11ce,0x8c,0x82,0,0xaa,0,0x4b,0xa9,0xb);
 DEFINE_GUID(IID_IConnectionPoint,0xb196b286,0xbab4,0x101a,0xb6,0x9c,0,0xaa,0,0x34,0x1d,0x7);
 DEFINE_GUID(IID_IConnectionPointContainer,0xb196b284,0xbab4,0x101a,0xb6,0x9c,0,0xaa,0,0x34,0x1d,0x7);
@@ -238,7 +229,6 @@ DEFINE_GUID(IID_IRpcProxyBuffer34,0x3bd5f56a,0x1a59,0xb510,0x69,0x8,0,0x2b,0x2d,
 DEFINE_GUID(IID_IRpcStub,0x5,0,0,0xc0,0,0,0,0,0,0,0x46);
 /*DEFINE_GUID(IID_IRpcStubBuffer,0xd5f56afc,0x593b,0x101a,0xb5,0x69,0x8,0,0x2b,0x2d,0xbf,0x7a);*/
 /*DEFINE_OLEGUID(IID_IRunnableObject,0x00000126,0,0);*/
-DEFINE_GUID(IID_IServerHandler,0xf4f569d0,0x593b,0x101a,0xb5,0x69,0x8,0,0x2b,0x2d,0xbf,0x7a);
 /*DEFINE_GUID(IID_IServerSecurity,0x13E,0,0,0xc0,0,0,0,0,0,0,0x46);*/
 /*DEFINE_GUID(IID_ISimpleFrameSite,0x742b0e01,0x14e6,0x101b,0x91,0x4e,0,0xaa,0,0x30,0xc,0xab);*/
 /*DEFINE_GUID(IID_ISpecifyPropertyPages,0xb196b28b,0xbab4,0x101a,0xb6,0x9c,0,0xaa,0,0x34,0x1d,0x7);*/
@@ -246,8 +236,6 @@ DEFINE_GUID(IID_IServerHandler,0xf4f569d0,0x593b,0x101a,0xb5,0x69,0x8,0,0x2b,0x2
 DEFINE_GUID(IID_IStub,0x26,0,0,0xc0,0,0,0,0,0,0,0x46);
 DEFINE_GUID(IID_IStubManager,0x6,0,0,0xc0,0,0,0,0,0,0,0x46);
 /*DEFINE_GUID(IID_ISupportErrorInfo,0xdf0b3d60,0x548f,0x101b,0x8e,0x65,0x8,0,0x2b,0x2b,0xd1,0x19);*/
-DEFINE_GUID(IID_ITargetEmbedding,0x548793c0,0x9e74,0x11cf,0x96,0x55,0,0xa0,0xc9,0x3,0x49,0x23);
-DEFINE_GUID(IID_ITargetFrame,0xd5f78c80,0x5252,0x11cf,0x90,0xfa,0,0xaa,0,0x42,0x10,0x6e);
 /*DEFINE_GUID(IID_ITypeChangeEvents,0x20410,0,0,0xc0,0,0,0,0,0,0,0x46);*/
 /*DEFINE_GUID(IID_ITypeInfo2,0x20412,0,0,0xc0,0,0,0,0,0,0,0x46); */
 /*DEFINE_GUID(IID_ITypeLib2,0x20411,0,0,0xc0,0,0,0,0,0,0,0x46); */
-- 
2.14.2.windows.1

Tim S.
Title: Re: multilib mingw-w64 TDM compiler
Post by: reckless on October 06, 2017, 12:02:16 pm
Thanks ill start pestering the devs :)
Jokes aside, i hope it will get accepted cross your fingers.
Title: Re: multilib mingw-w64 TDM compiler
Post by: reckless on October 06, 2017, 12:09:25 pm
Patch posted on the mingw-w64 mailing list.
Title: Re: multilib mingw-w64 TDM compiler
Post by: reckless on October 06, 2017, 02:22:46 pm
patch accepted :) thanks stahta.

Quote
Subject: [PATCH] uuid.c: Removed DEFINE_GUID also in extras-uuid.c.

Patch OK after putting the list of duplicates removed in the commit message.

Thanks.
Title: Re: multilib mingw-w64 TDM compiler
Post by: oBFusCATed on October 06, 2017, 08:32:39 pm
So the next release of mingw-w64 will be able to build wx3.x?
Title: Re: multilib mingw-w64 TDM compiler
Post by: stahta01 on October 07, 2017, 01:16:04 am
Quote from: reckless on October 06, 2017, 02:22:46 pm
patch accepted :) thanks stahta.

Please post when the patch is committed to the git repo.

Thank you

Tim S.
Title: Re: multilib mingw-w64 TDM compiler
Post by: reckless on October 07, 2017, 02:09:21 am
Should be up soon if i understand JonY correctly, its a small change for a long standing bug so i doubt it will have to wait for the next release.
Title: Re: multilib mingw-w64 TDM compiler
Post by: reckless on October 07, 2017, 02:15:09 am
Quote
So the next release of mingw-w64 will be able to build wx3.x?

I can build it allready with the git version, not sure if Tim's patch was allready applied as i did a build a few hours after posting the patch. So unless they used some other means to get over this bug, then it looks like it's allready up.
Title: Re: multilib mingw-w64 TDM compiler
Post by: stahta01 on October 07, 2017, 02:27:26 am
Quote from: reckless on October 07, 2017, 02:15:09 am
Quote
So the next release of mingw-w64 will be able to build wx3.x?

I can build it allready with the git version, not sure if Tim's patch was allready applied as i did a build a few hours after posting the patch. So unless they used some other means to get over this bug, then it looks like it's allready up.

What git url are you using because it was not in the url I tried 3 hours ago.

Tim S.
Title: Re: multilib mingw-w64 TDM compiler
Post by: reckless on October 07, 2017, 12:29:24 pm
This one https://git.code.sf.net/p/mingw-w64/mingw-w64 and ok, not sure why it builds here then ?!?. I asked JonY when it will be availiable, ill post when he gets back to me.
Title: Re: multilib mingw-w64 TDM compiler
Post by: stahta01 on October 07, 2017, 01:44:37 pm
No need to ask when it will be committed; I just wished to confirm I had the right URL to watch.

Edit: The multi-lib wxWidgets builds without issue; but, the monolithic build errors out without the patch.
Unless, you add the allow multiple linker option.

Tim S.
Title: Re: multilib mingw-w64 TDM compiler
Post by: reckless on October 09, 2017, 11:45:11 pm
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/57311fedb4960ad7d8b444b34c06a41f32b13702/

committed, unfortunatly the patch ended up as being by me when committed upstream, sorry about that :/.

But it should be availiable in the master branch now atleast.
Title: Re: multilib mingw-w64 TDM compiler
Post by: reckless on October 10, 2017, 06:04:36 pm
as for where to post future patches then it's here mailto:mingw-w64-public@lists.sourceforge.net  but you need to subscribe first at the sourceforge site.
Title: Re: multilib mingw-w64 TDM compiler
Post by: reckless on October 10, 2017, 06:06:07 pm
Last pull had the fix, so we are good to go :)
Title: Re: multilib mingw-w64 TDM compiler
Post by: oBFusCATed on October 10, 2017, 09:49:12 pm
Let me know when there is a released binary, so I can try it.
Title: Re: multilib mingw-w64 TDM compiler
Post by: reckless on October 10, 2017, 11:32:44 pm
I can upload new build with the fixed runtimes if nessesary, but it might be faster for some to just do a git pull from master and then rebuild the headers and crt from there if they have Msys2 or Msys.

Also i might have fixed the image assertions in the WxWidgets-3.0.3 codeblocks builds for good, i can now open and build with it without any errors so far.

Might not be the correct place but what i did was this.

in  src/main.cpp in the MainFrame::MainFrame(wxWindow* parent) function put 

// avoid image assertions, initialize all image backends.
wxInitAllImageHandlers();

just after

// New: Allow drag and drop of files into the editor
SetDropTarget(new cbFileDropTarget(this));

after this the only oddity is that the codeblocks IDE flickers in the tray for a few moments before showing, no errors though.
Title: Re: multilib mingw-w64 TDM compiler
Post by: reckless on October 11, 2017, 12:20:15 am
https://sourceforge.net/projects/cbadvanced/files/MinGW%20Builds/TDM/mingw64-TDM-gcc-6.4.0-2.7z/download
https://sourceforge.net/projects/cbadvanced/files/MinGW%20Builds/TDM/mingw32-TDM-gcc-6.4.0-2.7z/download

Now sports python-3.4 as well as python-2.7 for those who might want to try out that.
To use the Tools and libraries in /mingw<arch>/opt you will need to have them on path, this can be done in several ways.
From CodeBlocks add to <additional paths>
From Msys or Msys2, modify /etc/profile and add it there.
From Cmd via batch file.

Make sure /mingw<arch>/opt/bin comes after /mingw<arch>/bin.

I can also upload a snapshot of the 64 bit wx-3.0.3 CodeBlocks build mentioned earlier.
Title: Re: multilib mingw-w64 TDM compiler
Post by: oBFusCATed on October 11, 2017, 12:53:36 am
@reckless: What asserts? Can you post backtrace?
Title: Re: multilib mingw-w64 TDM compiler
Post by: reckless on October 11, 2017, 09:35:18 am
wxBitmap.IsOk() kept comming up with a trace to an existing image, but i could get around that by selecting cancel, was a bit annoying though.

So i started looking up if anyone else was running into that problem, and found a thread on the WxWidgets forum pointing out that you need to initialize all the image handlers first to avoid that assert.
Title: Re: multilib mingw-w64 TDM compiler
Post by: ollydbg on October 11, 2017, 05:28:55 pm
Quote from: reckless on October 11, 2017, 09:35:18 am
wxBitmap.IsOk() kept comming up with a trace to an existing image, but i could get around that by selecting cancel, was a bit annoying though.

So i started looking up if anyone else was running into that problem, and found a thread on the WxWidgets forum pointing out that you need to initialize all the image handlers first to avoid that assert.
I don't see this issue (mingw-build gcc 5.4 32bit compiler + wx3.1 release (with this patch applied #17483 (wxDynamicCast segfault with mingw64 5.3.0 release build) – wxWidgets (https://trac.wxwidgets.org/ticket/17483) + codeblocks svn head)

EDIT: I normally only build the core plugins, so you issue may caused by the contributed plugins.
Title: Re: multilib mingw-w64 TDM compiler
Post by: reckless on October 11, 2017, 07:21:49 pm
Cant rule it out, but atleast it works for me now :)
the old wxwidget-2.8 build has worked like a charm, a native 64 bit build does have its advantages though, but untill now i had problems with it, so im happy :)
Title: Re: multilib mingw-w64 TDM compiler
Post by: reckless on October 11, 2017, 07:28:21 pm
built wx monolithic both old 2.8 and 32 / 64 bit versions of wx 3.0.0, so it works now :)
Title: Re: multilib mingw-w64 TDM compiler
Post by: oBFusCATed on October 12, 2017, 09:28:55 am
Quote from: reckless on October 11, 2017, 09:35:18 am
wxBitmap.IsOk() kept comming up with a trace to an existing image, but i could get around that by selecting cancel, was a bit annoying though.

So i started looking up if anyone else was running into that problem, and found a thread on the WxWidgets forum pointing out that you need to initialize all the image handlers first to avoid that assert.
Please post the backtrace from gdb or the assert dialog window.
Title: Re: multilib mingw-w64 TDM compiler
Post by: gd_on on October 14, 2017, 07:55:17 pm
I have a very annoying problem with your last version (mingw32). When I start C::B or when I try to compile something, I obtain a message "there is no disk in dive H:". Such messages were related in some other threads, but when using gdb apparently. It's not my case, I just want a release version. If I click on the button "continue" several times (many many ...), compilation is completed succesfully and my compiled program works.
With official Mingw32 6.4.0 (posix version, but not sure it's important here, file i686-6.4.0-release-posix-sjlj-rt_v5-rev0.7z), I have no such annoying messages.
I remember that with old TDM version (4.7 or 4.8, I don't remember exactly), there was already such problems, solved by TDM in a next version.
I have effectively a H: drive on my PC. It's true that there is no disk in it, but I can't put something there, because it's for a specific memory card that I don't have.

gd_on
Title: Re: multilib mingw-w64 TDM compiler
Post by: stahta01 on October 14, 2017, 08:18:28 pm
@gd_on: Looks like the compiler was built on H drive.

I would see if renaming H drive is possible to another letter.
No idea what letters are good to use.

Tim S.
Title: Re: multilib mingw-w64 TDM compiler
Post by: reckless on October 26, 2017, 11:53:47 am
Hmm i thought that problem was fixed ages ago ?.
Ah i see the problem now, Msys2 mingw64 use a hack to sysroot the compiler to its own directory, but the mingw-builds script does not so it tries to run the compiler from the build dir which in your case does not exist... sigh. Ok i will have to modify the build script to use the same hack as Msys2 then, or use the TDM hack instead (not sure which is worse).

Ill see if i can get a test build up soon.

Turned out the assert in WxBitMap was caused by me being an idiot, i forgot to point the codeblocks build to the right folder, so it used an old broken version.
Title: Re: multilib mingw-w64 TDM compiler
Post by: reckless on October 30, 2017, 11:46:18 am
The problem and something that should really be looked at by the gcc devs is that gcc when built in mingw context hardcodes the mingw dir to /mingw which in case of mingw64 does not exist. Also this path should be the full windows path to the compiler dir and not the short posix version which was a hack for the old msys because it converted posix paths at runtime to windows format. You can get around in Msys2 by making a symlink to /mingw but in windows with codeblocks that wont help.

Finally got mingw-builds to accept the sed script to replace the hardcoded paths, building now.
Title: Re: multilib mingw-w64 TDM compiler
Post by: reckless on November 02, 2017, 10:47:28 pm
ugh sysroots need to diaf, on windows they cause more problems than they fix :( its basically impossible to shortcircuit sysroots in later versions of gcc (post 4.9 versions) )  so i had to create crosscompilers for every arch with the now defunct runtime version 4 because the above versions are incompatible with any newer versions. Then i had to update the runtimes to version 5
and then rebuild the same compiler again because else it would not accept the new runtime. To make matters worse sysroot now only accepts windows absolute paths which are then hardcoded into the compiler causing the compiler to fail building anything if it is moved sigh... on the plus side i seem to be able to build the gnat compiler again but with hardcoded windows paths it will piss of devs to no end.
Title: Re: multilib mingw-w64 TDM compiler
Post by: reckless on November 03, 2017, 07:30:49 am
Doh  >:( it has nothing to do with where gcc was built, its gettext that causes this error. Sadly there is no fix only a workaround proposed by keith marshall that renames the offending drives, ill see if i can get a hold on the patch. Removing it will only cause gcc to loose i18n support, so we do not want that.

Ada is also of the table if you want the 32 bit multilib compiler, theres a major bug in recent code causing ada to fail building if 32 bit multilib is selected. In a nutshell it is caused by g++ defaulting to SSE in 64 bit builds, but somehow they broke the logic cause if you try building a 32 bit multilib compiler then it will try and use the 64 bit SSE mechanics on ada which it cant. This also seems to be the reason why no one has built any 32 bit multilib compilers with ada for some time. The 64 bit version works though so if you really need ada support i can atleast upload that.
Title: Re: multilib mingw-w64 TDM compiler
Post by: dawn on April 01, 2019, 12:19:56 pm
Any news about a new release with a more recent gcc version?