msys2 ucrt32 cross compiler done

[revelator]

by request i have made a ucrt32 version of the msys2 mingw cross compiler for bootstrapping a mingw-w64-i686-ucrt32 compiler.

this version can be used to make 32 bit ucrt versions of current mingw packages for use on vista and greater os versions.

since this is a by request build it might not make it into the official msys2 repo's but ill make it avaliable for developers to add to the existing msys2 toolchain.

 

[revelator]

here is the version for jeremys msys2 32 bit msys2 fork.

https://sourceforge.net/projects/cbadvanced/files/msys2-cross-mingw-w64/

the msys2 64 bit version is still building but can be found here when done -> https://sourceforge.net/projects/cbadvanced/files/msys2-cross-mingw-w64 64Bit/

[revelator]

for those interrested the ada or gnat compiler is not currently buildable but we might be able to use the same hack to get it going as was used to build ada for the ucrt64 version of mingw-w64.

Fortran C and C++ should be bootstrappable without any problems, ada however needs its own seperate ada compiler since it cannot be built with C / C++ alone.

 

[revelator]

another note. since the ucrt32 version is not part of the official repo i will have to make my own version of the the msys2 filesystem package since this is needed for integration with the msys2 toolchain.

i will probably also have to make my own version of the shell launchers so that we have an easy way of starting a bash shell for the mingw-w64-i686-ucrt32 toolchain, this also means i have to modify the msys2 batch file so that it will work with the mingw-w64-ucrt32 toolchain.

so a lot of work ahead.

i will also make a TDM based version of both ucrt32 and ucrt64 for those who dont want there executables depending on the libgcc and libstdc++ dll's (exceptions will still work). the TDM version is pretty stable by now but a few packages cannot be linked to the static libgcc/libstdc++ which is not a problem with the TDM patches since they are also broken with plain gcc if the runtimes are linked statically (so far the only two packages that refuse to work when linked to the static runtimes are ogre3d and gdk-pixbuf2).

[revelator]

currently building the gcc cross compiler because it needs to be built before the rest of the toolchain.

afterwards ill start building the rest of the cross toolchain so i expect it will be done by tomorrow.

for those who might not want to wait for the changes to the msys2 filesystem you can use this guide.

in /etc find the msystem file and open it with notepad++,  you will see a large block of text with settings for the different compilers so scroll down to ucrt64 and make a copy of the block from UCRT64) to the two ;; at the end of the block. now paste it below the ;; in the UCRT64 block and change x86_64 to i686 and ucrt64 to ucrt32 and prefix to /ucrt32. now open makepkg_mingw.conf and do the same copy of the ucrt64 block and paste it below the ucrt64 block. CFLAGS change -march=nocona -msahf -mtune=generic to -march=pentium4 -mtune=generic and MINGW_PREFIX to /ucrt32 save the two files and done.

now comes the hard part you need to modify the msys2_shell.cmd file as otherwise theres no way to start a shell for the new compiler so here we go. find this block

if "x%~1" == "x-ucrt64" shift& set /a msys2_shiftCounter+=1& set MSYSTEM=UCRT64& goto :checkparams and copy it off and paste it below. then change x-ucrt64 to x-ucrt32 and MSYSTEM=UCRT64 to MSYSTEM=UCRT32. 

now this block ->

else if "%MSYSTEM%" == "UCRT64" (
  set "CONTITLE=MinGW UCRT x64"
  set "CONICON=ucrt64.ico"
)

copy it off and paste it below so it becomes

else if "%MSYSTEM%" == "UCRT64" (
  set "CONTITLE=MinGW UCRT x64"
  set "CONICON=ucrt64.ico"
) else if "%MSYSTEM%" == "UCRT32" (
  set "CONTITLE=MinGW UCRT x86"
  set "CONICON=ucrt32.ico"
) 

and this part

echo     -mingw32 ^| -mingw64 ^| -ucrt64 ^| -clang64 ^|
echo     -msys[2] ^| -clangarm64          Set shell type

make it

echo     -mingw32 ^| -mingw64 ^| -ucrt32 ^| -ucrt64 ^| -clang64 ^|
echo     -msys[2] ^| -clangarm64          Set shell type

save and make a shortcut to the batch file then in properties put -ucrt32 after the batch file name (remember to make a space between the batch file name and the variable).

now the shortcut will open the ucrt32 compiler when it has been built.

the launcher executables will do that part when im done editing them.

EDIT: you also need to add the ucrt32 toolchain to /usr/bin/makepkg-mingw

[revelator]

64 bit msys2 version is done and up on the sourceforge site.

currently building the mingw-w64-ucrt32 compiler toolchain.

