Vincent Rivière wrote:
By script I meant the RPM build spec files. Those are where you need to tease out changes in order to install the right files in the end to the right freemint style directories. For instance we use /usr/info not /usr/share/info, etc In terms of configure options, and patches, I will inspect your patches, my old ones and make sure you aren't missing anything and go from there.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.
Well it's nice that you're willing to do the patches. Before Keith and I did the patches AND the packaging ;)> I'm pretty good at making RPM's from these though, andthere 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.
I am working on this now. It seems our libtool needs upgraded for this to be packaged. So I built a new libtool and working on binutils now.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.Well this is a problem and it signals a need for ELF support in mint for sure but I know that's a big job. I've been reading up on BSD internals but it's a huge project - more than I anticipated.
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.Or I can just build it with my installed gcc 3.3.3? I think zorro actually built gcc independently too from Keith and I. Lots of people are duplicating this work, all because sparemint isn't getting updated rpm's. Can you tell I'm bitter yet? Alan's gentoo setup with binary package setup and a nice distcc setup should be a welcome thing to try.
Well this would be cool ;) I'm starting to use deeper and deeper features of GDB and I know the latest one has a pretty curses view. BTW I saw you upgraded to curses 5.1. This is another thing I upgraded and packaged 5.3 some time ago. I did work you could have used but again it never got done :-/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.
This reminds me of another problem. I can't seem to use gdb to debug windom in XaAES. The whole system freezes (under Aranym, anyway, haven't tried native but I'm sure it would be the same). I have to use N.AES. There's some nice problem there ;) I was told to use printf debugging but not only is that insane on a big program like GEM Instant Messenger but in terms of console output the bug was a moving target (the libfaim library did things based on callbacks so the signin process could be at different points before the crash making printf debugging futile).
- 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" (?).Ooh but can gcc generate ELF binaries without system support for them? I guess so, it would make sense.
- 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.
Seems like a good idea :)
So, lots of things to do ;-) Let's go !
Ok :)