I don't know much about build tools, or GCC in general. But what advantages would your build environment provide over the one by Lydux which is based on a newer version of GCC?
I assume you cannot compile doom using Lydux's toolchain, but why? I do remember him talking about his standard C library implementations being buggy, and incomplete, so that might be it?
Well the Lydux libraries leave a LOT to be desired... mostly that they don't work. I tried to fix some time functions, and it ended up just becoming a mess. I had tried to do a 'null' doom to see what it would do, and even putting a printf 'hi' in the start of main didn't work. There is other fundamental issues going on in there. Also the Lydux tool can't use the x68000 object format so you can't just switch to a different libc, if the issue was even revolving around libc. Sure there was some native GCC versions to the x68000 but I never could make heads or tails of them.
So switching gears I went to find out how the native stuff worked, and here we are.
The Lydux tools died, and with no debugging at all it's impossible to say what on earth is going on. There could be a whole host of issues, and I'm not even sure where to begin. But with a native compiler and thanks to run68 being able to run the assembler and linker on Windows (they are coded in assembly, so porting to C would take effort...) is a big help. It's easier to deal with crashes, and memory corruption when you fire up the emulator to run a single process (a-la run68 to assemble or link only), where running the toolchain in an emulator like xm6 suffers the same problems as trying to write software on MS-DOS, which is an unstable environment + unstable testing + unstable tools means lots of issues. SO for me, being able to compile outside of the emulator is a MASSIVE boon.
So yeah, the only issue I have is with m_fixed.c, which as my host CPU is little endian, but the 68000 is big endian. And I took the source dump for GCC as is, so it doesn't know it needs to swap bit field operations to work.. So you end up with this:
#- .dc.l $00000000,$40f00000
#+ .dc.l $40f00000,$00000000
But otherwise, it's so much faster, and easier to edit with native tools, and not worry about having to reboot the VM constantly to compile and test, only to test so it's much nicer. ... Not to mention it's nice to compare what is going on with a native vs cross build, which is how I found the issue with m_fixed .....
I'm amazed to see the system stuff Neko68 has put in, I never expected to actually be able to see anything on the screen!