Cross-compiling toolchain default location choice

ncrfgs ncrfgs@tin.it
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 
general.


> 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 
package. :D

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.



Best regards.
-- 
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
    http://www.gnu.org/philosophy/linux-gnu-freedom.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/crossgcc/attachments/20041004/7473978d/attachment.sig>


More information about the crossgcc mailing list