<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 11/04/2016 03:17 PM, Arnout Vandecappelle wrote:<br>
<blockquote cite="mid:7a64a70c-f8ff-f15d-e7b0-c1c226df96bd@mind.be"
type="cite">
<blockquote type="cite">
<pre wrap="">On 11/02/2016 10:42 AM, Hollis Blanchard wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
</blockquote>
<pre wrap="">
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
defconfig:
BR2_arm=y
BR2_cortex_a8=y
BR2_ARM_EABIHF=y
BR2_ARM_FPU_VFPV3=y
BR2_HOST_DIR="/opt/buildroot-cortexa8/2.0"
BR2_KERNEL_HEADERS_3_14=y
BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_PACKAGE_HOST_GDB=y
BR2_PACKAGE_LIBFUSE=y
BR2_PACKAGE_LIBCURL=y
BR2_PACKAGE_HOST_ANDROID_TOOLS=y
# 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:
BR2_arm=y
BR2_cortex_a8=y
BR2_ARM_EABIHF=y
BR2_ARM_FPU_VFPV3=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
BR2_TOOLCHAIN_EXTERNAL_PATH="/opt/ssn-buildroot-cortexa8/2.1/usr"
BR2_TOOLCHAIN_EXTERNAL_CUSTOM_GLIBC=y
BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY=y
BR2_PACKAGE_LIBFUSE=y
BR2_PACKAGE_LIBCURL=y
BR2_PACKAGE_IPROUTE2=y
BR2_TARGET_ROOTFS_UBIFS=y
BR2_TARGET_ROOTFS_UBIFS_LEBSIZE=0x1f000
BR2_TARGET_ROOTFS_UBIFS_MAXLEBCNT=300
You have to maintain both defconfigs and you have to provide both to the users
(though they'll normally only use the second one).</pre>
</blockquote>
<br>
OK, two defconfigs isn't a problem.<br>
<br>
<br>
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.<br>
<br>
<blockquote type="cite">
<blockquote type="cite" style="color: #000000;">
<blockquote type="cite" style="color: #000000;">
<pre wrap=""> 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.
</pre>
</blockquote>
</blockquote>
<pre wrap=""> 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...</pre>
</blockquote>
<br>
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 knowledge. :-)<br>
<br>
<blockquote type="cite">
<pre wrap=""> 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.</pre>
</blockquote>
<br>
It looks like Poky (OpenEmbedded?) recipes install wrapper shell
scripts into the host directory, as seen in <a
href="https://github.com/kraj/poky/blob/master/meta/classes/utils.bbclass#L275">create_wrapper()</a>.
Then a relocation script can edit the wrappers. In the case of
mke2fs, I guess that wrapper might look like this:<br>
<blockquote>
<pre>#!/bin/bash
realpath=`readlink -fn $0`
export MKE2FS_CONFIG=@SDK_BASE_DIRECTORY@/etc/mk
exec -a `dirname $realpath`/$cmdname `dirname $realpath`/$cmdname.real "$@"
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hollis Blanchard <a class="moz-txt-link-rfc2396E" href="mailto:hollis_blanchard@mentor.com"><hollis_blanchard@mentor.com></a>
Mentor Graphics Emulation Division</pre>
</body>
</html>