Cross-compiling toolchain default location choice
Mon Oct 4 06:15:00 GMT 2004
On Sun, Oct 03, 2004 at 04:44:13PM -0700, Dan Kegel wrote:
> Those are good choices, appropriate e.g. for a G3 Power Mac.
> What hardware are you planning to target?
I would like to be able to run the code on 32 bit PowerPC architectures in
> Um, the scripts for crosstool are at the top. What more do you want?
I'm not saying you are wrong, only that I wasn't able to.
> Stream editing of source is a bad idea, IMHO. I use patches exclusively,
> it's much clearer
Maybe with a different naming scheme. =)
> and the upstream maintainers are more likely to
> accept that kind of change. All the patches in crosstool
> are either taken from CVS, or are intended to be good enough for CVS,
> and will eventually be submitted to the gcc / glibc maintainers.
This is great. But one thing doesn't exclude the other IMO.
> I don't have the gcc-3.3.3-hammer-20040515.tar.gz tarball.
> (I suppose I should make crosstool smart enough to fetch things
> from gcc cvs, like it can for glibc, but I haven't yet.)
My previous messages weren't supposed to be a wishlist. Nobody sane could ever
ask you to keep a copy of every single daily cvs snapshot of every single
There is surely a way to make crosstool to use a custom tarball but maybe,
given the way they are written and the aims it wants to achieve, this is not
what crosstool is good at.
> > How could I have been sure everything would have worked and I would have
> > ran no risk?
> Buy a development system from Montavista. If you build your own
> stuff -- whether with crosstool, or with cross-lfs -- there is
> some risk.
> I obviously can't make you completely happy,
> since you seem to have unrealistic expectations (you want no risk),
> but I can at least deal with your realistic ones.
> Another cure for that is to leave out *all* the patches, and only bring
> in the patches one by one as you run into the problems they fix.
With no risk I didn't mean I wanted a nuclear-proof cross-compiling toolchain,
of course. :D The only way to run no risk is doing nothing at all. =) I just
exactly meant no risk to have to run the script several times and bring in the
patches one by one as I run into problems. What if the problem a patch fixes
doesn't show at compile-time but only at run-time?
> That's how I feel about it, too. This is why I want people to
> read and understand the scripts before running them, and
> read patches before applying them. Most people are too impatient
> to, though.
Please, be sure it's not about impatientness since If I were impatient I
wouldn't have spend any time reading and trying to adapt cross-lfs, too. =)
It's just that I found cross-lfs easier to read, to understand and to follow.
> Anyway, I like the guy who wrote the cross-lfs package, and I think
> he did fine work. I just want to make sure that I understand
> why you like his stuff better than crosstool, so I can address
> those problems.
Sorry I didn't mean to make you upset.
You asked me to tell you more about the problems I faced with crosstool and to
be more specific so I tried to. I didn't mean to tell you how to change
crosstool but just to try to explain why I preferred cross-lfs over crosstool.
Those were just the feelings of a user.
Value your freedom, or you will lose it, teaches history.
``Don't bother us with politics,'' respond those who don't
want to learn.
-- Richard M. Stallman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the crossgcc