[Buildroot] external buildroot toolchain: LD_LIBRARY_PATH needed

[Buildroot] external buildroot toolchain: LD_LIBRARY_PATH needed

[Thomas De Schampheleire]

Hi,

If I build a buildroot toolchain on machine A, package the
output/host/usr directory and use that as an external toolchain on
machine B, I get errors that cc1 cannot find libmpfr.so.4.
The location of that library is hardcoded in some compiler tools, and
since we are on another machine, the original location does not exist.

I can work around this by specifying
LD_LIBRARY_PATH=<buildroot>/output/host/opt/ext-toolchain/lib in the
environment, but this is an annoying and not so clean solution.

How is this supposed to work?
How do other external toolchains handle this?

Thanks,
Thomas

[Buildroot] external buildroot toolchain: LD_LIBRARY_PATH needed

[Grant Edwards]

On 2011-08-24, Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> wrote:

> If I build a buildroot toolchain on machine A, package the
> output/host/usr directory and use that as an external toolchain on
> machine B, I get errors that cc1 cannot find libmpfr.so.4. The
> location of that library is hardcoded in some compiler tools, and
> since we are on another machine, the original location does not
> exist.
>
> I can work around this by specifying
> LD_LIBRARY_PATH=<buildroot>/output/host/opt/ext-toolchain/lib in the
> environment, but this is an annoying and not so clean solution.
>
> How is this supposed to work?

Generally, when you run a gcc from somewhere othern than the location
for which it was originally compled you use the --sysroot option on
the compiler command line to tell it where it's now installed.

I don't know if the buildroot toolchain has that enabled or not.  I
had a lot of problems trying to use a buildroot-generated toolchain as
an external toolchain (this was a year or two back) and switched to
using crosstool-ng to build my toolchains.

-- 
Grant Edwards               grant.b.edwards        Yow! I wonder if there's
                                  at               anything GOOD on tonight?
                              gmail.com            

[Buildroot] external buildroot toolchain: LD_LIBRARY_PATH needed

[Thomas De Schampheleire]

On Wed, Aug 24, 2011 at 4:31 PM, Grant Edwards
<grant.b.edwards@gmail.com> wrote:
> On 2011-08-24, Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> wrote:
>
>> If I build a buildroot toolchain on machine A, package the
>> output/host/usr directory and use that as an external toolchain on
>> machine B, I get errors that cc1 cannot find libmpfr.so.4. The
>> location of that library is hardcoded in some compiler tools, and
>> since we are on another machine, the original location does not
>> exist.
>>
>> I can work around this by specifying
>> LD_LIBRARY_PATH=<buildroot>/output/host/opt/ext-toolchain/lib in the
>> environment, but this is an annoying and not so clean solution.
>>
>> How is this supposed to work?
>
> Generally, when you run a gcc from somewhere othern than the location
> for which it was originally compled you use the --sysroot option on
> the compiler command line to tell it where it's now installed.
>
> I don't know if the buildroot toolchain has that enabled or not. ?I
> had a lot of problems trying to use a buildroot-generated toolchain as
> an external toolchain (this was a year or two back) and switched to
> using crosstool-ng to build my toolchains.

The buildroot external-toolchain support uses a 'wrapper' command,
that makes sure that --sysroot, --mtune and the like gets passed to
the compiler.

The sysroot originally is at
output/host/opt/ext-toolchain/powerpc-unknown-linux-uclibc/sysroot
and gets copied to:
/repo/tdescham/buildroot/output/host/usr/powerpc-unknown-linux-uclibc/sysroot

However, the missing library does not seem part of sysroot. It is located at
output/host/opt/ext-toolchain/lib
where libgmp, libmpfr, libexpat etc. reside.

Maybe this wrapper should be adapted as to include the proper LD_LIBRARY_PATH?


How does crosstool-ng handle this fixed-path problem?

Thomas

[Buildroot] external buildroot toolchain: LD_LIBRARY_PATH needed

[Thomas De Schampheleire]

Thomas, Yann, Peter?
Any ideas?

