* [Buildroot] external buildroot toolchain: LD_LIBRARY_PATH needed
@ 2011-08-24 14:17 Thomas De Schampheleire
2011-08-24 14:31 ` Grant Edwards
0 siblings, 1 reply; 6+ messages in thread
From: Thomas De Schampheleire @ 2011-08-24 14:17 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] external buildroot toolchain: LD_LIBRARY_PATH needed
2011-08-24 14:17 [Buildroot] external buildroot toolchain: LD_LIBRARY_PATH needed Thomas De Schampheleire
@ 2011-08-24 14:31 ` Grant Edwards
2011-08-25 9:07 ` Thomas De Schampheleire
0 siblings, 1 reply; 6+ messages in thread
From: Grant Edwards @ 2011-08-24 14:31 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] external buildroot toolchain: LD_LIBRARY_PATH needed
2011-08-24 14:31 ` Grant Edwards
@ 2011-08-25 9:07 ` Thomas De Schampheleire
2011-09-06 14:17 ` Thomas De Schampheleire
2011-09-06 15:24 ` Thomas Petazzoni
0 siblings, 2 replies; 6+ messages in thread
From: Thomas De Schampheleire @ 2011-08-25 9:07 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] external buildroot toolchain: LD_LIBRARY_PATH needed
2011-08-25 9:07 ` Thomas De Schampheleire
@ 2011-09-06 14:17 ` Thomas De Schampheleire
2011-09-06 15:24 ` Thomas Petazzoni
1 sibling, 0 replies; 6+ messages in thread
From: Thomas De Schampheleire @ 2011-09-06 14:17 UTC (permalink / raw)
To: buildroot
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
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] external buildroot toolchain: LD_LIBRARY_PATH needed
2011-08-25 9:07 ` Thomas De Schampheleire
2011-09-06 14:17 ` Thomas De Schampheleire
@ 2011-09-06 15:24 ` Thomas Petazzoni
2011-09-07 10:37 ` Thomas De Schampheleire
1 sibling, 1 reply; 6+ messages in thread
From: Thomas Petazzoni @ 2011-09-06 15:24 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] external buildroot toolchain: LD_LIBRARY_PATH needed
2011-09-06 15:24 ` Thomas Petazzoni
@ 2011-09-07 10:37 ` Thomas De Schampheleire
0 siblings, 0 replies; 6+ messages in thread
From: Thomas De Schampheleire @ 2011-09-07 10:37 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-09-07 10:37 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-08-24 14:17 [Buildroot] external buildroot toolchain: LD_LIBRARY_PATH needed Thomas De Schampheleire
2011-08-24 14:31 ` Grant Edwards
2011-08-25 9:07 ` Thomas De Schampheleire
2011-09-06 14:17 ` Thomas De Schampheleire
2011-09-06 15:24 ` Thomas Petazzoni
2011-09-07 10:37 ` Thomas De Schampheleire
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox