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