User forums > General (but related to Code::Blocks)

multilib mingw-w64 TDM compiler

<< < (10/11) > >>

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page