[Buildroot] [PATCH 2/9] toolchain-external: allow specifying extra external libraries
Thomas De Schampheleire
patrickdepinguin+buildroot at gmail.com
Wed Oct 5 06:20:15 UTC 2011
On Tue, Oct 4, 2011 at 11:36 PM, Yann E. MORIN
<yann.morin.1998 at anciens.enib.fr> wrote:
> Thomas², All,
> On Monday 03 October 2011 09:21:59 Thomas De Schampheleire wrote:
>> On Sun, Oct 2, 2011 at 11:45 PM, Yann E. MORIN
>> <yann.morin.1998 at anciens.enib.fr> wrote:
>> > On Sunday 02 October 2011 21:20:10 Thomas Petazzoni wrote:
>> >> From: Thomas De Schampheleire <patrickdepinguin+buildroot at gmail.com>
>> >> Custom toolchains may provide extra libraries that need to be copied to the
>> >> target. This patch adds a configuration option for this.
>> > What kind of libraries are we talking about here? Things such as libz.so,
>> > or like libnss_*.so ?
>> > So, I'm not really sure we should allow that without further explanations.
>> > (and there was no more in Thomas' original post on the suject...)
>> uClibc supports the 'backtrace' functionality. I'm not sure whether it
>> already is in 0.9.32,
> Yes, it is.
>> but it certainly is in the repository. When you
>> enable the functionality in the uClibc configuration, a library
>> libubacktrace.so is generated. Application code that uses the
>> backtrace() or backtrace_symbols() functions, need to link with this
>> library and thus it needs to be copied from the toolchain.
> If an application is linked against libubactrace, then it should have a
> NEEDED entry for it, no? Or is it dlopen-ed on-demand?
I can confirm that there is an appropriate NEEDED entry in the application.
> That's what I find odd with how buildroot populates the rootfs. It has
> a somewhat-hard-coded list of libraries to copy. That list is lamost
> unconditionally constructed.
> The proper way to handle this would be to scan all the executables aferward,
> looking at the DT_NEEDED flag in the ELF header, and copying the missing
> Of course, this is tricky, because of the way buildroot handles the sysroot.
> Every time the compiler is called, the sysroot is overloaded to point to the
> staging area. This totaly highjacks the purpose of the sysroot.
> In that case, there is no need to pre-populate the rootfs with the libraries
> from the sysroot, it should be done only at the end.
Note that this step would need to be done at each 'make' execution, to
cater for external applications that were copied to the rootfs
manually (which is precisely my case).
> For example., that's what the 'populate' script in crosstool-NG is for:
> create a copy of the rootfs, and scan the sysroot for missing libraries.
>> The appropriate header is located next to the other toolchain headers,
>> which are already copied by default:
> Yes, because it is a system library, so it is copied as part of the initial
> staging filling.
>> Depending on the uClibc configuration, less or more libraries may need
>> to be copied. I can imagine that a similar thing is needed for other C
>> libraries. Hence this generic option I added.
>> Given this background information, how do you feel about this patch?
> Sadly, this has to go in for now. I'll be creating a new thread with an
> alternate proposal, but it will require a bit more work, so I'll Ack
> this for now.
Ok. Thanks for your ack.
> Currently, this hack applies only to custom external toolchain, because
> none of the "automatic" external toolchain currently bundles uClibc-0.9.32.
I think this would be stated more correctly as:
"... because none of the automatic external toolchains currently add
libraries that are not present in the explicit LIB_EXTERNAL_LIB /
More information about the buildroot