[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] C++ Stuff
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, 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.
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 ==
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
- 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 !