[Buildroot] Analysis of build failures
nroach44 at gmail.com
Sun Sep 7 15:34:55 UTC 2014
On 07/09/14 20:17, Thomas De Schampheleire wrote:
> On Sun, Sep 7, 2014 at 9:21 AM, Thomas Petazzoni
> <thomas.petazzoni at free-electrons.com> wrote:
>> On Sat, 06 Sep 2014 22:25:33 +0200, Peter Korsgaard wrote:
>>> > Seems like Nathaniel autobuilder does not have the ncurses development
>>> > libraries installed (also causing build failures in host-mysql, for
>>> > example). What is our policy regarding ncurses? I have it installed in
>>> > my autobuilder because I use it to run "make menuconfig". But it's true
>>> > it's not technically absolutely required to run a Buildroot build.
>>> > Should we add dependency on host-ncurses where appropriate? Or should
>>> > we make ncurses development files on the build machine a mandatory
>>> > dependency? What if the user uses only xconfig or gconfig?
>>> Given how many people use menuconfig, I think we should just make
>>> ncurses a mandatory dependency. Just about anybody doing embedded Linux
>>> development needs them anyway to configure
>>> If not, then we would also need to add host-ncurses to our
>>> barebox/linux/busybox/uclibc-menuconfig targets.
>> Well not sure we want to go down this road: it would mean we should add
>> host-qt as a dependency of the linux-xconfig target for example. We
>> could also decide that the *-menuconfig targets need to have curses-dev
>> installed on the build machine, but that the package that we build and
>> that need host-curses will depend on host-curses.
>> But well, menuconfig is indeed widely used, so maybe the easiest
>> solution would be to make ncurses-dev a mandatory dependency.
> An alternative is to use the suitable-host-package mechanism in such
> cases: if the host does have ncurses (but the same could be done for
> autoconf, automake, flex, bison, and other host packages) then build
> it inside buildroot. If it does, then just use them directly.
> Since the build of host-ncurses does take some time, it may be
> advantageous for the user to install ncurses on the host anyway, to
> avoid long build times, so a notice at the end of the build process to
> suggest that could be useful.
> Best regards,
> buildroot mailing list
> buildroot at busybox.net
Just my two cents:
For anything that requires user interaction like xconfig for menuconfig
(for buildroot or the kernel for example), use the host's libraries -
They are likely to have them installed and it will be quicker if I want
to change a config option. Also, none of the config binaries will be
copied to the target.
For any package that depends on ncurses to build, build host-ncurses -
This provides isolation against any changes between distributions and
ensures that we have control over versions.
Additionally, if the build time dependencies of BR are kept to a
minimum, it may be beneficial some situations where the user may not
have control of the building system - I doubt anyone actually uses BR in
this situation, but it's possible. I can see a situation where the user
configures BR on their laptop, and pushes the config to a more powerful
shared system to build it.
Finally, I'm not fond of the suitable-host-package approach Thomas has
mentioned: while again, I doubt the probability of such a case
happening, things like distro-specific patches or behavior may change
builds. (For example, my router firmware segfaults during build on
Ubuntu but not on Debian)
More information about the buildroot