[Buildroot] distributable Buildroot BSPs/SDKs
hollis_blanchard at mentor.com
Fri Nov 4 15:36:13 UTC 2016
Can I force the host tools to be built static? That would avoid the
rpath and the "recursively copy library dependencies by hand" problems.
Hollis Blanchard <hollis_blanchard at mentor.com>
Mentor Graphics Emulation Division
On 11/02/2016 10:42 AM, Hollis Blanchard wrote:
> Can anybody point me to an example of a prebuilt Buildroot-generated
> SDK/BSP distributed in the wild? I'm looking for something that
> includes binaries for host executables so I can see how they did it.
> My users primarily care about target code. I want to both provide
> prebuilt target binaries and let my users patch/rebuild them. That
> part seems to be pretty clear; I can 'make && cp output/images/*
> prebuilt/', and also provide the defconfig.
> However, I also want to provide a few host executables, and that's
> raising a lot of questions for me:
> 1. The fact that host binaries are non-relocatable (can only be run
> where they were built) seems to be well-known. For now I'm content
> to manually run "output/host/usr/bin/patchelf --set-rpath
> '$ORIGIN/../lib'" in a post-processing step...
> 2. I really only want to distribute a couple key host binaries, like
> adb and dtc. However, since these depend on other host packages,
> output/host/usr/bin ends up full of other binaries from gettext,
> autoconf/automake/etc, flex, etc. That's dead weight as far as I'm
> concerned; it takes up space, and encourages people to actually
> use them, but I don't want to support them.
> 3. That suggests I should manually extract the things I care about
> from inside output/host, just like I did with the "prebuilt"
> directory I mentioned above for target code.
> 1. Simplest would be to symlink, but then a "make clean" will
> suddenly make the host tools disappear, which would be unexpected.
> 2. So I should copy them out, again like the "prebuilt"
> directory. But then I'd also need to copy out the
> output/host/usr/lib files they depend on (and the libs the
> libs depend on...). I could write a readelf-based script to
> find the dependencies and copy them, but that's starting to
> sound complicated. If only I had a tool that could build me an
> SDK... ;-)
> 3. Host tools are built with options like these:
> --sysconfdir=/absolute/path/to/output/host/etc (so they can
> find output/host/etc/mke2fs.conf, for example). Huh. Readelf
> won't help me find those dependencies, and no rpath will help
> me relocate that. I'm not even sure what directory structure I
> would want for those files in an ideal BSP.
> 4. The likelihood that my users will need to rebuild host tools is
> slim, and they take a long time to rebuild, since they pull in
> dependencies like host-autoconf, host-flex, and even host-python.
> Again, unnecessary overhead. So should the defconfig I distribute
> include BR2_PACKAGE_HOST_*?
> 1. Yes: but then users typing "make" will spend lots of time
> rebuilding host executables that they're extremely unlikely to
> 2. No: OK, I can treat the host tools completely separately, and
> nobody even needs to know they came from Buildroot. But then I
> need to maintain two defconfigs, one that builds target code
> and one that builds host code.
> So anyways, that's why I'm looking for examples of how others have
> dealt with these problems.
> I'd appreciate thoughts on any of these points, even if no one person
> has The Answers to all of them. Thanks!
> Hollis Blanchard<hollis_blanchard at mentor.com>
> Mentor Graphics Emulation Division
> buildroot mailing list
> buildroot at busybox.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the buildroot