[Buildroot] distributable Buildroot BSPs/SDKs
hollis_blanchard at mentor.com
Tue Nov 29 17:02:33 UTC 2016
On 11/04/2016 03:17 PM, Arnout Vandecappelle wrote:
>> 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.
> When you say SDK, I would think you mean a toolchain + some additional
> libraries that can be used to build software and images outside of Buildroot.
> It's not something that Buildroot really supports very well, but I've done it in
> a couple of projects.
> What I do is basically two configs:
> - A toolchain config that just has the toolchain, the host tools and the
> libraries you want to make available. Since this is not relocatable, specify
> BR2_HOST_DIR=/opt/... It does mean that while building this config, you
> temporarily have to make /opt/... writeable for the building user. Example
> # BR2_TARGET_ROOTFS_TAR is not set
> - A target config that uses the above toolchain as external toolchain, but
> rebuilds the target libraries. Host tools that are needed in post-build/image
> scripts don't have to be included since they can be used from the external
> toolchain. Example defconfig:
> You have to maintain both defconfigs and you have to provide both to the users
> (though they'll normally only use the second one).
OK, two defconfigs isn't a problem.
Non-relocatable is a problem though. Many (most?) of our users don't
have root permission to the shared lab systems they're using, so must
install into unusual directories.
>>> 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.
> That's tough, because the host tools that you do use may inadvertently call
> some of these binaries... E.g. if gdb is built with python support, then it will
> call the host-python executable only when a plugin is running a python script...
That means the building user needs to know the details of each tool they
build, to know what its real runtime dependencies will be. Of course, in
an ideal world, the word "user" in that statement would be replaced by
the word "recipe", which is a more appropriate location for that
> 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.
It looks like Poky (OpenEmbedded?) recipes install wrapper shell scripts
into the host directory, as seen in create_wrapper()
Then a relocation script can edit the wrappers. In the case of mke2fs, I
guess that wrapper might look like this:
realpath=`readlink -fn $0`
exec -a `dirname $realpath`/$cmdname `dirname $realpath`/$cmdname.real "$@"
Hollis Blanchard <hollis_blanchard at mentor.com>
Mentor Graphics Emulation Division
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the buildroot