it will not have a gnat compiler to start with since it requires a working gnat compiler to start with, but there are plans to use the same method as was used for ucrt64 to have one.

a TDM based version will also be supplied which is geared more towards building standalone programs on windows without needing the gcc runtime dll's.

[revelator]

MinGW UCRT32 version done and can be downloaded here -> https://sourceforge.net/projects/cbadvanced/files/Ucrt32/

[datiswous]

I have no clue what this is about..

[revelator]

it is a 32 bit version of the mingw compiler using the universal runtime instead of the old msvcrt

the Msys2 project only provides the 64 bit version as they are moving away from 32 bit.

You can use it to make windows compatible software eg. games / dependencies for windows (must be atleast vista as ucrt does not support older windows versions than that).

I done it by request so it wont have a full package repository like UCRT64 does and it will not be added to the official Msys2 repo. Ill provide compiler builds and integration with Msys2 but packages users will have to build themself.

[revelator]

the upside to building with the above compared to the standard mingw 32 and 64 bit compilers is better compatibility with windows 10 and up as they use the universal runtime instead of msvcrt.

[revelator]

btw. the current uploaded compiler is not working because of a simple oversight.

the bootstrap compiler used gcc's own libssp and not the mingw-w64 dummies which means it will fail to run unless you copy of libssp-0.dll from the winlibs ucrt compiler and place it in /ucrt32/bin.

im currently rebuilding the toolchain without the libssp library from gcc so that it will work correctly with Msys2. Sorry about that...

The upside to this is that im including my runtime-config script in the new build to make it easier to use the static runtimes in case you absolutely dont want your code to rely on the gcc unwinder and exception dll's.

this version however will not support throwing exceptions across dll boundaries (32 bit problem only as the exception mechanism is incompatible with windows SEH exceptions. gcc uses dwarf or sjlj in 32 bit).

ill post a version based on the TDM compiler later which does support it.

[datiswous]

9 hours ago, revelator said:

it is a 32 bit version of the mingw compiler using the universal runtime instead of the old msvcrt

But who needs 32 bit nowadays?

[revelator]

mostly people working with emulators like pcem and clones which work better with 32 bit.

also still needed for some older sources not ported to 64 bit because the benefit of doing it would be neglible or just not there.

as posted i did the port by request, and it is indeed a niche product but wanted non the less

[revelator]

fixed compiler uploaded btw. totally forgot .

currently building the rust toolchain for use with it since a lot of the libraries on the Msys2 repo depends on it.

llvm/clang done just havent had time to upload it. ill upload it together with the rust toolchain.

[revelator]

btw. there are actually toolchains out there targetting ucrt32 but the benefit of having one specifically for the Msys2 version is the large library of packages and the package manager which eases building somewhat.

i also uploaded the Msys2 filesystem and pacman changes as well as updated launchers.

64 bit Msys here https://sourceforge.net/projects/cbadvanced/files/Msys64/

32 bit Msys here https://sourceforge.net/projects/cbadvanced/files/Msys32/

without these you cannot use them with Msys2 as the unmodified filesystem has no paths for the Ucrt32 compiler only Ucrt64.

[revelator]

the tdm version of ucrt32 will probably replace the current compiler as it works just as well.

the difference is that packages linked to the static gcc runtimes do not support throwing exceptions across dll boundaries on the normal ucrt compiler, the tdm version does support it. that is not to say you should link everything to the static runtimes as some packages behave very buggy when doing so (gdk-pixbuf ogre3d). i added my runtime-config script to the compiler to ease using the static runtimes, it does this by copying the static libstdc++.a to libstdc++.dll.a and libgcc_eh.a to libgcc_s.a. this might seem a little convoluted but there is actually a very good reason it was done this way instead of using the -static-libgcc and -static-libstdc++ flags. -static-libstdc++ does not work to well as the linker sees

-lstdc++ which both the static and shared runtime use so it links to the shared. we could get away with -static-libgcc but i decided against it because the script would become even more messy than it is.

so to build against the static runtimes you call runtime-config with no arguments before configure and runtime-config -shared after make or whatever build command you use.

it is mostly intended for people who want to build standalone programs something which the Msys2 MinGW / Clang compilers are not really geared towards.

[revelator]

go llvm and rust toolchains done and will be uploaded next.

a lot of packages on the Msys2 MinGW repos depend on these as many sources have moved away from standard C/C++. rust is needed for the svg imaging library (probably one of the first packages that got ported) and many more. go is used for a lot of networking tools like some git additions. llvm/clang can be used as a replacement compiler for C/C++ and it's libraries are used all over the place. this will conclude the compiler toolchain for my part and building packages for it will be up to users themself.

[revelator]

go and ruby packages are up, ill also throw in the vulkan development packages.

