multilib mingw-w64 TDM compiler

[gd_on]

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

[stahta01]

@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.

[reckless]

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.

[reckless]

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.

[reckless]

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.

[reckless]

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.

[dawn]

Any news about a new release with a more recent gcc version?