[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] C++ Stuff

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