This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: towards a good embedded userland cross-build system


Robert Schwebel wrote:
Just wait until you try to support gcc-3.3 and glibc-2.3.2 -- you may
change your mind!  Some files have to be installed twice, kind of, I
think.  I'm not sure if that kind of dependency can be expressed.  But
maybe I'm just pessimistic.

After my recent experiences with gcc-3* on Debian unstable I'm not quite
sure if I'll try it Very Soon (TM) ;)

Can you give me details about the gcc-3* bugs you think you're seeing? I'd like to address them.

I've had good luck with gcc-3.3.1 so far.  It's good stuff.
Debian is tripping over its own shoelaces a bit here, I think.
And boy do they patch their compiler!  I'm trying hard to keep my
patchsets minimal, but Debian seems to rejoice in complex, undocumented
patchsets.

The PTXdist "framework" is currently very thin: every makefile does
support a "get - extract - prepare - compile - install - targetinstall"
target; build targets touch state/foobar.target.

Sounds a bit like GAR (http://www.lnx-bbc.org/garchitecture.html). Did you look at that one?


Look at the less
complex examples (e.g. dropbear) in rules/ to get the idea. If you just
want the toolchain all you need is Makefile, rules/Rules.in and the
makefiles for binutils, *glibc, *gcc. Should not be more than what you
currentl have.

I'll look at it, but I have a feeling the toolchain build can't be expressed as Makefiles properly. What rule would one have for /usr/include/stdio.h? That gets installed twice -- once before building the bootstrap gcc (I'm not kidding; it's awful), and once before building the real gcc.

Currently the "large" Makefiles (e.g. glibc) are bloated by the fact
that all possible combinations are hand-ifdefed which is plain uggly. I
suppose size and readability can be significantly reduced by using your
nice automatisms to find out which patches have to applied to which
packages based on the version numbers.

Yes, switching to a table-driven approach would probably help.


Even when I finally settle on a userland build framework that uses
Make or whatever, it may have a prerequisite that you have already got
a toolchain installed and working.

You need a host toolchain for initial bootstrap; PTXdist builds a cross compiler even for i386 (other x86s are not yet supported/tested).

Yes, of course, even for i386 I would build a fresh cross-compiler; I don't want the build machine's local files leaking into the target. But I don't know that the toolchain should be built by the same machinery that builds everything else. FWIW, one of my users' requirements is that they not have to build the toolchain, so I have to have a two-step process anyway.

What I would like to see in the future is a collaboration regarding
things like the patches; it definitely needs a critical mass testing and
using stuff to make it maintainable, so doing the same thing twice is a
waste. If I cannot argue you into switching to PTXdist ;) I'll try to
integrate your patch system first to see how it feels like...

Sounds like a good idea. - Dan

--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045


------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]