Cross-compiling toolchain default location choice

[Dan Kegel]

ncrfgs wrote:
> After having successfully built a cross-compiling toolchain thanks to 
> cross-lfs (http://www.linuxfromscratch.org/~ryan/scripts/cross-lfs/), 
> I'm trying to adapt the wonderful scripts written by Ryan Oliver for 
> the Linux From Scratch system, to the form of some package building 
> scripts for the GNU/Linux distribution I'm using at the moment, CRUX 
> (http://www.crux.nu/), a lightweight source-based GNU/Linux 
> distribution.

Did you also look at http://kegel.com/crosstool?  Ryan is contributing
improvements to those, too.  (He wanted NPTL support, and sent in a patch.
I'll try to add that in the next release.)

> Unfortunately while trying to accomplish this task I'm facing some 
> problems, first of all the choice of the cross-compiling toolchain 
> default location.
> 
> What do you think is the best location in the filesystem for the 
> cross-compiling toolchain or, in other words, what do you think is 
> the best configure time prefix to use? At the moment I put it into
> /opt/ppc/usr but I wonder whether is there a way to make it to 
> coexist with the "regular" toolchain in /usr or whether is there a 
> better location to put it into.

I like putting it in /opt/cross/$target/bin/$target-gcc.

> Another problem I'm facing from the package management point of view 
> are the files that gcc and glibc share among the different build 
> steps.
> 
> Let's take for example the case of gcc. The gcc-static package shares 
> all of its files with the gcc-shared package while the following 
> files are included in the gcc-shared package only.
> 
> $PREFIX/lib/gcc-lib/powerpc-unknown-linux-gnu/3.3.3-hammer/libgcc_eh.a
> $PREFIX/powerpc-unknown-linux-gnu/
> $PREFIX/powerpc-unknown-linux-gnu/lib/
> $PREFIX/powerpc-unknown-linux-gnu/lib/libgcc_s.so -> libgcc_s.so.1
> $PREFIX/powerpc-unknown-linux-gnu/lib/libgcc_s.so.1
> 
> Should gcc-shared be seen as a gcc-static "upgrade"? Or may I safely 
> delete from the gcc-shared package all the files already installed by 
> gcc-static and leave only the new ones (namely libgcc_eh.a and 
> libgcc_s.so*)?

I think the 2nd gcc can completely replace the 1st.

> What when, just like in the case of the different glibc builds, the 
> two packages shares only some files?

I suspect the 2nd glibc can completely replace the 1st.

But I'm not sure why you care.  The full toolchain - gcc and glibc and binutils -
should be a single package built all at once.  You should not try to
mix and match, it's too painful.  Crosstool makes a single RPM for all components
of the toolchain.
- 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