[Buildroot] distributable Buildroot BSPs/SDKs

Hollis Blanchard 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
>         change.
>      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
> http://lists.busybox.net/mailman/listinfo/buildroot

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20161104/36033b82/attachment.html>

More information about the buildroot mailing list