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: Cross-compiling toolchain default location choice


ncrfgs wrote:
Not being able to find any file with powerpc-unknown in its name ...

That's because there are many flavors of powerpc. You have to know which one you need.

> I continued
with the demo-ppc750.sh script and then with the powerpc-750.dat and
gcc-3.3.3-glibc-2.3.2.dat files.

Those are good choices, appropriate e.g. for a G3 Power Mac. What hardware are you planning to target?

Starting to be a bit frustrated I gave a look at what patches were going to be applied. I changed to the patches directory and I looked for something like gcc-3.3.3-hammer in it. Unfortunately there was no gcc-3.3.3-hammer directory and gcc-3.3.3 looked like the closest to gcc-3.3.3-hammer to me. Then I changed to the gcc-3.3.3 directory and...


The whole point of crosstool was to have only the bare minimum of patches


... I found twentyone different patches. (!!!) Most of them were called pr<something> in a way that I found impossible to understand what were they about without opening the patch file itself.

If you're not willing to look inside the patches, you'll miss the description of what the patch is for. You will find that crosstool fixes a lot of problems that cross-lfs doesn't. You can achieve the clarity of cross-lfs's lack of patches by simply deleting all the patches in the crosstool patch directory.

Furthermore, if just for gcc there were twentyone different patches what about the other packages? It would have likely resulted in almost one hundred patches.

... I was scaried...

One cure for that is simply to have a look at the first few lines of each patch. They clearly state what problem the patch solves.

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.

As I said in my previous messages, I wanted to use a quite exotic combination of packages. Among them are glibc-2.3.3-20040410 and gcc-3.3.3-hammer-20040515, a snapshot dated 20040515 of the hammer branch of the gcc repository.

As all.sh states, crosstool is a "Script to download sources for, build, and test a gnu/linux toolchain".

How could I have made crosstool to download exactly the tarball I needed?

Put the tarball gcc-3.3.3-hammer-20040515.tar.gz into ~/downloads Create the file gcc-3.3.3-hammer-20040515-glibc-20040410.dat containing the lines BINUTILS_DIR=binutils-2.15 GCC_DIR=gcc-3.3.3-hammer-20040515 GLIBC_DIR=glibc-20040410 LINUX_DIR=linux-2.6.8 GLIBCTHREADS_FILENAME=glibc-linuxthreads-20040410 Add the line eval `cat powerpc-750.dat gcc-3.3.3-hammer-20040515-glibc-20040410.dat` sh all.sh --notest into demo-ppc750.sh, and comment out the other variants. Then run demo-ppc750.sh. I haven't tried this myself because 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.)

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.

On the contrary cross-lfs requires just few patches and uses a patch naming
scheme where almost all the patches bring in their names the architecture the
patch is intended for, so one can easily skip the unneeded ones.

I suppose I could try to put the architecture into the patch name more often, for architecture-specific ones.

Moreover the archive tree is organized in such a way that I was easily able to find the building scripts in no time.

Um, the scripts for crosstool are at the top. What more do you want?


Please, I hope that it's clear that this is just my opinion. Everywhere I read about cross-compiling your name comes out. You are an authority in this field now. :D I'm sure crosstool works great for almost everyone but one of my main goals was to understand what I were doing instead of "just let it run an wait for the results". I don't like the "do everything for me" things. Of course it's just a matter of taste.

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.

As I said in my previous messages, from this point of view, cross-lfs seemed to suit better my needs. The cross-lfs naming scheme looked clearer to me and more easy to understand, the use of stream editing instead of patches makes them almost "binutils/glibc/gcc/... version" indipendent and all of this came out being a very rich educationl experience.

Stream editing of source is a bad idea, IMHO. I use patches exclusively, it's much clearer, 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.

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.  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.

Thanks,
Dan

--
My technical stuff: http://kegel.com
My politics: see http://www.misleader.org for examples of why I'm for regime change

------
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]