From mboxrd@z Thu Jan 1 00:00:00 1970 From: Romain Naour Date: Sat, 23 Jan 2016 11:47:30 +0100 Subject: [Buildroot] Analysis of build failures In-Reply-To: <20160123093209.5f0085c5@free-electrons.com> References: <20160122073021.E35B6101A27@stock.ovh.net> <20160122102957.10f29956@free-electrons.com> <56A2B908.2000801@gmail.com> <20160123093209.5f0085c5@free-electrons.com> Message-ID: <56A35A42.6050901@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net Hi Thomas, Le 23/01/2016 09:32, Thomas Petazzoni a ?crit : > 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 ? Yes. I didn't have the issue during the EFL bump since Lua 5.1 was the default choice in Buildroot until recently. > I guess there is no way of disabling Lua support ? :-) No indeed, we have the choice between old lua and luajit. > > 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 ? I have a small series (not yet submitted) enabling luajit :) > >>>> 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 ? I didn't investigate further but it seems we remove something in the Makefile with the SED command that break the build. > >> But I gave up on the patch for upstream... > > What was the feedback ? https://sourceware.org/ml/gdb-patches/2015-09/msg00579.html I don't remember if I tried with this proposal: https://sourceware.org/ml/gdb-patches/2015-09/msg00572.html > >>> 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. Indeed... Also, we should disable gcc 4.9.x and binutils 2.25.x for niosII for the internal toolchain. I'll send a small series doing that. Best regards, Romain > > Thanks, > > Thomas >