Re: [MiNT] C++ Stuff

[Vincent Rivière <vincent.riviere@freesbee.fr>]

Mark Duckworth wrote:

> > The problem is that we didn't manage to make a clean native build of 
> > GCC 4.X, with RPM packages.
> Ok, well I guess I will work on it.

It would be wonderful !

> I can find all my build scripts but I trust 
> yours better.

No script is better, you should merge the two ones in order to make the 
best RPM build script.
My build scripts are crappy, they don't contain error handling, and they 
cannot be run without human monitoring. However, they contain all the 
commands and options for patching, compiling, and building a binary 
archive. They can act as a reminder for what needs to be done for 
building binary packages.

However, the most valuable things on my website are the MiNT patches. I 
try to keep them as perfect as possible. So if one want to make a binary 
distribution of the tools (.tar.bz2, RPM, Gentoo...), he just has to 
download the original sources, apply the MiNT patch as-is, and build the 
software in the usual way for its packaging system.

> I'm pretty good at making RPM's from these though, and
> there are a number of ways to cheat the RPM build process so that you 
> can fix bugs incrementally rather than restarting the build process.  
> Building rpm's of things like gcc mainly involves sending alerts to 
> yourself so hours later when something finishes you get an SMS letting 
> you know.  Makes it easier.

Wow, you have a great experience !
Personally, I prefer spend my time on the patches rather than the 
packaging. So if you do the RPM packaging, our effort will be available 
to every MiNT user (as requested recently by Olivier Landemarre), so we 
will get more feedback for improving the patches, the packaging, and so on.

Some quick information about the status of my patches :

- binutils 2.19.1 patch is clean, for the MiNT target as well as the 
MiNT host. So it is ready for RPM packaging !

- GCC 4.3.3 : It seems to work quite well for the MiNT target, and seems 
to produce code compatible with the existing libraries compiled with GCC 
2.95.3 (needs further testing). I know two serious bugs : when 
outputting an int with cout (sadly, very common), and when compiling 
some very complicated code using nested templates (Keith had problems 
when compiling ScummVM because of that). These two bugs doesn't seem to 
be related to the MiNT patches, they seem to appear when using the a.out 
 file format for the intermediate object files (we use it). And because 
the a.out file format is considered as obsolete (in profit of ELF), the 
gcc team doesn't care :-(. That kind of bug is very difficult to track, 
and probably impossible to fix without the help of the GCC developers.
My GCC patch is not ready for the MiNT host (native compilation), 
however MiKRO and Alan did it, so I plan to include their additional 
patches (if any).
One of the most annoying thing on the MiNT host it that currently, code 
has to be be compiled with GCC 2.95.3, it has a bug in the preprocessor 
so things like #if value != negative_constant returns the wrong result, 
it has to be rewritten like #if !(value == negative_constant)
The current binutils are patched against this, but gcc is not. So with 
this kind of bug in the compiler, we could easily miss a preprocessor 
test, then building an invalid compiler, and so on... Maybe we should 
fix this preprocessor bug in GCC 2.95.3 first (and repackage an RPM for 
it) before going further.

Finally, here are my current projects related to GCC :

- port the latest gdb to MiNT. It is complicated, because it's 
architecture has changed a lot, and some non-trival code has to be 
written nearly from scratch.

- use the ELF file format for intermediate object files. It will unlock 
some GCC features currently unavailable for us, and we will get rid of 
that a.out bugs in gcc that no one wants/know-how to fix. Using ELF is 
complicated, because the original linker patch expects a.out input 
files, but I already cleaned up some things and I got very nice results. 
GCC will have to be reconfigured, too, to take advantage of ELF 
features. Coming "soon" (?).

- adjust the MiNTLib scripts/makefiles in order to enable the gcc 
"bootstrap" process. That means building binutils/gcc/MiNTLib on one 
pass. This is difficult because gcc and MiNTLib have interdependencies, 
but the gcc makefiles have support for this, we "just" have to adapt the 
MiNTLib scripts and we will be able to build everything in a one pass, 
automated build, in the standard gcc way.

So, lots of things to do ;-)
Let's go !

--
Vincent Rivière