Re: Using non-distro gcc

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Fri, 2012-02-24 at 00:01 -0800, Khem Raj wrote:
> On (23/02/12 08:31), Richard Purdie wrote:
> > On Wed, 2012-02-22 at 16:00 +0800, Chin Huat Ang wrote:
> > > My Centos 5.6’s gcc is a bit outdated and I’m seeing compiler bugs
> > > when compiling elfutils-native. As such I’ve rolled my own gcc 4.5.3
> > > with MPC/MPFR/GMP all installed to /opt, my intention is to make the
> > > new toolchain self-contained and reusable on other machines/distros.
> > >  
> > > The problem is that, in order to use this gcc I will need to set
> > > LD_LIBRARY_PATH so that it can picks up MPC/MPFR/GMP from /opt. 
> > >  
> > > Poky seems to always build with pristine environment (i.e. no
> > > LD_LIBRARY_PATH), so my new toolchain is unusable. This problem will
> > > not happen on distro gcc as MPC et al are always installed
> > > in /usr/lib.
> > >  
> > > Is there a way to tell Poky to set LD_LIBRARY_PATH whenever it uses
> > > the non-distro toolchain? Or is it the right thing to do at all?
> > 
> > You can set "export LD_LIBRARY_PATH=xxx" in your local.conf and that
> > will make bitbake always set the variable. I'm not sure you can do it
> > for just the target gcc.
> > 
> > Another alternative would be to put wrapper scripts around your
> > toolchain binaries and ensure they get found in PATH first and the
> > scripts setup the environment correctly.
> > > 
> > Its certainly possible to make this work but it might require a little
> > bit of experimentation. I'm surprised your toolchain doesn't set the
> > RPATHs of the binaries correctly to find the libs its linked to.
> 
> I think it would be safer to provide gcc-native for such cases 

Which you would compile with what?

Cheers,

Richard