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: Failure to boot into cross built environment (iWMMXt NPTL EABI)


--- Mike Frysinger <vapier@gentoo.org> wrote:

> On Sunday 23 April 2006 20:08, Steven Newbury wrote:
> > Since I've got
> > you attention I'd like to ask a question about the gcc ebuild; when a
> > cross-<target>/gcc is installed the gcc library path gets added via LDPATH
> > to the env.d -> ld.so.conf, this puts incompatible libraries in the library
> > search path which causes dynamic linking to then fail for native programs
> > that find the alien library before the native one they seek. I assume this 
> > is not intended!  I made the LDPATH addition conditional on is_crosscompile
> > and CHOST != CTARGET, is that OK?
> 
> gcc-config already handles this by not inserting stuff into ld.so.conf when 
> selecting a cross-compiler ... so having LDPATH declared 
> in /etc/env.d/gcc/CTARGET-VERSION isnt a bug

Or rather that isn't where the bug is/was! I was getting non-native paths in
ld.so.conf.  Hmm.

> 
> > Another thing that's come up is when cross-emerging (with
> > ROOT=<target-root> CHOST=<target> CBUILD=<build> etc), CBUILD is being
> > overridden by CHOST somewhere in the emerge process.  I had to hack a bit
> > to get it working, do you know what might be causing that?
> 
> this has never happened to me ... CBUILD is only set to CHOST when CBUILD
> isnt 
> already set ...

I think this must have fixed itself with an update, it seems to be ok now and
the changes went with the update.

> 
> > +               arm)
> > +                       [[ ${CTARGET} == *-iwmmxt-*eabi ]] && append-flags
> > "-march=iwmmxt -mcpu=iwmmxt -mabi=aapcs" +               ;;
> 
> such overrides shouldnt really be in the ebuild ... you should set your
> CFLAGS 
> before emerging the cross-glibc into ROOT

Yes, this is very true, though I did for a reason.  I use the ebuild for
building the cross-compiler as well as the native compiler and it seemed the
only way to get the CFLAGS respected by the build process.  I've only been
learning Gentoo as I've been going along, and it seemed like a good idea at the
time...  Since I've been cross-emerging things into ROOT I've been doing things
a little differently.  With gcc I patched in a support for a
arm-iwmmxt-linux-gnueabi target which sets appropriate defaults, flags, specs
etc.

> > + echo $ECHO_N "checking version of $AS... $ECHO_C" >&6
> > +-  ac_prog_version=`$AS --version 2>&1 | sed -n 's/^.*GNU assembler.*
> > \([0-9]*\.[0-9.]*\).*$/\1/p'` ++  ac_prog_version=`$AS --version 2>&1 | sed
> > 's/ 06..../ 2\.16\.99\.9/g' | sed -n 's/^.*GNU assembler.*
> > \([0-9]*\.[0-9.]*\).*$/\1/p'` +   case $ac_prog_version in
> 
> i guess you need these as/ld changes because you're using a cvs snapshot of 
> binutils ?  binutils-2.16.91+ should be OK for arm EABI; 2.16.92 for sure 
> (which is in portage)
Yes, 2.16.92 might well do it. It's taken me so long to get all this working
the world has moved on without me! I'm pretty sure it wasn't there when I
started...
> -mike
> 


Steve

Send instant messages to your online friends http://uk.messenger.yahoo.com 

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