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] |
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
Attachment:
pgp00000.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |