Using non-distro gcc

Using non-distro gcc

[Chin Huat Ang]

[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]

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?

________________________________
Confidentiality Notice.
This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution, or copying of this message, or any attachments, is strictly prohibited. If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments. Thank you.

[-- Attachment #2: Type: text/html, Size: 5773 bytes --]

Re: Using non-distro gcc

[Richard Purdie]

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.

Cheers,

Richard

Re: Using non-distro gcc

[Khem Raj]

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 

Re: Using non-distro gcc

[Richard Purdie]

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

Re: Using non-distro gcc

[Chin Huat Ang]

Richard,

I think you're right about the toolchain wasn't compiled with -Wl,-rpath, as revealed by "chrpath -l".

Setting LD_LIBRARY_PATH in order to use a toolchain essentially means it's broken.

(and apologies for non-poky/oe specific questions)

--Chin Huat

-----Original Message-----
From: Richard Purdie [mailto:richard.purdie@linuxfoundation.org]
Sent: Friday, February 24, 2012 6:19 PM
To: Khem Raj
Cc: Chin Huat Ang; 'poky@yoctoproject.org'
Subject: Re: [poky] Using non-distro gcc

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




Confidentiality Notice.
This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution,  or copying  of this message, or any attachments, is strictly prohibited.  If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments.  Thank you.

Re: Using non-distro gcc

[Khem Raj]

On Fri, Feb 24, 2012 at 2:19 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> 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?

its native you can bootstrap it.

>
> Cheers,
>
> Richard
>
>