A longstanding pair of minor bugs has existed in the Windows ToolChain since I put it together, and after MANY recompiles and even more tests, googling, hair pulling, late nights, IRC chats and so on, the fix was found and resolved.
The bugs were basically two-fold. First off, the build was being done not quite exactly the same as the debian packages which are configured with a prefix of /usr and then relocated-during install int oa temp dir (the debian package buildroot) before being wrapped up with a shiny bow. For some reason when I built the script to roll the windows binaries I didn’t do it that way (lazy, incompetent, didn’t notice? who knows), this lead to some minor issues internal to binutils where the linker scripts installed in c:/usr/m68hc11/lib/ldscripts had incorrect “SEARCH_DIR” settings that referenced my build machine. Configuring with –prefix=/usr and using a relocated install solved that first issue…
Me being the pragmatic bloke, figured the same would work with GCC, but alas, it’s never THAT easy. Using the same method with GCC as with binutils, resulted in a correct gcc library search path and correct path to crt1.o, but the code that compiled resulted in DIFFERENT .s19 md5sums (the firmware was different with this toolchain vs my reference toolchain on linux). I took many many many (too damn many) tests, investigation of code, chats with the #GCC folks on IRC to figure out exactly what was wrong. It turns out due to a friendly tip from a GCC developer on freenode, to compare the output config.cache on GCC runs where it created good md5’s vs where it didn’t and low and behold I found that GCC was detecting the WRONG linker/assembler to use (not entirely sure how, but it’s likely a path issue, or some oddness in how autoconf searches for things). Two mystery options “–with-ld=/path/to/linker” and “–with-as=/path/to/assembler” solves the issue and the resulting GCC crosscompiler creates matching md5sums to the reference compiler AND fixes the bad path to crt1.o, so the hardcoded path within the makefile can now go away (already committed in the dev branch). This means that it is possible to compile LibreEMS on windows via the command prompt and via git-bash’s shell, though I’ve noticed that that shell seems to act a bit odd at times resulting in a compile failure, where it never fails under CMD.
All in a months work….
New binaries are here: http://builds.libreems.org/ToolChains/Windows/