* [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-13
@ 2014-02-14 7:30 Thomas Petazzoni
2014-02-14 9:12 ` [Buildroot] Analysis of build failures Thomas Petazzoni
0 siblings, 1 reply; 27+ messages in thread
From: Thomas Petazzoni @ 2014-02-14 7:30 UTC (permalink / raw)
To: buildroot
Build statistics for 2014-02-13
===============================
success : 94
failures : 31
timeouts : 3
TOTAL : 128
Classification of failures by reason
====================================
thrift-0.9.1 | 3
unknown | 3
imagemagick-6.8.8-4 | 2
mmc-utils-11f2ceabc4ad3f0dd... | 2
cairo-1.12.10 | 2
pixman-0.30.0 | 2
libnetfilter_queue-1.0.2 | 1
toolchain-external-undefined | 1
popt-1.16 | 1
samba-3.6.22 | 1
w_scan-20130331 | 1
qt5base-5.2.0 | 1
udev-182 | 1
tstools-1_11 | 1
crda-1.1.3 | 1
libxml2-2.9.1 | 1
tvheadend-c7d0335eb10d02b78... | 1
python-2.7.3 | 1
dropwatch-1.4 | 1
ltp-testsuite-20130904 | 1
vlc-2.1.2 | 1
e2fsprogs-1.42.9 | 1
kmod-16 | 1
host-libeet-1.7.7 | 1
host-libxslt-1.1.28 | 1
gst1-libav-1.2.2 | 1
Detail of failures
===================
bfin | cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/899395ce00ba54f19fd1f8ebaf1ea7a15e3d98dc/
bfin | cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/0fcb07e9efbef5881c986199e2c1358d7fd9cffa/
nios2 | crda-1.1.3 | NOK | http://autobuild.buildroot.net/results/780c3388e408ae6479e824711b1c02fdbd34bef4/
microblaze | dropwatch-1.4 | NOK | http://autobuild.buildroot.net/results/916eec6a8853c49eab5b7806edcc0add06b8168f/
nios2 | e2fsprogs-1.42.9 | NOK | http://autobuild.buildroot.net/results/70a47bd7392560cbc1c64769c8357c0b4c91ca3b/
x86_64 | gst1-libav-1.2.2 | NOK | http://autobuild.buildroot.net/results/2d83f38b4a6cb2a1a47c78306da7773270ce698e/
powerpc | host-libeet-1.7.7 | NOK | http://autobuild.buildroot.net/results/e3581e4a17e2c577458f5481b391f548b7fcdf69/
i686 | host-libxslt-1.1.28 | NOK | http://autobuild.buildroot.net/results/784b3989fab4007d6d077fba9a9078cf337ce002/
i686 | imagemagick-6.8.8-4 | NOK | http://autobuild.buildroot.net/results/a9d35975c7699515350eb307712cd69b6d48e418/
arc | imagemagick-6.8.8-4 | NOK | http://autobuild.buildroot.net/results/97ec0c366c24bd03fe4c26851e8729a4d8eaf4d0/
xtensa | kmod-16 | NOK | http://autobuild.buildroot.net/results/ba205bcbb6898bee78f610883f3837930eda262c/
nios2 | libnetfilter_queue-1.0.2 | NOK | http://autobuild.buildroot.net/results/3d77c91847a099b2498030505b91f3f84c81df18/
arc | libxml2-2.9.1 | NOK | http://autobuild.buildroot.net/results/4abdea83c6915aa02b6dc55c9a9dd964ba70ac4b/
mips64el | ltp-testsuite-20130904 | NOK | http://autobuild.buildroot.net/results/f6aa04e2b904b1aae3b68b2ffbb1b8edb6f4929a/
powerpc | mmc-utils-11f2ceabc4ad3f0dd... | NOK | http://autobuild.buildroot.net/results/79e24d5ada564e664f32041cc71a1aeac0d9d5cd/
powerpc | mmc-utils-11f2ceabc4ad3f0dd... | NOK | http://autobuild.buildroot.net/results/b23f295008a834bbb37b6ea5c99842409b652bc9/
microblaze | pixman-0.30.0 | NOK | http://autobuild.buildroot.net/results/3becd76e2a7c3cf843d43ea9f1713fd536888cd7/
microblaze | pixman-0.30.0 | NOK | http://autobuild.buildroot.net/results/2b1feb18dc415c69aae6de9d558e527faae7b246/
bfin | popt-1.16 | NOK | http://autobuild.buildroot.net/results/8d3ee14585f54c6946b449854df9f06ea7746e8e/
powerpc | python-2.7.3 | NOK | http://autobuild.buildroot.net/results/64ed5890d4d03399eb549cba4aa3e65afd3b005f/
xtensa | qt5base-5.2.0 | NOK | http://autobuild.buildroot.net/results/70b77e7a5b292e3fcbcf8cab4651c48220f2bd17/
nios2 | samba-3.6.22 | NOK | http://autobuild.buildroot.net/results/bc674e494c24155800583dde5dfda0709709becb/
x86_64 | thrift-0.9.1 | NOK | http://autobuild.buildroot.net/results/eb6317433b89d3ad2a70b39a186ee223bc3f4a41/
x86_64 | thrift-0.9.1 | NOK | http://autobuild.buildroot.net/results/d439787cb8b3ee3e001dfd24e93351201a1387ce/
x86_64 | thrift-0.9.1 | NOK | http://autobuild.buildroot.net/results/c397677e2332c9a39950ea840333fc05d04c2e68/
powerpc | toolchain-external-undefined | NOK | http://autobuild.buildroot.net/results/a659d7ede91bb13904c360fe8c8f316b7011918b/
powerpc | tstools-1_11 | NOK | http://autobuild.buildroot.net/results/b92b707ec32bf6f9a0c5834fd68d81d76d1a6365/
arm | tvheadend-c7d0335eb10d02b78... | NOK | http://autobuild.buildroot.net/results/4df8cd85e0287910567df81c0394b2914570e98a/
bfin | udev-182 | NOK | http://autobuild.buildroot.net/results/386be48be71ede6e06ea5547e37a1b6448f5fba2/
sh4a | unknown | TIM | http://autobuild.buildroot.net/results/52bc9c4c2dfc0bd37f7170b98a2201ed853bad74/
sh4a | unknown | TIM | http://autobuild.buildroot.net/results/899155257298dbc85c1681f900ddd042ead98412/
sh4a | unknown | TIM | http://autobuild.buildroot.net/results/b908769c1291da8f758a44b04d36dbc415400b39/
x86_64 | vlc-2.1.2 | NOK | http://autobuild.buildroot.net/results/a53ea017ec92150c7d37c0da0ca9a8dac75f460e/
powerpc | w_scan-20130331 | NOK | http://autobuild.buildroot.net/results/6e7c691099a8f3eef4fc84860ceb1a94f25873eb/
--
http://autobuild.buildroot.net
^ permalink raw reply [flat|nested] 27+ messages in thread* [Buildroot] Analysis of build failures 2014-02-14 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-13 Thomas Petazzoni @ 2014-02-14 9:12 ` Thomas Petazzoni 2014-02-14 10:23 ` Anton Kolesov ` (4 more replies) 0 siblings, 5 replies; 27+ messages in thread From: Thomas Petazzoni @ 2014-02-14 9:12 UTC (permalink / raw) To: buildroot Hello, Aaron, Ezequiel, Spenser, Anton, Baruch and Gustavo, there are questions for you below. Please read on ! :-) On Fri, 14 Feb 2014 08:30:08 +0100 (CET), Thomas Petazzoni wrote: > bfin | cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/899395ce00ba54f19fd1f8ebaf1ea7a15e3d98dc/ > bfin | cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/0fcb07e9efbef5881c986199e2c1358d7fd9cffa/ cairo-test-runner.c: In function 'is_running_under_debugger': cairo-test-runner.c:168: error: implicit declaration of function 'getppid' cairo-test-runner.c:168: warning: nested extern declaration of 'getppid' cairo-test-runner.c:169: error: implicit declaration of function 'readlink' cairo-test-runner.c:169: warning: nested extern declaration of 'readlink' This problem has been here for a while. Aaron, as the Blackfin person, can you have a look into this and sent a patch to fix the problem? Thanks! > nios2 | crda-1.1.3 | NOK | http://autobuild.buildroot.net/results/780c3388e408ae6479e824711b1c02fdbd34bef4/ No idea what this error means. Ezequiel ? /home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.7.3/../../../../nios2-linux-gnu/bin/ld: /home/test/test/2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/lib/crt1.o: undefined reference to symbol '_gp' /home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.7.3/../../../../nios2-linux-gnu/bin/ld: note: '_gp' is defined in DSO /home/test/test/2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/lib/libgpg-error.so.0 so try adding it to the linker command line > microblaze | dropwatch-1.4 | NOK | http://autobuild.buildroot.net/results/916eec6a8853c49eab5b7806edcc0add06b8168f/ Spenser, can you have a look at this one? /home/test/test/2/output/host/usr/bin/microblaze-buildroot-linux-gnu-gcc -g -o dropwatch main.o lookup.o lookup_bfd.o lookup_kas.o -lbfd -liberty -lreadline -lnl-3 -lnl-genl-3 -lpthread -lncurses -lm /home/test/test/2/output/host/usr/lib/gcc/microblaze-buildroot-linux-gnu/4.9.0/../../../../microblaze-buildroot-linux-gnu/bin/ld: cannot find -liberty > nios2 | e2fsprogs-1.42.9 | NOK | http://autobuild.buildroot.net/results/70a47bd7392560cbc1c64769c8357c0b4c91ca3b/ Another missing syscall on NIOS II ? Ezequiel ? ../lib/libext2fs.so: undefined reference to `fallocate64' collect2: error: ld returned 1 exit status > x86_64 | gst1-libav-1.2.2 | NOK | http://autobuild.buildroot.net/results/2d83f38b4a6cb2a1a47c78306da7773270ce698e/ Weird: /home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-unknown-linux-uclibc/4.6.3/../../../../x86_64-unknown-linux-uclibc/bin/ld: ../../gst-libs/ext/libav/libavcodec/libavcodec.a(lpc.o): relocation R_X86_64_PC32 against symbol `ff_pd_1' can not be used when making a shared object; recompile with -fPIC But the build is not a static library build. > powerpc | host-libeet-1.7.7 | NOK | http://autobuild.buildroot.net/results/e3581e4a17e2c577458f5481b391f548b7fcdf69/ Spurious failure, the build machine was too heavily loaded. > i686 | host-libxslt-1.1.28 | NOK | http://autobuild.buildroot.net/results/784b3989fab4007d6d077fba9a9078cf337ce002/ CCLD testThreads /home/peko/scratch/host/usr/lib/libxml2.so: undefined reference to `lzma_code at XZ_5.0' /home/peko/scratch/host/usr/lib/libxml2.so: undefined reference to `lzma_auto_decoder at XZ_5.0' /home/peko/scratch/host/usr/lib/libxml2.so: undefined reference to `lzma_end at XZ_5.0' /home/peko/scratch/host/usr/lib/libxml2.so: undefined reference to `lzma_properties_decode at XZ_5.0' collect2: error: ld returned 1 exit status I find it rather weird that this doesn't happen more often... > i686 | imagemagick-6.8.8-4 | NOK | http://autobuild.buildroot.net/results/a9d35975c7699515350eb307712cd69b6d48e418/ Not enough backlog to see what the error is, unfortunately. > arc | imagemagick-6.8.8-4 | NOK | http://autobuild.buildroot.net/results/97ec0c366c24bd03fe4c26851e8729a4d8eaf4d0/ Internal compiler error. Anton, would you mind checking if your recent bump of the ARC toolchain components solves this compiler problem? > xtensa | kmod-16 | NOK | http://autobuild.buildroot.net/results/ba205bcbb6898bee78f610883f3837930eda262c/ Binutils internal error. Baruch ? > nios2 | libnetfilter_queue-1.0.2 | NOK | http://autobuild.buildroot.net/results/3d77c91847a099b2498030505b91f3f84c81df18/ Issue with kernel headers ? /home/test/test/1/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/include/libnfnetlink/linux_nfnetlink.h:6:6: error: nested redefinition of 'enum nfnetlink_groups' /home/test/test/1/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/include/libnfnetlink/linux_nfnetlink.h:6:6: error: redeclaration of 'enum nfnetlink_groups' > arc | libxml2-2.9.1 | NOK | http://autobuild.buildroot.net/results/4abdea83c6915aa02b6dc55c9a9dd964ba70ac4b/ Another internal compiler error. Anton, same thing, is that fixed by your recent bump? > mips64el | ltp-testsuite-20130904 | NOK | http://autobuild.buildroot.net/results/f6aa04e2b904b1aae3b68b2ffbb1b8edb6f4929a/ This one is fixed by http://git.buildroot.net/buildroot/commit/?h=next&id=898e54bd783280ee1ffb6aeeb523c9fb8c31641a, but unfortunately Peter only merged it in the next branch, so we still have the build problem on master. > powerpc | mmc-utils-11f2ceabc4ad3f0dd... | NOK | http://autobuild.buildroot.net/results/79e24d5ada564e664f32041cc71a1aeac0d9d5cd/ > powerpc | mmc-utils-11f2ceabc4ad3f0dd... | NOK | http://autobuild.buildroot.net/results/b23f295008a834bbb37b6ea5c99842409b652bc9/ Too old kernel headers; > microblaze | pixman-0.30.0 | NOK | http://autobuild.buildroot.net/results/3becd76e2a7c3cf843d43ea9f1713fd536888cd7/ > microblaze | pixman-0.30.0 | NOK | http://autobuild.buildroot.net/results/2b1feb18dc415c69aae6de9d558e527faae7b246/ utils.c:779:21: error: 'FE_DIVBYZERO' undeclared (first use in this function) feenableexcept (FE_DIVBYZERO); Spenser ? :-) > bfin | popt-1.16 | NOK | http://autobuild.buildroot.net/results/8d3ee14585f54c6946b449854df9f06ea7746e8e/ Maybe the blackfin uClibc lacks _glob_pattern_p ? Aaron ? ./.libs/libpopt.so: undefined reference to `_glob_pattern_p' > powerpc | python-2.7.3 | NOK | http://autobuild.buildroot.net/results/64ed5890d4d03399eb549cba4aa3e65afd3b005f/ ./Modules/posixmodule.c: In function '_pystat_fromstructstat': ./Modules/posixmodule.c:1356:22: error: 'struct stat' has no member named 'st_birthtime' Weird: it wants to use st_birthtime, even though this field doesn't exist under Linux, and Python has a configure test that checks whether it exists or not, and the code is properly conditionally compiled. > xtensa | qt5base-5.2.0 | NOK | http://autobuild.buildroot.net/results/70b77e7a5b292e3fcbcf8cab4651c48220f2bd17/ Needs NPTL. Fixed by my series about NPTL support. > nios2 | samba-3.6.22 | NOK | http://autobuild.buildroot.net/results/bc674e494c24155800583dde5dfda0709709becb/ Wooo, lots of errors. Relocation truncated to fit (maybe the binary is too large), and missing fallocate64. > x86_64 | thrift-0.9.1 | NOK | http://autobuild.buildroot.net/results/eb6317433b89d3ad2a70b39a186ee223bc3f4a41/ > x86_64 | thrift-0.9.1 | NOK | http://autobuild.buildroot.net/results/d439787cb8b3ee3e001dfd24e93351201a1387ce/ > x86_64 | thrift-0.9.1 | NOK | http://autobuild.buildroot.net/results/c397677e2332c9a39950ea840333fc05d04c2e68/ uint64_t type problem. Gustavo, can you have a look? > powerpc | toolchain-external-undefined | NOK | http://autobuild.buildroot.net/results/a659d7ede91bb13904c360fe8c8f316b7011918b/ Something for me to look at, it seems. > powerpc | tstools-1_11 | NOK | http://autobuild.buildroot.net/results/b92b707ec32bf6f9a0c5834fd68d81d76d1a6365/ Weird messages: Assembler messages: Fatal error: can't create obj/esfilter.o: No such file or directory Parallel build issue? > arm | tvheadend-c7d0335eb10d02b78... | NOK | http://autobuild.buildroot.net/results/4df8cd85e0287910567df81c0394b2914570e98a/ src/input/mpegts/dvb_support.c:415:25: error: 'SYS_TURBO' undeclared here (not in a function) { "TURBO", SYS_TURBO } Too old kernel headers. > bfin | udev-182 | NOK | http://autobuild.buildroot.net/results/386be48be71ede6e06ea5547e37a1b6448f5fba2/ udev needs fork(). > sh4a | unknown | TIM | http://autobuild.buildroot.net/results/52bc9c4c2dfc0bd37f7170b98a2201ed853bad74/ > sh4a | unknown | TIM | http://autobuild.buildroot.net/results/899155257298dbc85c1681f900ddd042ead98412/ > sh4a | unknown | TIM | http://autobuild.buildroot.net/results/b908769c1291da8f758a44b04d36dbc415400b39/ Those ones should be fixed now, they were caused by issues in the autobuilder script. > x86_64 | vlc-2.1.2 | NOK | http://autobuild.buildroot.net/results/a53ea017ec92150c7d37c0da0ca9a8dac75f460e/ /home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../i686-pc-linux-gnu/bin/ld: ./.libs/libvlc_srtp.a(libvlc_srtp_la-srtp.o): relocation R_X86_64_PC32 against undefined symbol `gcry_md_reset@@GCRYPT_1.2' can not be used when making a shared object; recompile with -fPIC /home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../i686-pc-linux-gnu/bin/ld: final link failed: Bad value > powerpc | w_scan-20130331 | NOK | http://autobuild.buildroot.net/results/6e7c691099a8f3eef4fc84860ceb1a94f25873eb/ Too old kernel headers. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Buildroot] Analysis of build failures 2014-02-14 9:12 ` [Buildroot] Analysis of build failures Thomas Petazzoni @ 2014-02-14 10:23 ` Anton Kolesov 2014-02-14 14:13 ` Thomas Petazzoni 2014-02-14 11:29 ` Peter Korsgaard ` (3 subsequent siblings) 4 siblings, 1 reply; 27+ messages in thread From: Anton Kolesov @ 2014-02-14 10:23 UTC (permalink / raw) To: buildroot Hi Thomas, > > > arc | imagemagick-6.8.8-4 | NOK | > http://autobuild.buildroot.net/results/97ec0c366c24bd03fe4c26851e8729a4d > 8eaf4d0/ > > Internal compiler error. Anton, would you mind checking if your recent > bump of the ARC toolchain components solves this compiler problem? No, that hasn't fixed yet. I've opened bug report for this error, but no ETA. Should I disable affected packages for ARC until solution will be ready? > > arc | libxml2-2.9.1 | NOK | > http://autobuild.buildroot.net/results/4abdea83c6915aa02b6dc55c9a9dd964 > ba70ac4b/ > > Another internal compiler error. Anton, same thing, is that fixed by your > recent bump? Yes, it passes for me with the "next" branch. Anton ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Buildroot] Analysis of build failures 2014-02-14 10:23 ` Anton Kolesov @ 2014-02-14 14:13 ` Thomas Petazzoni 2014-02-14 14:42 ` Peter Korsgaard 0 siblings, 1 reply; 27+ messages in thread From: Thomas Petazzoni @ 2014-02-14 14:13 UTC (permalink / raw) To: buildroot Dear Anton Kolesov, On Fri, 14 Feb 2014 10:23:00 +0000, Anton Kolesov wrote: > > > arc | imagemagick-6.8.8-4 | NOK | > > http://autobuild.buildroot.net/results/97ec0c366c24bd03fe4c26851e8729a4d > > 8eaf4d0/ > > > > Internal compiler error. Anton, would you mind checking if your recent > > bump of the ARC toolchain components solves this compiler problem? > > No, that hasn't fixed yet. I've opened bug report for this error, but no ETA. Should I disable affected packages for ARC until solution will be ready? Yes, please. > > > arc | libxml2-2.9.1 | NOK | > > http://autobuild.buildroot.net/results/4abdea83c6915aa02b6dc55c9a9dd964 > > ba70ac4b/ > > > > Another internal compiler error. Anton, same thing, is that fixed by your > > recent bump? > > Yes, it passes for me with the "next" branch. Argh. So libxml2 doesn't build at all on master. This is pretty annoying, because this package has a fairly large number of reverse dependencies, so marking all of them "depends on !BR2_arc" to avoid build problems occurring on master is going to be annoying. I was discussing this morning with better whether he should have merged your ARC toolchain components bump to master instead of next. He merged in next to be on the safe side, but the consequence is that we have a good number of packages that don't build for ARC in master, causing autobuilder failures, that we know are solved in next. Oh well, I guess it's just a matter of waiting for the release at the end of the month, and get next merged into master. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Buildroot] Analysis of build failures 2014-02-14 14:13 ` Thomas Petazzoni @ 2014-02-14 14:42 ` Peter Korsgaard 2014-02-14 15:19 ` Thomas Petazzoni 0 siblings, 1 reply; 27+ messages in thread From: Peter Korsgaard @ 2014-02-14 14:42 UTC (permalink / raw) To: buildroot >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: Hi, >> Yes, it passes for me with the "next" branch. > Argh. So libxml2 doesn't build at all on master. This is pretty > annoying, because this package has a fairly large number of reverse > dependencies, so marking all of them "depends on !BR2_arc" to avoid > build problems occurring on master is going to be annoying. > I was discussing this morning with better whether he should have merged s/better/Peter/ ;) > your ARC toolchain components bump to master instead of next. He merged > in next to be on the safe side, but the consequence is that we have a > good number of packages that don't build for ARC in master, causing > autobuilder failures, that we know are solved in next. > Oh well, I guess it's just a matter of waiting for the release at the > end of the month, and get next merged into master. As I said on IRC, if we think arc will be in a better state with those bumps cherry picked to master instead, then that's fine for me as well. -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Buildroot] Analysis of build failures 2014-02-14 14:42 ` Peter Korsgaard @ 2014-02-14 15:19 ` Thomas Petazzoni 2014-02-14 17:05 ` Anton Kolesov 0 siblings, 1 reply; 27+ messages in thread From: Thomas Petazzoni @ 2014-02-14 15:19 UTC (permalink / raw) To: buildroot Dear Peter Korsgaard, On Fri, 14 Feb 2014 15:42:16 +0100, Peter Korsgaard wrote: > > Argh. So libxml2 doesn't build at all on master. This is pretty > > annoying, because this package has a fairly large number of reverse > > dependencies, so marking all of them "depends on !BR2_arc" to avoid > > build problems occurring on master is going to be annoying. > > > I was discussing this morning with better whether he should have merged > > s/better/Peter/ ;) Oops, sorry! Fortunately I have this automatic thing "Dear <foo>", which gets your name right whenever I reply to you :-) > > your ARC toolchain components bump to master instead of next. He merged > > in next to be on the safe side, but the consequence is that we have a > > good number of packages that don't build for ARC in master, causing > > autobuilder failures, that we know are solved in next. > > > Oh well, I guess it's just a matter of waiting for the release at the > > end of the month, and get next merged into master. > > As I said on IRC, if we think arc will be in a better state with those > bumps cherry picked to master instead, then that's fine for me as well. Anton, what is your confidence with this bump of the toolchain components? Should we merge it for 2014.02 ? Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Buildroot] Analysis of build failures 2014-02-14 15:19 ` Thomas Petazzoni @ 2014-02-14 17:05 ` Anton Kolesov 2014-02-14 17:42 ` Thomas Petazzoni 0 siblings, 1 reply; 27+ messages in thread From: Anton Kolesov @ 2014-02-14 17:05 UTC (permalink / raw) To: buildroot Hi Thomas and Peter, > > > > As I said on IRC, if we think arc will be in a better state with those > > bumps cherry picked to master instead, then that's fine for me as well. > > Anton, what is your confidence with this bump of the toolchain > components? Should we merge it for 2014.02 ? > I would say that I would prefer to keep current state, because currently master points to our released versions, which are pretty much of a known entity for us, even if with some known failures. Latest commits haven?t been completely tested, so while they fix some bugs, they might introduce some new undiscovered troubles as well, so I don't feel safe about pointing to them in the buildroot release. Since it is a problem of our tools, I can volunteer to prepare patches that disable reverse dependencies of libxml for ARC in master, though you still will have to apply them :) I will ask our team opinion on this as well. And let me know if you are ok if I we just disable failing packages in master. Anton ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Buildroot] Analysis of build failures 2014-02-14 17:05 ` Anton Kolesov @ 2014-02-14 17:42 ` Thomas Petazzoni 0 siblings, 0 replies; 27+ messages in thread From: Thomas Petazzoni @ 2014-02-14 17:42 UTC (permalink / raw) To: buildroot Dear Anton Kolesov, On Fri, 14 Feb 2014 17:05:24 +0000, Anton Kolesov wrote: > I would say that I would prefer to keep current state, because currently master points to our released versions, which are pretty much of a known entity for us, even if with some known failures. Latest commits haven?t been completely tested, so while they fix some bugs, they might introduce some new undiscovered troubles as well, so I don't feel safe about pointing to them in the buildroot release. Ok, no problem! > Since it is a problem of our tools, I can volunteer to prepare patches that disable reverse dependencies of libxml for ARC in master, though you still will have to apply them :) > > I will ask our team opinion on this as well. And let me know if you are ok if I we just disable failing packages in master. I believe it's ok to disable failing packages in master, except when they have too many reverse dependencies and that we know the problem will be fixed soon. For such cases, I can simply add an exception to the autobuilder script. Thanks! Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Buildroot] Analysis of build failures 2014-02-14 9:12 ` [Buildroot] Analysis of build failures Thomas Petazzoni 2014-02-14 10:23 ` Anton Kolesov @ 2014-02-14 11:29 ` Peter Korsgaard 2014-02-14 13:15 ` Ezequiel García ` (2 subsequent siblings) 4 siblings, 0 replies; 27+ messages in thread From: Peter Korsgaard @ 2014-02-14 11:29 UTC (permalink / raw) To: buildroot >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: Hi, >> nios2 | crda-1.1.3 | NOK | http://autobuild.buildroot.net/results/780c3388e408ae6479e824711b1c02fdbd34bef4/ > No idea what this error means. Ezequiel ? > /home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.7.3/../../../../nios2-linux-gnu/bin/ld: /home/test/test/2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/lib/crt1.o: undefined reference to symbol '_gp' > /home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.7.3/../../../../nios2-linux-gnu/bin/ld: note: '_gp' is defined in DSO /home/test/test/2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/lib/libgpg-error.so.0 so try adding it to the linker command line If I remember correctly, _gp is a magic linker symbol on mips/nios. When we discussed it last time I brought up this link: https://lists.debian.org/debian-mips/2013/06/msg00041.html >> x86_64 | gst1-libav-1.2.2 | NOK | http://autobuild.buildroot.net/results/2d83f38b4a6cb2a1a47c78306da7773270ce698e/ > Weird: > /home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-unknown-linux-uclibc/4.6.3/../../../../x86_64-unknown-linux-uclibc/bin/ld: ../../gst-libs/ext/libav/libavcodec/libavcodec.a(lpc.o): relocation R_X86_64_PC32 against symbol `ff_pd_1' can not be used when making a shared object; recompile with -fPIC > But the build is not a static library build. But it uses a static (embedded) copy of libav, perhaps that one isn't built with -fPIC? >> powerpc | tstools-1_11 | NOK | http://autobuild.buildroot.net/results/b92b707ec32bf6f9a0c5834fd68d81d76d1a6365/ > Weird messages: > Assembler messages: > Fatal error: can't create obj/esfilter.o: No such file or directory > Parallel build issue? Sounds like it. -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Buildroot] Analysis of build failures 2014-02-14 9:12 ` [Buildroot] Analysis of build failures Thomas Petazzoni 2014-02-14 10:23 ` Anton Kolesov 2014-02-14 11:29 ` Peter Korsgaard @ 2014-02-14 13:15 ` Ezequiel García 2014-02-15 7:27 ` Frank Bergmann 2014-02-15 17:29 ` Frank Bergmann 2014-02-15 21:31 ` [Buildroot] Analysis of build failures Baruch Siach 2014-02-16 0:00 ` [Buildroot] Analysis of build failures Romain Naour 4 siblings, 2 replies; 27+ messages in thread From: Ezequiel García @ 2014-02-14 13:15 UTC (permalink / raw) To: buildroot On 14 February 2014 06:12, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: >> nios2 | crda-1.1.3 | NOK | http://autobuild.buildroot.net/results/780c3388e408ae6479e824711b1c02fdbd34bef4/ > > No idea what this error means. Ezequiel ? > > /home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.7.3/../../../../nios2-linux-gnu/bin/ld: /home/test/test/2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/lib/crt1.o: undefined reference to symbol '_gp' > /home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.7.3/../../../../nios2-linux-gnu/bin/ld: note: '_gp' is defined in DSO /home/test/test/2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/lib/libgpg-error.so.0 so try adding it to the linker command line > As Peter said, some issue with the compiler. This is too much for me :-) Adding nios2 support in the internal toolchain is on my (increasingly long) TODO list. >> nios2 | e2fsprogs-1.42.9 | NOK | http://autobuild.buildroot.net/results/70a47bd7392560cbc1c64769c8357c0b4c91ca3b/ > > Another missing syscall on NIOS II ? Ezequiel ? > > ../lib/libext2fs.so: undefined reference to `fallocate64' > collect2: error: ld returned 1 exit status > Ah, yes. We have lots of packages failing with this issue. I think it's some issue with the toolchain. fallocate64 is not a system call (only fallocate exists, AFAICS), so this should be some libc issue. Anybody knows better? Who implements fallocate64? What can we do to fix this in Buildroot (using an external toolchain)? >> nios2 | libnetfilter_queue-1.0.2 | NOK | http://autobuild.buildroot.net/results/3d77c91847a099b2498030505b91f3f84c81df18/ > > Issue with kernel headers ? > > /home/test/test/1/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/include/libnfnetlink/linux_nfnetlink.h:6:6: error: nested redefinition of 'enum nfnetlink_groups' > /home/test/test/1/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/include/libnfnetlink/linux_nfnetlink.h:6:6: error: redeclaration of 'enum nfnetlink_groups' > The kernel headers exported by CodeSourcery toolchain seem to be copied using some braindead cp-like copy, instead of using "make headers_install". The latter does some modification to the headers. The dhcp package also fails because of this. Let's put this on top of my nios2 TODO list. Can we apply the header sanitize in Buildroot, when we install the Sourcery toolchain? -- Ezequiel Garc?a, VanguardiaSur www.vanguardiasur.com.ar ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Buildroot] Analysis of build failures 2014-02-14 13:15 ` Ezequiel García @ 2014-02-15 7:27 ` Frank Bergmann 2014-02-15 17:29 ` Frank Bergmann 1 sibling, 0 replies; 27+ messages in thread From: Frank Bergmann @ 2014-02-15 7:27 UTC (permalink / raw) To: buildroot Hello, On 14.02.2014 14:15, Ezequiel Garc?a wrote: > On 14 February 2014 06:12, Thomas Petazzoni > <thomas.petazzoni@free-electrons.com> wrote: >>> nios2 | crda-1.1.3 | NOK | http://autobuild.buildroot.net/results/780c3388e408ae6479e824711b1c02fdbd34bef4/ >> >> No idea what this error means. Ezequiel ? >> >> /home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.7.3/../../../../nios2-linux-gnu/bin/ld: /home/test/test/2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/lib/crt1.o: undefined reference to symbol '_gp' >> /home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.7.3/../../../../nios2-linux-gnu/bin/ld: note: '_gp' is defined in DSO /home/test/test/2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/lib/libgpg-error.so.0 so try adding it to the linker command line >> > > As Peter said, some issue with the compiler. This is too much for me :-) What about the hint the linker gives in the line after the error ? Link the binary with the additional LDFLAG '-lgpg-error' build the binary (but I have not run-time tested the result). This is also the advise from libgcrypt: $> libgcrypt-config --libs -lgcrypt -ldl -lgpg-error I guess this is an unlucky accident: libgpg-error exports a symbol/function named '_gp' that could lead one to think it's about the global pointer from the nios2. > Adding nios2 support in the internal toolchain is on my (increasingly > long) TODO list. That's fine. Is there a public repository for early testing ? With regards, Frank Bergmann. ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Buildroot] Analysis of build failures 2014-02-14 13:15 ` Ezequiel García 2014-02-15 7:27 ` Frank Bergmann @ 2014-02-15 17:29 ` Frank Bergmann 2014-02-15 18:52 ` [Buildroot] [PATCH 1/1] e2fsprogs: fix missing fallocate64() on nios2 Frank Bergmann 1 sibling, 1 reply; 27+ messages in thread From: Frank Bergmann @ 2014-02-15 17:29 UTC (permalink / raw) To: buildroot Hello, On 14.02.2014 14:15, Ezequiel Garc?a wrote: >>> nios2 | e2fsprogs-1.42.9 | NOK | http://autobuild.buildroot.net/results/70a47bd7392560cbc1c64769c8357c0b4c91ca3b/ >> >> Another missing syscall on NIOS II ? Ezequiel ? >> >> ../lib/libext2fs.so: undefined reference to `fallocate64' >> collect2: error: ld returned 1 exit status >> > > Ah, yes. We have lots of packages failing with this issue. I think > it's some issue > with the toolchain. fallocate64 is not a system call (only fallocate > exists, AFAICS), > so this should be some libc issue. > > Anybody knows better? Who implements fallocate64? What can we do to fix this > in Buildroot (using an external toolchain)? No, sorry. But after dig a little bit: e2fsprogs using _FILE_OFFSET_BITS=64 while compiling the source. In this case the fallocate system call will be silently replaced by fallocate64 (see: https://lists.debian.org/debian-glibc/2010/02/msg00088.html). But fallocate64 is unfortunately not available on nios2 toolchain at the moment. The only solution that works appears to be completely disable the fallocate system call(s) by providing ac_cv_func_fallocate=no to the configure script. The effect in e2fsprogs will be that unix_discard() in ext2fs/unix_io.c will return with the "UNIMPLEMENTED" return code. I'm not sure for the moment if the whole packages or only a couple of functions gets unusable with this. With regards, Frank Bergmann. ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Buildroot] [PATCH 1/1] e2fsprogs: fix missing fallocate64() on nios2 2014-02-15 17:29 ` Frank Bergmann @ 2014-02-15 18:52 ` Frank Bergmann 2014-02-18 21:19 ` Thomas Petazzoni 2014-02-27 13:35 ` Peter Korsgaard 0 siblings, 2 replies; 27+ messages in thread From: Frank Bergmann @ 2014-02-15 18:52 UTC (permalink / raw) To: buildroot Nios2 is currently missing the fallocate64 system call. Because of compiling the e2fsprogs package with _FILE_OFFSET_BITS=64 the fallocate call is replaced by fallocate64 by the glibc. Therefor fallocate is entirely disbaled while configuring the package. e4defrag have to be disabled because it declares the fallocate64 but the library have its own defined. It fixes an autobuilder issue: http://autobuild.buildroot.org/results/70a/70a47bd7392560cbc1c64769c8357c0b4c91ca3b/ Signed-off-by: Frank Bergmann <frank@frajasalo.de> --- package/e2fsprogs/Config.in | 2 +- package/e2fsprogs/e2fsprogs.mk | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/package/e2fsprogs/Config.in b/package/e2fsprogs/Config.in index 7775e94..1e87aef 100644 --- a/package/e2fsprogs/Config.in +++ b/package/e2fsprogs/Config.in @@ -49,7 +49,7 @@ config BR2_PACKAGE_E2FSPROGS_E2UNDO config BR2_PACKAGE_E2FSPROGS_E4DEFRAG bool "e4defrag" - depends on !BR2_avr32 # fallocate not implemented + depends on !BR2_avr32 && !BR2_nios2 # fallocate not implemented config BR2_PACKAGE_E2FSPROGS_FILEFRAG bool "filefrag" diff --git a/package/e2fsprogs/e2fsprogs.mk b/package/e2fsprogs/e2fsprogs.mk index 2eb59f5..310f549 100644 --- a/package/e2fsprogs/e2fsprogs.mk +++ b/package/e2fsprogs/e2fsprogs.mk @@ -23,7 +23,8 @@ E2FSPROGS_CONF_OPT = \ --disable-libuuid \ --enable-fsck \ --disable-e2initrd-helper \ - --disable-testio-debug + --disable-testio-debug \ + $(if $(BR2_nios2),ac_cv_func_fallocate=no,) E2FSPROGS_DEPENDENCIES = host-pkgconf util-linux -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* [Buildroot] [PATCH 1/1] e2fsprogs: fix missing fallocate64() on nios2 2014-02-15 18:52 ` [Buildroot] [PATCH 1/1] e2fsprogs: fix missing fallocate64() on nios2 Frank Bergmann @ 2014-02-18 21:19 ` Thomas Petazzoni 2014-02-18 23:13 ` Frank Bergmann 2014-02-27 13:35 ` Peter Korsgaard 1 sibling, 1 reply; 27+ messages in thread From: Thomas Petazzoni @ 2014-02-18 21:19 UTC (permalink / raw) To: buildroot Dear Frank Bergmann, Please send your patches with "git send-email". Thunderbird has badly replaces the tabs by spaces. On Sat, 15 Feb 2014 19:52:01 +0100, Frank Bergmann wrote: > Nios2 is currently missing the fallocate64 system call. Because of > compiling the e2fsprogs package with _FILE_OFFSET_BITS=64 the fallocate > call is replaced by fallocate64 by the glibc. Therefor fallocate is > entirely disbaled while configuring the package. Therefor -> Therefore disbaled -> disabled > > e4defrag have to be disabled because it declares the fallocate64 but > the library have its own defined. Not sure I understand this part. > > It fixes an autobuilder issue: > http://autobuild.buildroot.org/results/70a/70a47bd7392560cbc1c64769c8357c0b4c91ca3b/ > > Signed-off-by: Frank Bergmann <frank@frajasalo.de> > --- > package/e2fsprogs/Config.in | 2 +- > package/e2fsprogs/e2fsprogs.mk | 3 ++- > 2 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/package/e2fsprogs/Config.in b/package/e2fsprogs/Config.in > index 7775e94..1e87aef 100644 > --- a/package/e2fsprogs/Config.in > +++ b/package/e2fsprogs/Config.in > @@ -49,7 +49,7 @@ config BR2_PACKAGE_E2FSPROGS_E2UNDO > > config BR2_PACKAGE_E2FSPROGS_E4DEFRAG > bool "e4defrag" > - depends on !BR2_avr32 # fallocate not implemented > + depends on !BR2_avr32 && !BR2_nios2 # fallocate not implemented > > config BR2_PACKAGE_E2FSPROGS_FILEFRAG > bool "filefrag" > diff --git a/package/e2fsprogs/e2fsprogs.mk b/package/e2fsprogs/e2fsprogs.mk > index 2eb59f5..310f549 100644 > --- a/package/e2fsprogs/e2fsprogs.mk > +++ b/package/e2fsprogs/e2fsprogs.mk > @@ -23,7 +23,8 @@ E2FSPROGS_CONF_OPT = \ > --disable-libuuid \ > --enable-fsck \ > --disable-e2initrd-helper \ > - --disable-testio-debug > + --disable-testio-debug \ > + $(if $(BR2_nios2),ac_cv_func_fallocate=no,) Such variables are normally passed in <pkg>_CONF_ENV. Also, in Config.in, the fallocate problem seems to also apply for AVR32, while you only pass ac_cv_func_fallocate=no for NIOS II here. Could you explain why? Thanks, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Buildroot] [PATCH 1/1] e2fsprogs: fix missing fallocate64() on nios2 2014-02-18 21:19 ` Thomas Petazzoni @ 2014-02-18 23:13 ` Frank Bergmann 2014-02-20 20:52 ` Frank Bergmann 0 siblings, 1 reply; 27+ messages in thread From: Frank Bergmann @ 2014-02-18 23:13 UTC (permalink / raw) To: buildroot Hello, On 18.02.2014 22:19, Thomas Petazzoni wrote: > Dear Frank Bergmann, > > Please send your patches with "git send-email". Thunderbird has badly > replaces the tabs by spaces. Sorry for that, next time using the right tool ! > On Sat, 15 Feb 2014 19:52:01 +0100, Frank Bergmann wrote: >> Nios2 is currently missing the fallocate64 system call. Because of >> compiling the e2fsprogs package with _FILE_OFFSET_BITS=64 the fallocate >> call is replaced by fallocate64 by the glibc. Therefor fallocate is >> entirely disbaled while configuring the package. > > Therefor -> Therefore > disbaled -> disabled > >> >> e4defrag have to be disabled because it declares the fallocate64 but >> the library have its own defined. > > Not sure I understand this part. Sorry for not being clear but the toolchain is a little bit messy: In the toolchain headers fallocate64 is defined but it is not implemented in the library. e4defrag declares its own fallocate64 function that throw an error because of the previous declaration in the header. > >> >> It fixes an autobuilder issue: >> http://autobuild.buildroot.org/results/70a/70a47bd7392560cbc1c64769c8357c0b4c91ca3b/ >> >> Signed-off-by: Frank Bergmann <frank@frajasalo.de> >> --- >> package/e2fsprogs/Config.in | 2 +- >> package/e2fsprogs/e2fsprogs.mk | 3 ++- >> 2 files changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/package/e2fsprogs/Config.in b/package/e2fsprogs/Config.in >> index 7775e94..1e87aef 100644 >> --- a/package/e2fsprogs/Config.in >> +++ b/package/e2fsprogs/Config.in >> @@ -49,7 +49,7 @@ config BR2_PACKAGE_E2FSPROGS_E2UNDO >> >> config BR2_PACKAGE_E2FSPROGS_E4DEFRAG >> bool "e4defrag" >> - depends on !BR2_avr32 # fallocate not implemented >> + depends on !BR2_avr32 && !BR2_nios2 # fallocate not implemented >> >> config BR2_PACKAGE_E2FSPROGS_FILEFRAG >> bool "filefrag" >> diff --git a/package/e2fsprogs/e2fsprogs.mk b/package/e2fsprogs/e2fsprogs.mk >> index 2eb59f5..310f549 100644 >> --- a/package/e2fsprogs/e2fsprogs.mk >> +++ b/package/e2fsprogs/e2fsprogs.mk >> @@ -23,7 +23,8 @@ E2FSPROGS_CONF_OPT = \ >> --disable-libuuid \ >> --enable-fsck \ >> --disable-e2initrd-helper \ >> - --disable-testio-debug >> + --disable-testio-debug \ >> + $(if $(BR2_nios2),ac_cv_func_fallocate=no,) > > Such variables are normally passed in <pkg>_CONF_ENV. Also, in > Config.in, the fallocate problem seems to also apply for AVR32, while > you only pass ac_cv_func_fallocate=no for NIOS II here. Could you > explain why? As written in the patch description fallocate is replaced by fallocate64 if using _FILE_OFFSET_BITS=64 . fallocate64 is not available in nios2 toolchain library. So if in that case we want to avoid fallocate64 then we have to avoid fallocate. Not sure for the moment why it's working for AVR32 but fallocate is referenced in lib/ext2fs/unix_io.c which builds libext2fs.so and therefore it's independent of e4defrag. Only avoiding e4defrag does not work for nios2. I missed that ac_cv_func_fallocate is normally passed in E2FSPROGS_CONF_ENV. Regards, Frank. ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Buildroot] [PATCH 1/1] e2fsprogs: fix missing fallocate64() on nios2 2014-02-18 23:13 ` Frank Bergmann @ 2014-02-20 20:52 ` Frank Bergmann 0 siblings, 0 replies; 27+ messages in thread From: Frank Bergmann @ 2014-02-20 20:52 UTC (permalink / raw) To: buildroot Hello, On 19.02.2014 00:13, Frank Bergmann wrote: > On 18.02.2014 22:19, Thomas Petazzoni wrote: >>> diff --git a/package/e2fsprogs/Config.in b/package/e2fsprogs/Config.in >>> index 7775e94..1e87aef 100644 >>> --- a/package/e2fsprogs/Config.in >>> +++ b/package/e2fsprogs/Config.in >>> @@ -49,7 +49,7 @@ config BR2_PACKAGE_E2FSPROGS_E2UNDO >>> >>> config BR2_PACKAGE_E2FSPROGS_E4DEFRAG >>> bool "e4defrag" >>> - depends on !BR2_avr32 # fallocate not implemented >>> + depends on !BR2_avr32 && !BR2_nios2 # fallocate not implemented >>> >>> config BR2_PACKAGE_E2FSPROGS_FILEFRAG >>> bool "filefrag" >>> diff --git a/package/e2fsprogs/e2fsprogs.mk b/package/e2fsprogs/e2fsprogs.mk >>> index 2eb59f5..310f549 100644 >>> --- a/package/e2fsprogs/e2fsprogs.mk >>> +++ b/package/e2fsprogs/e2fsprogs.mk >>> @@ -23,7 +23,8 @@ E2FSPROGS_CONF_OPT = \ >>> --disable-libuuid \ >>> --enable-fsck \ >>> --disable-e2initrd-helper \ >>> - --disable-testio-debug >>> + --disable-testio-debug \ >>> + $(if $(BR2_nios2),ac_cv_func_fallocate=no,) >> >> Such variables are normally passed in <pkg>_CONF_ENV. Also, in >> Config.in, the fallocate problem seems to also apply for AVR32, while >> you only pass ac_cv_func_fallocate=no for NIOS II here. Could you >> explain why? > > As written in the patch description fallocate is replaced by fallocate64 if using > _FILE_OFFSET_BITS=64 . fallocate64 is not available in nios2 toolchain library. So > if in that case we want to avoid fallocate64 then we have to avoid fallocate. > > Not sure for the moment why it's working for AVR32 but fallocate is referenced in > lib/ext2fs/unix_io.c which builds libext2fs.so and therefore it's independent of > e4defrag. Only avoiding e4defrag does not work for nios2. On AVR32 there is neither fallocate nor fallocate64 available. e4defrag has to be disabled on this architecture because it uses the fallocate system call which is also not available. Frank. ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Buildroot] [PATCH 1/1] e2fsprogs: fix missing fallocate64() on nios2 2014-02-15 18:52 ` [Buildroot] [PATCH 1/1] e2fsprogs: fix missing fallocate64() on nios2 Frank Bergmann 2014-02-18 21:19 ` Thomas Petazzoni @ 2014-02-27 13:35 ` Peter Korsgaard 1 sibling, 0 replies; 27+ messages in thread From: Peter Korsgaard @ 2014-02-27 13:35 UTC (permalink / raw) To: buildroot >>>>> "Frank" == Frank Bergmann <frank@frajasalo.de> writes: > Nios2 is currently missing the fallocate64 system call. Because of > compiling the e2fsprogs package with _FILE_OFFSET_BITS=64 the fallocate > call is replaced by fallocate64 by the glibc. Therefor fallocate is > entirely disbaled while configuring the package. > e4defrag have to be disabled because it declares the fallocate64 but > the library have its own defined. > It fixes an autobuilder issue: > http://autobuild.buildroot.org/results/70a/70a47bd7392560cbc1c64769c8357c0b4c91ca3b/ > Signed-off-by: Frank Bergmann <frank@frajasalo.de> Committed, thanks. -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Buildroot] Analysis of build failures 2014-02-14 9:12 ` [Buildroot] Analysis of build failures Thomas Petazzoni ` (2 preceding siblings ...) 2014-02-14 13:15 ` Ezequiel García @ 2014-02-15 21:31 ` Baruch Siach 2014-02-18 21:22 ` [Buildroot] Xtensa support ? Thomas Petazzoni 2014-02-16 0:00 ` [Buildroot] Analysis of build failures Romain Naour 4 siblings, 1 reply; 27+ messages in thread From: Baruch Siach @ 2014-02-15 21:31 UTC (permalink / raw) To: buildroot Hi Thomas, On Fri, Feb 14, 2014 at 10:12:41AM +0100, Thomas Petazzoni wrote: > > xtensa | kmod-16 | NOK | http://autobuild.buildroot.net/results/ba205bcbb6898bee78f610883f3837930eda262c/ > > Binutils internal error. Baruch ? Xtensa Toolchain issues are out of scope for me at the moment I'm afraid. Sorry. baruch -- http://baruch.siach.name/blog/ ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il - ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Buildroot] Xtensa support ? 2014-02-15 21:31 ` [Buildroot] Analysis of build failures Baruch Siach @ 2014-02-18 21:22 ` Thomas Petazzoni 2014-02-19 0:24 ` Chris Zankel 2014-02-19 5:26 ` Jonathan Ben Avraham 0 siblings, 2 replies; 27+ messages in thread From: Thomas Petazzoni @ 2014-02-18 21:22 UTC (permalink / raw) To: buildroot Baruch, On Sat, 15 Feb 2014 23:31:24 +0200, Baruch Siach wrote: > On Fri, Feb 14, 2014 at 10:12:41AM +0100, Thomas Petazzoni wrote: > > > xtensa | kmod-16 | NOK | http://autobuild.buildroot.net/results/ba205bcbb6898bee78f610883f3837930eda262c/ > > > > Binutils internal error. Baruch ? > > Xtensa Toolchain issues are out of scope for me at the moment I'm afraid. > Sorry. Argh, too bad. You have been very active in recent times in improving the Xtensa support, and this was really nice. The daily Xtensa autobuilder failures are sent to chris at zankel.net, but Chris doesn't seem to be very active in fixing the issues. Chris, are you still interested in Buildroot Xtensa support? Are there other Xtensa users on the list? If so, please speak up, we need you to continue improving the Xtensa Buildroot support. Thanks, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Buildroot] Xtensa support ? 2014-02-18 21:22 ` [Buildroot] Xtensa support ? Thomas Petazzoni @ 2014-02-19 0:24 ` Chris Zankel 2014-02-19 8:04 ` Thomas Petazzoni 2014-02-19 5:26 ` Jonathan Ben Avraham 1 sibling, 1 reply; 27+ messages in thread From: Chris Zankel @ 2014-02-19 0:24 UTC (permalink / raw) To: buildroot +CC: Max Hi Thomas, Unfortunately, I have been really busy with another project and won't have much time to look into it for another week or so. Max has been working on Xtensa a lot, so maybe he can step in? If the autobuilder supports multiple recipients, it would be great if you could still keep me in that list, though. Thanks, -Chris On 2/18/14, 1:22 PM, Thomas Petazzoni wrote: > Baruch, > > On Sat, 15 Feb 2014 23:31:24 +0200, Baruch Siach wrote: > >> On Fri, Feb 14, 2014 at 10:12:41AM +0100, Thomas Petazzoni wrote: >>>> xtensa | kmod-16 | NOK | http://autobuild.buildroot.net/results/ba205bcbb6898bee78f610883f3837930eda262c/ >>> Binutils internal error. Baruch ? >> Xtensa Toolchain issues are out of scope for me at the moment I'm afraid. >> Sorry. > Argh, too bad. You have been very active in recent times in improving > the Xtensa support, and this was really nice. > > The daily Xtensa autobuilder failures are sent to chris at zankel.net, but > Chris doesn't seem to be very active in fixing the issues. Chris, are > you still interested in Buildroot Xtensa support? > > Are there other Xtensa users on the list? If so, please speak up, we > need you to continue improving the Xtensa Buildroot support. > > Thanks, > > Thomas ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Buildroot] Xtensa support ? 2014-02-19 0:24 ` Chris Zankel @ 2014-02-19 8:04 ` Thomas Petazzoni [not found] ` <CAMo8Bf+gfdgfV+XFows8HmppvXdL=VWXGG_givbUNerep0zeHg@mail.gmail.com> 0 siblings, 1 reply; 27+ messages in thread From: Thomas Petazzoni @ 2014-02-19 8:04 UTC (permalink / raw) To: buildroot Dear Chris Zankel, On Tue, 18 Feb 2014 16:24:20 -0800, Chris Zankel wrote: > Unfortunately, I have been really busy with another project and won't > have much time to look into it for another week or so. I am not really worried about the immediate future (i.e the coming week), but more in the mid to long term future. > Max has been working on Xtensa a lot, so maybe he can step in? We'll be definitely happy to receive contributions from Max. Max, do you want to receive a daily e-mail that lists the Xtensa build issues (no mail is sent when there are no Xtensa build issues during the day). > If the autobuilder supports multiple recipients, it would be great if > you could still keep me in that list, though. I can send the e-mail to as many recipients as I want, so I'll definitely keep you in the list. Thanks! Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <CAMo8Bf+gfdgfV+XFows8HmppvXdL=VWXGG_givbUNerep0zeHg@mail.gmail.com>]
* [Buildroot] Xtensa support ? [not found] ` <CAMo8Bf+gfdgfV+XFows8HmppvXdL=VWXGG_givbUNerep0zeHg@mail.gmail.com> @ 2014-02-19 13:19 ` Thomas Petazzoni 0 siblings, 0 replies; 27+ messages in thread From: Thomas Petazzoni @ 2014-02-19 13:19 UTC (permalink / raw) To: buildroot Dear Max Filippov, On Wed, 19 Feb 2014 14:46:28 +0400, Max Filippov wrote: > On Wed, Feb 19, 2014 at 12:04 PM, Thomas Petazzoni > <thomas.petazzoni@free-electrons.com> wrote: > >> Unfortunately, I have been really busy with another project and won't > >> have much time to look into it for another week or so. > > > > I am not really worried about the immediate future (i.e the coming > > week), but more in the mid to long term future. > > > >> Max has been working on Xtensa a lot, so maybe he can step in? > > I think I can. I've been always using somewhat old buildroot version, > so need some time to get familiar with its current state. Great! > > We'll be definitely happy to receive contributions from Max. Max, do > > you want to receive a daily e-mail that lists the Xtensa build issues > > (no mail is sent when there are no Xtensa build issues during the day). > > Yes, please. Done, you will receive the daily e-mail with Xtensa build failures starting tomorrow morning. Thanks for your participation! Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Buildroot] Xtensa support ? 2014-02-18 21:22 ` [Buildroot] Xtensa support ? Thomas Petazzoni 2014-02-19 0:24 ` Chris Zankel @ 2014-02-19 5:26 ` Jonathan Ben Avraham 2014-02-19 8:05 ` Thomas Petazzoni 1 sibling, 1 reply; 27+ messages in thread From: Jonathan Ben Avraham @ 2014-02-19 5:26 UTC (permalink / raw) To: buildroot On Tue, 18 Feb 2014, Thomas Petazzoni wrote: > Date: Tue, 18 Feb 2014 22:22:15 +0100 > From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> > To: Baruch Siach <baruch@tkos.co.il> > Cc: buildroot at uclibc.org > Subject: [Buildroot] Xtensa support ? > > Baruch, > > On Sat, 15 Feb 2014 23:31:24 +0200, Baruch Siach wrote: > >> On Fri, Feb 14, 2014 at 10:12:41AM +0100, Thomas Petazzoni wrote: >>>> xtensa | kmod-16 | NOK | http://autobuild.buildroot.net/results/ba205bcbb6898bee78f610883f3837930eda262c/ >>> >>> Binutils internal error. Baruch ? >> >> Xtensa Toolchain issues are out of scope for me at the moment I'm afraid. >> Sorry. > > Argh, too bad. You have been very active in recent times in improving > the Xtensa support, and this was really nice. > > The daily Xtensa autobuilder failures are sent to chris at zankel.net, but > Chris doesn't seem to be very active in fixing the issues. Chris, are > you still interested in Buildroot Xtensa support? > > Are there other Xtensa users on the list? If so, please speak up, we > need you to continue improving the Xtensa Buildroot support. > > Thanks, > > Thomas Hi Thomas, There is a chance that I can take over the Xtensa Buildroot support from Baruch. There is a budget issue and a ramp-up issue that I need to resolve first, but I believe that it's doable. I will let you know later in the day. Regards, - yba -- 9590 8E58 D30D 1660 C349 673D B205 4FC4 B8F5 B7F9 ~. .~ Tk Open Systems =}------------- Jonathan Ben-Avraham -------------ooO--U--Ooo------------{= mailto:yba at tkos.co.il tel:+972.52.486.3386 http://tkos.co.il skype:benavrhm ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Buildroot] Xtensa support ? 2014-02-19 5:26 ` Jonathan Ben Avraham @ 2014-02-19 8:05 ` Thomas Petazzoni 2014-02-19 8:16 ` Jonathan Ben Avraham 0 siblings, 1 reply; 27+ messages in thread From: Thomas Petazzoni @ 2014-02-19 8:05 UTC (permalink / raw) To: buildroot Dear Jonathan Ben Avraham, On Wed, 19 Feb 2014 07:26:14 +0200 (IST), Jonathan Ben Avraham wrote: > There is a chance that I can take over the Xtensa Buildroot support from > Baruch. There is a budget issue and a ramp-up issue that I need to resolve > first, but I believe that it's doable. I will let you know later in the > day. Cool. Let me know when you have the answer. Also, let me know if you want to receive daily e-mails about Xtensa autobuilder failures. Thanks! Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Buildroot] Xtensa support ? 2014-02-19 8:05 ` Thomas Petazzoni @ 2014-02-19 8:16 ` Jonathan Ben Avraham 2014-02-19 8:22 ` Thomas Petazzoni 0 siblings, 1 reply; 27+ messages in thread From: Jonathan Ben Avraham @ 2014-02-19 8:16 UTC (permalink / raw) To: buildroot On Wed, 19 Feb 2014, Thomas Petazzoni wrote: > Date: Wed, 19 Feb 2014 09:05:32 +0100 > From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> > To: Jonathan Ben Avraham <yba@tkos.co.il> > Cc: Baruch Siach <baruch@tkos.co.il>, buildroot at uclibc.org > Subject: Re: [Buildroot] Xtensa support ? > > Dear Jonathan Ben Avraham, > > On Wed, 19 Feb 2014 07:26:14 +0200 (IST), Jonathan Ben Avraham wrote: > >> There is a chance that I can take over the Xtensa Buildroot support from >> Baruch. There is a budget issue and a ramp-up issue that I need to resolve >> first, but I believe that it's doable. I will let you know later in the >> day. > > Cool. Let me know when you have the answer. Also, let me know if you > want to receive daily e-mails about Xtensa autobuilder failures. Hi Thomas, Yes, please keep Baruch and I on the Xtensa autobuilder list. If Baruch gives me his blessing for this effort then I intend to be in for the long-term. - yba (Jonathan) > Thanks! > > Thomas > -- 9590 8E58 D30D 1660 C349 673D B205 4FC4 B8F5 B7F9 ~. .~ Tk Open Systems =}------------- Jonathan Ben-Avraham -------------ooO--U--Ooo------------{= mailto:yba at tkos.co.il tel:+972.52.486.3386 http://tkos.co.il skype:benavrhm ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Buildroot] Xtensa support ? 2014-02-19 8:16 ` Jonathan Ben Avraham @ 2014-02-19 8:22 ` Thomas Petazzoni 0 siblings, 0 replies; 27+ messages in thread From: Thomas Petazzoni @ 2014-02-19 8:22 UTC (permalink / raw) To: buildroot Dear Jonathan Ben Avraham, On Wed, 19 Feb 2014 10:16:04 +0200 (IST), Jonathan Ben Avraham wrote: > > Cool. Let me know when you have the answer. Also, let me know if you > > want to receive daily e-mails about Xtensa autobuilder failures. > > Yes, please keep Baruch and I on the Xtensa autobuilder list. Until now, Baruch was not receiving the daily Xtensa e-mails, only Chris Zankel. Should I add both Baruch and you? > If Baruch gives me his blessing for this effort then I intend to be in for the > long-term. That would be great. We really need some contributors to maintain all these fairly specific architectures, so your help is definitely welcome here. Thanks, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Buildroot] Analysis of build failures 2014-02-14 9:12 ` [Buildroot] Analysis of build failures Thomas Petazzoni ` (3 preceding siblings ...) 2014-02-15 21:31 ` [Buildroot] Analysis of build failures Baruch Siach @ 2014-02-16 0:00 ` Romain Naour 4 siblings, 0 replies; 27+ messages in thread From: Romain Naour @ 2014-02-16 0:00 UTC (permalink / raw) To: buildroot Hi Thomas, All, >> i686 | imagemagick-6.8.8-4 | NOK | http://autobuild.buildroot.net/results/a9d35975c7699515350eb307712cd69b6d48e418/ > Not enough backlog to see what the error is, unfortunately. > > It is impossible to disable documentation in Imagemagick because all options like --disable-gtk-doc, --disable-doc, --disable-docs and --disable-documentation are not handled by configure script. It will be easier to understand what happens when the build fails if we remove hard coded documentation from Makefiles. I just sent a patch for this. Best regards, Romain Naour ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2014-02-27 13:35 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-14 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-13 Thomas Petazzoni
2014-02-14 9:12 ` [Buildroot] Analysis of build failures Thomas Petazzoni
2014-02-14 10:23 ` Anton Kolesov
2014-02-14 14:13 ` Thomas Petazzoni
2014-02-14 14:42 ` Peter Korsgaard
2014-02-14 15:19 ` Thomas Petazzoni
2014-02-14 17:05 ` Anton Kolesov
2014-02-14 17:42 ` Thomas Petazzoni
2014-02-14 11:29 ` Peter Korsgaard
2014-02-14 13:15 ` Ezequiel García
2014-02-15 7:27 ` Frank Bergmann
2014-02-15 17:29 ` Frank Bergmann
2014-02-15 18:52 ` [Buildroot] [PATCH 1/1] e2fsprogs: fix missing fallocate64() on nios2 Frank Bergmann
2014-02-18 21:19 ` Thomas Petazzoni
2014-02-18 23:13 ` Frank Bergmann
2014-02-20 20:52 ` Frank Bergmann
2014-02-27 13:35 ` Peter Korsgaard
2014-02-15 21:31 ` [Buildroot] Analysis of build failures Baruch Siach
2014-02-18 21:22 ` [Buildroot] Xtensa support ? Thomas Petazzoni
2014-02-19 0:24 ` Chris Zankel
2014-02-19 8:04 ` Thomas Petazzoni
[not found] ` <CAMo8Bf+gfdgfV+XFows8HmppvXdL=VWXGG_givbUNerep0zeHg@mail.gmail.com>
2014-02-19 13:19 ` Thomas Petazzoni
2014-02-19 5:26 ` Jonathan Ben Avraham
2014-02-19 8:05 ` Thomas Petazzoni
2014-02-19 8:16 ` Jonathan Ben Avraham
2014-02-19 8:22 ` Thomas Petazzoni
2014-02-16 0:00 ` [Buildroot] Analysis of build failures Romain Naour
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.