[Buildroot] Analysis of build failures
Thomas Petazzoni
thomas.petazzoni at free-electrons.com
Sat Jan 23 08:32:09 UTC 2016
Hello,
On Sat, 23 Jan 2016 00:19:36 +0100, Romain Naour wrote:
> > Romain ? This is host-efl, maybe we need to disable Lua support or
> > something ?
>
> It's a lua 5.1 vs 5.2 and 5.3 issue.
>
> It's a complete mess because there is an uptream patch [1] that try to fixes the
> build issue, but not completely.
>
> The build fail with the following error due to compatibility mode in lua
> (LUA_COMPAT_ALL and LUA_COMPAT_5_1):
>
> lib/evas/.libs/libevas.so: undefined reference to `luaL_openlib'
> collect2: error: ld returned 1 exit status
>
> Also the patch break the build for lua 5.1...
> So, I think it's safe to add a dependency on lua 5.1 and report the problem
> upstream.
So you would make the *target* EFL package depend on lua 5.1, so that
the *host* EFL package also gets built against the host Lua 5.1 ?
I guess there is no way of disabling Lua support ? :-)
So, yes, in the mean time, please add the dependency, and report the
problem upstream. BTW, did you test the --enable-lua-old option that
is mentioned in
https://git.enlightenment.org/core/efl.git/commit/?id=6124d0733657e425001ce51f526aea3bb8dc54e7,
which you pointed ?
> >> microblazeel | host-gdb-6be65fb56ea6694a92... | NOK | http://autobuild.buildroot.net/results/d35f6ee7643a695af7db3739ff480d25b99ee051/
> >> microblazeel | host-gdb-6be65fb56ea6694a92... | NOK | http://autobuild.buildroot.net/results/09f4a89e463b6ccbca01cce1d38eb849c17ed6e1/
> >
> > The documentation issue. Romain, you looked into this a while ago, why
> > does it pop up again on Microblaze specifically ?
>
> I think this build failure is here since we SED into the Makefile to remove the
> documentation.
I don't understand. Isn't the SED precisely here to prevent the
documentation from being built ?
> But I gave up on the patch for upstream...
What was the feedback ?
> > Maybe we can switch to the mainline gdb for Microblaze ?
>
> Why not. The latest gdb version was 7.5.1 when gdb for Microblaze was added to
> Buildroot. Now we have at least 7.7.x.
I think we should try to use the mainline gdb. We have a Microblaze
Qemu configuration, so we can at least do some basic testing here.
> >
> >> nios2 | imagemagick-6.9.2-10 | NOK | http://autobuild.buildroot.net/results/0bf3a2a284b7d4712ab1530562d3b8164fc75e88/
> >
> > The usual:
> >
> > assertion fail elf32-nios2.c:1038
> >
> > This is being fixed at
> > https://sourceware.org/bugzilla/show_bug.cgi?id=19405. In the mean
> > time, we could disable on NIOS II maybe ?
>
> Yes maybe.
Can you submit a patch ?
> >> nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/183df75a853c3b0e2617c9219a356c5531aa523d/
> >
> > Will be fixed once we bump to binutils 2.26. Romain, maybe we should
> > disable libcap-ng in the mean time ?
>
> binutils 2.26 should be released in a few days, hopefully.
Ok, good.
> >> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/aa1492777c5f60ab45921618f64910ca4d048e5f/
> >> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/a74810f0fce398c41fef11b8e2b8e1a52ffdb46a/
> >> nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/cb70d195cf9b9b5ae09b83a40ef767cc8f699a9c/
> >
> > Toolchain issues. Being fixed in upstream gcc, but we should disable
> > with external NIOS2 toolchain anyway.
> >
> > Romain ?
>
> This patch should be fine:
> http://patchwork.ozlabs.org/patch/561414/
Thanks. The only thing that bothers me a bit is that we will likely
forget to remove all those "depends on BR2_nios2". But I guess we don't
really have the choice.
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
More information about the buildroot
mailing list