On Thu, Aug 25, 2011 at 11:07 AM, Thomas De Schampheleire
<patrickdepinguin+buildroot@gmail.com> wrote:
> On Wed, Aug 24, 2011 at 4:31 PM, Grant Edwards
> <grant.b.edwards@gmail.com> wrote:
>> On 2011-08-24, Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> wrote:
>>
>>> If I build a buildroot toolchain on machine A, package the
>>> output/host/usr directory and use that as an external toolchain on
>>> machine B, I get errors that cc1 cannot find libmpfr.so.4. The
>>> location of that library is hardcoded in some compiler tools, and
>>> since we are on another machine, the original location does not
>>> exist.
>>>
>>> I can work around this by specifying
>>> LD_LIBRARY_PATH=<buildroot>/output/host/opt/ext-toolchain/lib in the
>>> environment, but this is an annoying and not so clean solution.
>>>
>>> How is this supposed to work?
>>
>> Generally, when you run a gcc from somewhere othern than the location
>> for which it was originally compled you use the --sysroot option on
>> the compiler command line to tell it where it's now installed.
>>
>> I don't know if the buildroot toolchain has that enabled or not. ?I
>> had a lot of problems trying to use a buildroot-generated toolchain as
>> an external toolchain (this was a year or two back) and switched to
>> using crosstool-ng to build my toolchains.
>
> The buildroot external-toolchain support uses a 'wrapper' command,
> that makes sure that --sysroot, --mtune and the like gets passed to
> the compiler.
>
> The sysroot originally is at
> output/host/opt/ext-toolchain/powerpc-unknown-linux-uclibc/sysroot
> and gets copied to:
> /repo/tdescham/buildroot/output/host/usr/powerpc-unknown-linux-uclibc/sysroot
>
> However, the missing library does not seem part of sysroot. It is located at
> output/host/opt/ext-toolchain/lib
> where libgmp, libmpfr, libexpat etc. reside.
>
> Maybe this wrapper should be adapted as to include the proper LD_LIBRARY_PATH?
>
>
> How does crosstool-ng handle this fixed-path problem?
>
> Thomas
>

[Buildroot] external buildroot toolchain: LD_LIBRARY_PATH needed

[Thomas Petazzoni]

Hello,

Le Thu, 25 Aug 2011 11:07:31 +0200,
Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> a ?crit :

> However, the missing library does not seem part of sysroot. It is
> located at output/host/opt/ext-toolchain/lib
> where libgmp, libmpfr, libexpat etc. reside.

Those libraries are libraries for the host, and they are used by gcc
and binutils.

> Maybe this wrapper should be adapted as to include the proper
> LD_LIBRARY_PATH?

No, I don't think it's the right solution. I think there are two
solutions:

 * Link the toolchain binaries statically against those libraries so
   that the toolchain binaries only rely on the C libraries but not on
   gmp, mpfr, etc.

 * Link the toolchain binaries with a proper rpath.

> How does crosstool-ng handle this fixed-path problem?

From what I can see, using static linking against those libraries.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] external buildroot toolchain: LD_LIBRARY_PATH needed

[Thomas De Schampheleire]

Hi Thomas,

On Tue, Sep 6, 2011 at 5:24 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> Le Thu, 25 Aug 2011 11:07:31 +0200,
> Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> a ?crit :
>
>> However, the missing library does not seem part of sysroot. It is
>> located at output/host/opt/ext-toolchain/lib
>> where libgmp, libmpfr, libexpat etc. reside.
>
> Those libraries are libraries for the host, and they are used by gcc
> and binutils.
>
>> Maybe this wrapper should be adapted as to include the proper
>> LD_LIBRARY_PATH?
>
> No, I don't think it's the right solution. I think there are two
> solutions:
>
> ?* Link the toolchain binaries statically against those libraries so
> ? that the toolchain binaries only rely on the C libraries but not on
> ? gmp, mpfr, etc.
>
> ?* Link the toolchain binaries with a proper rpath.

When using the rpath solution, we should of course make sure that
these paths are relative to the executable (as it may move). According
to the following link, $ORIGIN can be used for that purpose:
http://groups.google.com/group/gnu.gcc.help/browse_thread/thread/1b713af28905247b?pli=1

I couldn't say which one is better.

How will we handle this? I'm willing to test any possible solution,
but to be honest I have little experience with creating toolchains so
I doubt that I can provide patches for this.

>
>> How does crosstool-ng handle this fixed-path problem?
>
> From what I can see, using static linking against those libraries.
>

Thanks,
Thomas