have tested building some quake engines with ucrt32 and they work pretty well with it

[revelator]

started building packages with it and so far it works just fine. got the qt packages and dependencies built as well as most of the gtk toolchain. going to try my hand at building kdevelop since we allready have most of the KDE toochain as packages (preferably a standalone version). kdevelop is an IDE which supports multiple compilers a bit like codeblocks but using QT/KDE, the interface is pretty straight forward and there have been a few versions built for windows but they where all a bit messy to set up (batch files ???). if i can ill make a version that can plug in to msvc / mingw without having to jump through firewheels .

lets see how it goes.

[revelator]

Built most packages and also started adding back the 32 bit clang compiler. The 32 bit clang has some problems though especially with rust due to how it handles allocating memory. Rust uses a huge ammount of memory when bootstrapping > 64gb unfortunatly clang uses memory mapping instead of malloc so it runs headlong into oom when building rust. gcc still uses a more traditional malloc based memory allocator and makes use of the physical adress extension which clang has removed causing problems with sources that allocate more than 4gb.

So the latest rust version is limited to rust-1.81 which still uses the 2021 model and has some problems building libraries like librsvg due to duplicate symbols (bcrypt). And also goes bonkers on libraries like dovi where it produces a gnu style dll (libdovi.dll) but the import library points to an msvc style dll (dovi.dll) sigh.

Atleast it is easy to work around the dll name by simply renaming it, the duplicate symbol problem is not fixable without being able to build a newer version of rust which we cant so argh...

Lukily i can build rsvg with the ucrt gcc compiler and rust and use it with clang but it needs to be linked with the static gcc runtimes otherwise we would need to also copy the gcc dlls.

Some other changes in clangs libc++ like deprecating char_trait have also left a mess.

[revelator]

took a lot of patching rust but i got rid of the duplicate symbol madness. cannot build the latest librsvg sources with it though since those rely on a newer model of rust so i had to build the previous version which still worked.

works as it should as far as i can see and opens svg images with no problems whatsoever.

so the 32 bit clang is done and all packages that can be built with the 32 bit version are finished.

many of these packages are a lot more stable than the gcc based ucrt32 builds so it is worth considering.

only downside until i can port classic flang is the lack of fortran modules for some tools.

[revelator]

i ditched the TDM unwinder changes completely in favor of the method used by msys2 clang.

the libstdc++ dll now uses the static unwinder by default which means C++ code that relies on the dll (needed if throwing exceptions across dll boundaries) no longer requires the libgcc dll, it is wholly standalone like clangs libc++.

this could probably use some refinement because it does run the risk of duplicate symbols because the libstdc++ dll now has the C unwinder symbols linked in. one way to get around this would be with C++ wrappers around the unwinders so that the the symbols dont collide when linking with libgcc_eh and libstdc++ so something along this line

#ifdef __cplusplus C++ wrapper for say _Unwind_Resume with a different symbol (something like _unw_resume maybe)

#else

standard C _Unwind_Resume

#endif

 

[revelator]

hmm seems that is also the way it is done on clang so it might be the way to go forward.

biggest hurdle is that the autotool based build system would need some changes so that it can be made optional like it is on clang. sadly while i can make some changes with autotool based build systems im far from an expert on it .

 

[revelator]

ucrt32 ada compilers are done and working .

using the static gcc runtimes for the dynamic C++ exception handler was the way to go to cut down on the dll madness it works splendidly so far. even the few projects that previously had problems with the TDM based exception mechanism work without a problem now (gdk-pixbuff librsvg ogre3d). for C++ projects that uses exceptions you still need the libstdc++ dll but it no longer pulls in the libgcc dll unwinders as these are now part of the libstdc++ dll.

atm trying to get rust updated to latest but it is a grind... rust relies heavily on specific LLVM versions so to build the later versions you need to upgrade LLVM rust and a ton of support stuff arghhhhhh!!!!.

got pyinstaller working with 32 bit gcc + ucrt (msys2 dropped 32 bit for everything besides the old msvcrt based mingw versions and even with that they could not get it to build with the 32 bit version  ) the fix was really simple though -> point the environment variable CC to where gcc is located. yeah sounds insane but pyinstaller defaults to a 64 bit compiler unless specifically told by the compiler that it is a 32 bit version, it does not detect it otherwise lol.

 

[revelator]

cmake has some problems on 32 bit i noticed especially the later versions (4.0 and onward).

sometimes throws an exception saying it cannot find a file but does not tell me which file it was looking for groan (more debugging ahead i reckon).

restoring 32 bit compiles on packages which have it disabled from the msys2 repo is time consuming and really not a one man job. help wanted! .

besides atm i barely have time to do any of that as my mom has entered critical phase and will probably leave this world at months end