[Buildroot] [PATCH v2] monkey: new package

Thomas Petazzoni thomas.petazzoni at free-electrons.com
Wed Jul 1 07:48:25 UTC 2015


Hello,

On Wed, 1 Jul 2015 07:27:40 +0000, Julien CORJON wrote:

> You're right, with the autotool -> generic-packages rework I just 
> checked the compilation and didn't notice that x86 GCC was used. It 
> won't happen again, next time I will fully test patches after each rework.

Ah, ok, I understand. Indeed when using the autotools-package infra,
TARGET_CONFIGURE_OPTS is automatically passed in the environment of
configure. But as discussed previously, this package is not using
autoconf/automake, so it doesn't make a lot of sense to use the
autotools-package infrastructure for it.

> >      [Thomas:
> >        - Add missing dependency on !BR2_STATIC_LIBS (the source code uses
> >          dlopen) and BR2_USE_MMU (the source code uses fork)
> 
> Do you have a documentation on "BR dependencies versus functions" to 
> learn about that?

No, not really. And it's not necessarily a 1:1 mapping. For example,
usage of dlopen() is an indication that you should depend
on !BR2_STATIC_LIBS. But there are also other situations where you need
to depend on !BR2_STATIC_LIBS: when the package tries to build a shared
library unconditionally.

Seeing fork() being called is a good indication that you need a depends
on BR2_USE_MMU.

For the other dependencies like BR2_TOOLCHAIN_HAS_THREADS, you can grep
for pthread functions.

For wide-char/locales, it's a bit more complicated.

But it's not too dramatic if you don't get these correct, as the
autobuilders will catch such problems.

> >        - Slightly adjust/reword the description of the
> >          BR2_PACKAGE_MONKEY_SHARED option.
> >        - Remove all the complicated installation logic for the target, and
> >          just use "make install" instead.
> 
> I didn't know that BR remove all headers from the target image at the 
> end of the compilation. Is it the same for the man files?

Yes. Look at what the target-finalize target is doing at
http://git.buildroot.net/buildroot/tree/Makefile#n547. This is executed
at the end of the build: after all packages have been built/installed,
but before the root filesystem images are generated.

> >        - Pass --no-backtrace when uClibc is used, otherwise the build fails
> >          because <execinfo.h> is not available in uClibc.
> 
> As I daily use a linaro toolchain, I did not test the uClib and Musl 
> configure options. In this case (for future patches), should I include a 
> case I cannot test or disable it with depend?

No, we really prefer when the uClibc situation has been at least built
tested: uClibc is still our default C library, so it's a bit weird to
make a package depends on !BR2_TOOLCHAIN_USES_UCLIBC, if it really can
be used with uClibc.

Especially since your package had some specific conditionals for uClibc
and Musl handling.

But to be honest, I did not built the musl case. The autobuilders will
take care of that.

Remember that you have pre-built uClibc toolchains available at
http://autobuild.buildroot.org/toolchains/tarballs/, which allows you
do quickly build test a package with uClibc.

Here I have a script called br-init-conf, which does:

#!/bin/sh
wget -O .config http://autobuild.buildroot.org/toolchains/configs/br-arm-full.config
cat /home/thomas/projets/br/minimal.defconfig >> .config

With minimal.defconfig being:

BR2_INIT_NONE=y
BR2_SYSTEM_BIN_SH_NONE=y
# BR2_PACKAGE_BUSYBOX is not set
# BR2_TARGET_ROOTFS_TAR is not set

This allows to initialize a minimal Buildroot configuration that uses a
pre-built uClibc toolchain. Excellent to do a quick test build.

> > Also, if you could post a follow-up patch adding an init script that
> > starts Monkey at boot time, it would be great.
> 
> I notice there is an systemd start script debian/monkey.init but my 
> knowledge of init daemons is so limited that I didn't try to 
> include/modify this file in BR package declaration.

Ok, no problem.

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com



More information about the buildroot mailing list