This is the mail archive of the crossgcc@sourceware.org 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: making gcc relocatable->fixed


On Monday 26 June 2006 12:48 pm, Mike Frysinger wrote:
> On Monday 26 June 2006 09:09, NZG wrote:
> > > no, you moved the wrong libs
> >
> > You mean when I built it shared I did? Why is this?
> > The target libs move with the toolchain because their sysrooted into the
> > exec_path.
> > Shouldn't the shared libs for the host move with the toolchain just
> > because their in the prefix?
> > Is there a way I can fix this from the configure path?
>
> you're confusing the libs
>
> the shared libs that are part of binutils are used by the host to generate
> code for the target, they are not for use by the target at runtime
Although I did not understand that at the inception of this project, I have 
for some time. Is there something about my procedure that appears to be 
confusing them?


> > > binutils' shared libs are in host format, not target format ... so they
> > > need to be in either the RPATH or in ld.so.conf path or
> > > $LD_LIBRARY_PATH
> >
> > I need to be able to move the toolchain around and avoid a root install,
> > so a static path in a root permission folder(or anywhere else for that
> > matter) is not acceptable.
>
> ok ?  i just told you how to make it work ... make sure ld.so can find them
> at runtime and it doesnt matter where they are
But wouldn't this involve changing ld.so (or it's configuration file or 
something) every time you move the toolchain?
That's precisely what I'm trying to avoid.
I want a toolchain that I can just move anywhere, without reinstalling 
anything or modifying anything other than the cross prefix in a Makefile:
i.e. 
CROSS=$(SDKBASE)gcc-4.0.0-i486-D/bin/i486-linux-
CC=$(CROSS)gcc 

This works for toolchains generated with crosstool, and
it works on my system right now, but if I turn on shared library support in 
binutils it does not, it fails to find the BFD libs for i486-linux-ar (and 
probably other binutil programs as well)
*********************************binutils build script********************
#!/bin/sh
HOST=i686
TARGET=i486
BINVERSION=2.16.1
GCCVERSION=4.0.0
#prefix=$HOME/workspace-new/SIB2.0-SDK/gcc-$GCCVERSION-$TARGET-D/
prefix=/opt/cross/gcc-$GCCVERSION-$TARGET-D/
mkdir $prefix
cp -r sysroot $prefix/
sysroot=$prefix/sysroot/

mkdir -p binutils-$BINVERSION-obj
cd binutils-$BINVERSION-obj

../../binutils-$BINVERSION/configure \
--host=$HOST-linux \
--target=$TARGET-linux \
--with-sysroot=$sysroot \
--prefix=$prefix \
--enable-_cxz_atexit \
--with-system-zlib \
--enable-nls \
--without-included-gettext \
--enable-clocal=gnu \
--enable-shared \ #if this line is here it won't relocate without adding 
Makefile flags or modifying something
--enable-debug 

make all 
make install
*********************************************************************************

> shared libs are pretty well tested ... we've always used them in Gentoo and
> i have yet to see a bug that was caused by shared libs
It's not just shared libs, it's shared libs in conjunction with a relocatable 
toolchain which builds everything under it's prefix.
Does Gentoo do this? Can you move the toolchain without reconfiguring it?

thx,
NZG

--
For unsubscribe information see http://sourceware.org/lists.html#faq


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]