[Freemint-list] Clean gcc buid for m68k-atari-mint

[Vincent Rivière]

On 05/01/2017 12:31, Miro Kropáček wrote:
> I've been studying cross compilers for ARM for some time so as a side
> effect I've learned quite a deal about cross compiling in general.

Actually, I did the opposite: I originally wanted a cross-compiler for 
ARM, so I started learning GCC for the more familiar Atari ST ;-)
And I never went back to ARM, btw :-(

> I was always wondering why our poor gcc must be built so differently
> from the standard ones like ARM or even m68k-elf.

So differently? Yes, building libc/libm in the middle is not really 
clean. But it was the only solution I found in early days, and I always 
continued like that...

> I thought it's because of the nature of Vincent's patches but as it
> turns out... it is not!

Indeed, the patches are clean. Actually, most of my work has been to 
clean the patches and make them minimal. So our target is as standard as 
possibles, and patches can be applied to upstream more easily.

> So I'm happy to present you my much cleaner Makefile for the gcc
> toolchain: https://github.com/mikrosk/m68k-atari-mint-build. The key
> difference is that it doesn't use any hacks, it's built as it was meant
> to be. :) So instead of building a semi-working gcc, joggling with
> include headers and whatnot we /explicitly/ configure gcc as "libc-less"
> (using /--without-headers/, /--with-newlib /and /--with-sysroot/),
> install it and use /that/ to build mintlib and pml (libc in general).

Excellent :-)

I never took the time to study the normal GCC bootstrap process. 
Actually, I wasn't sure it was possible with MiNTLib. And most of all, 
it was *so long* to rebuild everything with Cygwin 10 years ago that 
once I found a working method, I hadn't the courage to change.

Definitely, your method is the right one. Next time I build my binaries, 
I will try to upgrade with your process.

> With all that cleanness I've realised how pitiful the state of public
> headers in FreeMiNT/mintlib is.

Exactly, this is what stopped me to try cleaner things. Especially the 
lack of freemint-headers packages. With the clean packages you propose, 
we could easily integrate the cross-compiler to Linux distributions. And 
even automated builds, etc. This is the thing to do.

> So in case there's somebody wondering what would be a nice and not so
> complex task to improve FreeMiNT/mintlib relationship to Linux/Unix
> worlds, here's couple of hints:

I fully agree with you, this has to be done.

> TL; DR version: no real news, just a handful of wishes. ;)

Then go ahead :D

-- 
Vincent Rivière