* [Buildroot] Analysis of build results for 2016-08-08
2016-08-09 12:15 ` [Buildroot] Analysis of build " Thomas Petazzoni
@ 2016-08-09 12:25 ` Gary Bisson
2016-08-09 12:34 ` Thomas Petazzoni
2016-08-09 13:27 ` Ezequiel Garcia
` (2 subsequent siblings)
3 siblings, 1 reply; 15+ messages in thread
From: Gary Bisson @ 2016-08-09 12:25 UTC (permalink / raw)
To: buildroot
Thomas, All,
On Tue, Aug 9, 2016 at 2:15 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> <snip>
>> arm | gst1-imx-0.12.2 | NOK | http://autobuild.buildroot.net/results/b460a770c8f4e992d29dde8fe37fc23a949937f2/
>
> error: 'V4L2_PIX_FMT_XRGB555X' undeclared (first use in this function)
>
> and other errors. We use kernel headers 4.7 since recently. Maybe
> there's something to fix here?
Actually I see in the defconfig that the external headers are 3.10
which is the issue. This V4L2 format was added in 3.18.
http://lxr.free-electrons.com/ident?v=3.10;i=V4L2_PIX_FMT_XRGB555X
http://lxr.free-electrons.com/ident?v=3.18;i=V4L2_PIX_FMT_XRGB555X
I've submitted a patch to Carlos to fix that:
https://github.com/Freescale/gstreamer-imx/pull/106
I don't see any other error, there's an 'error' variable that isn't
used but that's a warning.
I would wait for the change to be merged but if you want we can add
that patch to the Buildroot package for now.
Regards,
Gary
^ permalink raw reply [flat|nested] 15+ messages in thread* [Buildroot] Analysis of build results for 2016-08-08
2016-08-09 12:15 ` [Buildroot] Analysis of build " Thomas Petazzoni
2016-08-09 12:25 ` Gary Bisson
@ 2016-08-09 13:27 ` Ezequiel Garcia
2016-08-09 14:07 ` Romain Naour
2016-08-09 17:58 ` Yann E. MORIN
3 siblings, 0 replies; 15+ messages in thread
From: Ezequiel Garcia @ 2016-08-09 13:27 UTC (permalink / raw)
To: buildroot
On 9 August 2016 at 09:15, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Tue, 9 Aug 2016 08:30:32 +0200 (CEST), Thomas Petazzoni wrote:
>
>> bfin | acpitool-0.5.1 | NOK | http://autobuild.buildroot.net/results/0818dfa5d339424bdf7192634bed7e133c065f70/
>
> Still the Blackfin/C++ issue. We're going to disable C++ support in the
> Blackfin toolchain.
>
>> arc | aespipe-2.4c | NOK | http://autobuild.buildroot.net/results/b8dc85b990472ec0e205cedc1aa0eee424b63e4f/
>
> This is being analyzed by the people at Synopsys.
>
>> bfin | alsa-lib-1.1.2 | NOK | http://autobuild.buildroot.net/results/b0af78629db06c3693c8bbf8ec3aedfea606b1f9/
>
> undefined reference to `__emutls_get_address'
>
> Waldemar, this one is not a C++ issue I believe, can you check this?
>
>> mips64el | android-tools-4.2.2+git2013... | NOK | http://autobuild.buildroot.net/results/3b56943afccc03e5920e941325f3e60824bb95a2/
>
> error: conflicting types for 'u64'
> error: conflicting types for 'get_file_size'
>
> Weird. Someone to have a look?
>
>> arm | babeld-1.7.1 | NOK | http://autobuild.buildroot.net/results/a36fa8415507551dd4cf8503754655d2504fd330/
>
> musl build issue.
>
>> arm | cairo-1.14.6 | NOK | http://autobuild.buildroot.net/results/19af091fc6b8c496b1ee5bcbe6c075eb369c230c/
>
> Conflicting CPU architectures 13/1
>
>> m68k | cairo-1.14.6 | NOK | http://autobuild.buildroot.net/results/722a4fc268657620b805fdbeb0c62131df117d3d/
>
> Fixed by
> https://git.buildroot.org/buildroot/commit/?id=fd4f715268df5fbfc14e6ea8a54fd5de70b6a947.
>
>> m68k | clapack-3.2.1 | NOK | http://autobuild.buildroot.net/results/ba10714bd28e1dc21d4df2be030e2cef37846d6b/
>
> /tmp/ccySQY3I.s: Assembler messages:
> /tmp/ccySQY3I.s:14834: Error: value -34500 out of range
> /tmp/ccySQY3I.s:15075: Error: value -35250 out of range
> /tmp/ccySQY3I.s:15528: Error: value -45542 out of range
> /tmp/ccySQY3I.s:15529: Error: value -45566 out of range
> /tmp/ccySQY3I.s:15539: Error: value -45886 out of range
>
> Waldemar ?
>
>> i586 | connman-1.33 | NOK | http://autobuild.buildroot.net/results/71177f73c16f3fcb0500f6cc04690a85e32bf73c/
>> x86_64 | connman-1.33 | NOK | http://autobuild.buildroot.net/results/1dc914af4db2c894d521af2bc9f7d77e88f0c38d/
>> i586 | connman-1.33 | NOK | http://autobuild.buildroot.net/results/72537d66f78a0bf354436766cdc39c644c6e74b6/
>
> musl issues.
>
>> nios2 | dante-1.4.1 | NOK | http://autobuild.buildroot.net/results/4bc5501b792a3e14754796d279f61b75cebe83a0/
>> arc | dante-1.4.1 | NOK | http://autobuild.buildroot.net/results/ed51aa9c5559607f7df58dbc16bffd696779c0ed/
>
> Those two ones are:
>
> nios2-linux-gcc.br_real: error: 2: No such file or directory
> nios2-linux-gcc.br_real: error: 2: No such file or directory
> nios2-linux-gcc.br_real: error: 2: No such file or directory
>
> arc-linux-gcc.br_real: error: 2: No such file or directory
> arc-linux-gcc.br_real: error: 2: No such file or directory
> arc-linux-gcc.br_real: error: 2: No such file or directory
>
> They are happening on two different machines. Not sure what's going on
> here :-/
>
>> powerpc | dante-1.4.1 | NOK | http://autobuild.buildroot.net/results/313370bf05efe7fd87c281a97ecb6e06531a87ed/
>
> This last one would be fixed by applying
> https://patchwork.ozlabs.org/patch/656671/.
>
>> arm | ffmpeg-2.8.7 | NOK | http://autobuild.buildroot.net/results/ef579863ac7a4fb94827bfb7aeefdc5625b16676/
>
> Another: "Conflicting CPU architectures 13/1".
>
>> m68k | flickcurl-1.26 | NOK | http://autobuild.buildroot.net/results/c18eeb955a69b5a621eef5574df397f8de60d187/
>
> Another "relocation truncated to fit: R_68K_GOT16O" for Waldemar :)
>
>> arm | fwup-v0.8.0 | NOK | http://autobuild.buildroot.net/results/42f74ea254d5b3c1a2bca89913e805323bdf020b/
>
> Still the libintl/pthread issue.
>
>> powerpc | gadgetfs-test | NOK | http://autobuild.buildroot.net/results/2a935b7bcede2a12afdb836b7bc91a513825f39c/
>> powerpc | gadgetfs-test | NOK | http://autobuild.buildroot.net/results/fe0c97ee07354f831199f8d58e06e7bddccaba29/
>
> The infamous libaio problem...
>
>> arm | gst1-imx-0.12.2 | NOK | http://autobuild.buildroot.net/results/b460a770c8f4e992d29dde8fe37fc23a949937f2/
>
> error: 'V4L2_PIX_FMT_XRGB555X' undeclared (first use in this function)
>
> and other errors. We use kernel headers 4.7 since recently. Maybe
> there's something to fix here?
>
> Gary, can you have a look?
>
>> arm | host-efl-1.17.2 | NOK | http://autobuild.buildroot.net/results/89bf12f8333d47af0cb5775c859e26f300af56cc/
>
> edje_cc: Critical. Unable to open temp file "(null)" for pre-processor.
>
> Romain? This looks like a transient error, but I'm not sure.
>
>> arc | host-gcc-final-arc-2016.09-... | NOK | http://autobuild.buildroot.net/results/55592cb7c04687f3b73fae865bc5d745f1688f31/
>
> Investigated by the Synopsys people.
>
>> microblazeel | host-gdb-6be65fb56ea6694a92... | NOK | http://autobuild.buildroot.net/results/c3f724afbf79434864be7901dadaf6d848edefea/
>
> make[4]: *** No rule to make target `../sim/microblaze/libsim.a', needed by `gdb'. Stop.
> make[4]: *** Waiting for unfinished jobs....
>
> Yet another case of GDB Simulator build failure :-/ Waldemar ?
>
>> xtensa | jack2-v1.9.10 | NOK | http://autobuild.buildroot.net/results/3f5f885d5ccf84d634d9d483ff35a7757996cec4/
>
> ../dbus/sigsegv.c:110:20: error: 'NGREG' undeclared (first use in this function)
> for(i = 0; i < NGREG; i++)
>
>> arm | jack2-v1.9.10 | NOK | http://autobuild.buildroot.net/results/b8570a3e597384fd48e50b000ee760ad12945fa9/
>
> error: narrowing conversion of '-1' from 'int' to 'jack_nframes_t {aka unsigned int}' inside { } [-Wnarrowing]
>
> gcc 6.x issue?
>
>> i586 | kismet-Kismet-2014-02-R1 | NOK | http://autobuild.buildroot.net/results/461415e9b8de7ae4d8fcc2d11c6384be665b1f4e/
>
> musl header problem.
>
>> arm | kmsxx-a706f157b86e906968080... | NOK | http://autobuild.buildroot.net/results/1f005c46b927fbeeffb11d843c2c3f18308bb5b9/
>
> Lots and lots of errors. Maxime, Yann, any idea?
>
>> arm | lftp-4.7.3 | NOK | http://autobuild.buildroot.net/results/fa48dfa0034dd75588132f342bfd44a87d440c93/
>> mips64el | lftp-4.7.3 | NOK | http://autobuild.buildroot.net/results/77a9365c1f6cc205ed11d614b331a6a809aef55d/
>
> Would be fixed by https://patchwork.ozlabs.org/patch/656893/.
>
>> bfin | libarchive-3.2.1 | NOK | http://autobuild.buildroot.net/results/01b7088a06e7310c8773e78e8be4f6e88da67357/
>
> Static linking against pthread.
>
>> aarch64 | libepoxy-v1.3.1 | NOK | http://autobuild.buildroot.net/results/afbb24414340307617e88f26d1e82be672baf317/
>
> error: conflicting types for 'khronos_uint64_t'
>
> Gustavo, could you have a look?
>
>> arm | libsidplay2-2.1.1 | NOK | http://autobuild.buildroot.net/results/4f57a7a37da0ce6d14a368272d982b4874a54927/
>
> xsid.cpp:101:1: error: narrowing conversion of ''\200'' from 'char' to 'int8_t {aka signed char}' inside { } [-Wnarrowing]
> };
> ^
> xsid.cpp:101:1: error: narrowing conversion of ''\224'' from 'char' to 'int8_t {aka signed char}' inside { } [-Wnarrowing]
> xsid.cpp:101:1: error: narrowing conversion of ''\251'' from 'char' to 'int8_t {aka signed char}' inside { } [-Wnarrowing]
> xsid.cpp:101:1: error: narrowing conversion of ''\274'' from 'char' to 'int8_t {aka signed char}' inside { } [-Wnarrowing]
> xsid.cpp:101:1: error: narrowing conversion of ''\316'' from 'char' to 'int8_t {aka signed char}' inside { } [-Wnarrowing]
> xsid.cpp:101:1: error: narrowing conversion of ''\341'' from 'char' to 'int8_t {aka signed char}' inside { } [-Wnarrowing]
> xsid.cpp:101:1: error: narrowing conversion of ''\362'' from 'char' to 'int8_t {aka signed char}' inside { } [-Wnarrowing]
>
> gcc 6.x issue ?
>
> Bernd, you added this package, could you have a look?
>
>> arm | libsigsegv-2.10 | NOK | http://autobuild.buildroot.net/results/b1e40b3ec64cd98b535d83e89e5780c46680e095/
>
> Would be fixed by https://patchwork.ozlabs.org/patch/656693/.
>
>> arm | libxmlrpc-1.25.30 | NOK | http://autobuild.buildroot.net/results/832a9feb9561eae1239689a36c57bd0065f98e0d/
>
> base64.cpp:26:1: error: narrowing conversion of '-1' from 'int' to 'char' inside { } [-Wnarrowing]
>
> Another one.
>
>> i586 | linux-zigbee-v0.3.1 | NOK | http://autobuild.buildroot.net/results/5d56f998b5c5ab9e06cf048e6ec95b8671989cef/
>> arm | linux-zigbee-v0.3.1 | NOK | http://autobuild.buildroot.net/results/15033e9cdb1ecb23c0228c306236aca64c01303c/
>
> Would both be fixed by https://patchwork.ozlabs.org/patch/656730/.
>
>> i686 | lirc-tools-0.9.4 | NOK | http://autobuild.buildroot.net/results/c8db62509f77906b3bad5b2d58c2c02f95edf104/
>> sh4a | lirc-tools-0.9.4 | NOK | http://autobuild.buildroot.net/results/8545b910fe16e9fec038d2609a2071346b6cdb79/
>
> lircd.o: In function `schedule_repeat_timer(timespec*)':
> lircd.cpp:(.text+0x470): undefined reference to `clock_gettime'
> lircd.o: In function `dosigalrm(int)':
> lircd.cpp:(.text+0x24dd): undefined reference to `clock_gettime'
> lircd.o: In function `send_core(int, char*, char*, int)':
> lircd.cpp:(.text+0x295f): undefined reference to `clock_gettime'
>
> Need to link against librt.
>
>> x86_64 | lshw-B.02.18 | NOK | http://autobuild.buildroot.net/results/576eccb104ff23e60bfa9d15ce5bf8cab064a64f/
>
> Would be fixed by https://patchwork.ozlabs.org/patch/655854/.
>
>> x86_64 | lvm2-2.02.162 | NOK | http://autobuild.buildroot.net/results/c32851d3497b296904793c7d9af20cc8eb655a27/
>
> error: assignment of read-only variable 'stdin'
>
> musl-related.
>
>> arc | make[1]: *** Waiting for un... | TIM | http://autobuild.buildroot.net/results/1f049e02d1f2f9e1b6ce85ed8bcf6c59976e8c17/
>
> Ignore.
>
>> mipsel | mpd-0.19.17 | NOK | http://autobuild.buildroot.net/results/3605750023267e4cd35d98451bd283f9e70a6106/
>
> Static linking against OpenSSL ?
>
>> sparc | mpv-0.18.1 | NOK | http://autobuild.buildroot.net/results/f607eed9a48c4ca00db43f9d2652e615b4bd7c93/
>> sparc | mpv-0.18.1 | NOK | http://autobuild.buildroot.net/results/8e9c05b03e59b9b4d0b7b587e6ddc864acca28b1/
>> sparc | mpv-0.18.1 | NOK | http://autobuild.buildroot.net/results/422c5eb3fac8c68e45c7087af8e0b06d25898f2e/
>
> Would all three be fixed by https://patchwork.ozlabs.org/patch/657017/.
>
>> bfin | mtd-1.5.2 | NOK | http://autobuild.buildroot.net/results/edfd56d95e1338ff0ec20ad92d740f4fd77aaecc/
>
> integck.c: In function 'parse_mount_options':
> integck.c:2889: error: 'MS_DIRSYNC' undeclared (first use in this function)
> integck.c:2889: error: (Each undeclared identifier is reported only once
> integck.c:2889: error: for each function it appears in.)
> integck.c:2899: error: 'MS_RELATIME' undeclared (first use in this function)
>
> This is with the old Blackfin toolchain.
>
>> x86_64 | netplug-1.2.9.2 | NOK | http://autobuild.buildroot.net/results/ad1ee46fa0250e005eb9b1b30427e1db81f04264/
>> x86_64 | netplug-1.2.9.2 | NOK | http://autobuild.buildroot.net/results/7912ec10153e158e1671dbcd8b530aff9c31cbde/
>
> Fixed by
> https://git.buildroot.org/buildroot/commit/?id=225e1681cc000d904e5e98a3fcff974aac4e8d71.
>
>> x86_64 | ntfs-3g-2016.2.22 | NOK | http://autobuild.buildroot.net/results/a4387751d8b17ef0ef86ae04bdd4f4e13c13978d/
>
> fusermount.c: In function 'count_fuse_fs':
> fusermount.c:172:24: error: '_PATH_MOUNTED' undeclared (first use in this function)
> const char *mtab = _PATH_MOUNTED;
>
> musl issue, it seems.
>
>> bfin | ntp-4.2.8p8 | NOK | http://autobuild.buildroot.net/results/3df650e7a513f46cc948f350863414f43b5e3a89/
>
> multiple definition of `___GI_raise'
>
> Issue with the old Blackfin toolchain. It reminds me of something, but
> I can't remember if we had a solution or not.
>
>> arm | openblas-f04af36ad0e85b64f1... | NOK | http://autobuild.buildroot.net/results/bb51df385961d9f489e7a4f582cee8662e715897/
>> arm | openblas-f04af36ad0e85b64f1... | NOK | http://autobuild.buildroot.net/results/88362649ac5cd71918092a511a10f460535abb3e/
>> arm | openblas-f04af36ad0e85b64f1... | NOK | http://autobuild.buildroot.net/results/3047169caf157796854b9095d8ec1b9abd104260/
>
> Would be fixed by https://patchwork.ozlabs.org/patch/656508/.
>
>> microblazeel | openipmi-2.0.21 | NOK | http://autobuild.buildroot.net/results/fc4084f8d1ff3fe98066c7cc051c2127bbe77ec5/
>
> ./.libs/libOpenIPMIpthread.so: undefined reference to `pthread_condattr_setclock'
>
> Needs NPTL dependency.
>
>> x86_64 | openswan-2.6.46 | NOK | http://autobuild.buildroot.net/results/6b73c1d1bfd4b2f9db8c4b92747bcc2cd6f30a9e/
>
> fatal error: sys/cdefs.h: No such file or directory
>
> musl issue.
>
>> bfin | owfs-3.1p1 | NOK | http://autobuild.buildroot.net/results/b3529e5661c55c53074d85cb6bde28cb51b913ca/
>
> Fixed by disabling PHP support (I believe).
>
>> arm | php-7.0.9 | NOK | http://autobuild.buildroot.net/results/885f418cc26c6832a8a9abf703aecbeea8fbe550/
>
> Would be fixed by https://patchwork.ozlabs.org/patch/657181/.
>
>> mips64el | pinentry-0.9.4 | NOK | http://autobuild.buildroot.net/results/f73a28583d56a29a419f4f861135dd7548e88e3b/
>
> Some crazy C++ error. Anyone to look into this?
>
>> x86_64 | pinentry-0.9.4 | NOK | http://autobuild.buildroot.net/results/3dd54c594ee0521a10a057094e342500b4657cea/
>
> Same crazy C++ error.
>
>> sparc64 | qt5base-5.6.1-1 | NOK | http://autobuild.buildroot.net/results/bc4ceb53fff7b3f78e544c8fbeb7b549b7881dba/
>
> Project ERROR: libudev development package not found
> KMS disabled.
> KMS support cannot be enabled due to functionality tests!
> Turn on verbose messaging (-v) to ./configure to see the final report.
> If you believe this message is in error you may use the continue
> switch (-continue) to ./configure to continue.
>
> Hum, not sure here.
>
>> i586 | rpcbind-0.2.3 | NOK | http://autobuild.buildroot.net/results/2285b15f0c89ecf7c37876987a24d30a96cc2c67/
>> arm | rpcbind-0.2.3 | NOK | http://autobuild.buildroot.net/results/176adc06dff2393ec32630bb2bb354fbff06eab1/
>
> Musl issue.
>
>> bfin | snmppp-3.3.5 | NOK | http://autobuild.buildroot.net/results/a1888998291b08bd32f8c968572620748921017a/
>> bfin | snmppp-3.3.5 | NOK | http://autobuild.buildroot.net/results/3c755158e94865312b42384f2a152f30b4a28c7d/
>
> Blackfin C++ problem.
>
>> microblazeel | squeezelite-v1.8 | NOK | http://autobuild.buildroot.net/results/2a27e11ac01d4a9de01fb684b1f28c07c7fe6830/
>
> squeezelite.h:248:121: error: 'PTHREAD_PRIO_INHERIT' undeclared (first use in this function)
>
>> m68k | squeezelite-v1.8 | NOK | http://autobuild.buildroot.net/results/095642dd43a708bb3283ab6150c016344df3f84d/
>
> Ditto. Priority inheritance mutexes are only available for NPTL, it seems.
>
>> arc | stella-4.7.2 | NOK | http://autobuild.buildroot.net/results/5deb954dbaa436c335ebe873e53ac03685e83e1e/
>
> For some reason, it's using the host compiler :-/
>
>> sparc64 | supertuxkart-0.9.2 | NOK | http://autobuild.buildroot.net/results/7ae73f52589693a082a85967d77fc03a86f172bd/
>
> as_callfunc_x64_gcc.cpp:162:82: error: unknown register name '%r15' in 'asm'
>
> Seems like it's using some x86_64 code on Sparc64. Ezequiel, could you
> have a look?
>
Same report in Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830748
Seems angelscript build is not clever enough, and I'm guessing
this issue will happen on other non-x86 arches. Maybe cross-building
is completely broken?
--
Ezequiel Garc?a, VanguardiaSur
www.vanguardiasur.com.ar
^ permalink raw reply [flat|nested] 15+ messages in thread* [Buildroot] Analysis of build results for 2016-08-08
2016-08-09 12:15 ` [Buildroot] Analysis of build " Thomas Petazzoni
2016-08-09 12:25 ` Gary Bisson
2016-08-09 13:27 ` Ezequiel Garcia
@ 2016-08-09 14:07 ` Romain Naour
2016-08-22 19:49 ` Romain Naour
2016-08-09 17:58 ` Yann E. MORIN
3 siblings, 1 reply; 15+ messages in thread
From: Romain Naour @ 2016-08-09 14:07 UTC (permalink / raw)
To: buildroot
Hi Thomas, All,
Le 09/08/2016 ? 14:15, Thomas Petazzoni a ?crit :
> Hello,
>
> On Tue, 9 Aug 2016 08:30:32 +0200 (CEST), Thomas Petazzoni wrote:
>
[snip]
>
>> arm | host-efl-1.17.2 | NOK | http://autobuild.buildroot.net/results/89bf12f8333d47af0cb5775c859e26f300af56cc/
>
> edje_cc: Critical. Unable to open temp file "(null)" for pre-processor.
>
> Romain? This looks like a transient error, but I'm not sure.
I already seen this issue on autobuilders but I'm not able to reproduce it
locally...
>
>> microblazeel | host-gdb-6be65fb56ea6694a92... | NOK | http://autobuild.buildroot.net/results/c3f724afbf79434864be7901dadaf6d848edefea/
>
> make[4]: *** No rule to make target `../sim/microblaze/libsim.a', needed by `gdb'. Stop.
> make[4]: *** Waiting for unfinished jobs....
>
> Yet another case of GDB Simulator build failure :-/ Waldemar ?
I'm not sure the GDB Simulator for microblaze really build/work. We use the
Xilinx fork which provide a pretty old version (7.5 or 7.6).
>
>> x86_64 | lshw-B.02.18 | NOK | http://autobuild.buildroot.net/results/576eccb104ff23e60bfa9d15ce5bf8cab064a64f/
>
> Would be fixed by https://patchwork.ozlabs.org/patch/655854/.
As pointed out by Khem Raj, we should be careful with this patch. In doubt
disable lshw for musl.
>
>> x86_64 | lvm2-2.02.162 | NOK | http://autobuild.buildroot.net/results/c32851d3497b296904793c7d9af20cc8eb655a27/
>
> error: assignment of read-only variable 'stdin'
>
> musl-related.
The issue has already been reported upstream by Brendan Heading and nothing
happened to fix it.
https://www.redhat.com/archives/linux-lvm/2016-February/msg00027.html
>
>> nios2 | tftpd-5.2 | NOK | http://autobuild.buildroot.net/results/3117e3f39cd0b72a9a5d177091e9bbbd3e631363/
>
> tftpd.c:(.text.startup+0x5c): warning: Unable to reach (null) (at 0x00000000) from the global pointer (at 0x00011a80) because the offset (-72320) is out of the allowed range, -32678 to 32767.
>
> Romain, is this a known NIOSII toolchain issue?
Humm, not sure. It remind me an old nios2 issue, maybe the gcc compiler require
a backported patch ?
[snip]
Best regards,
Romain
>
> Thomas
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] Analysis of build results for 2016-08-08
2016-08-09 14:07 ` Romain Naour
@ 2016-08-22 19:49 ` Romain Naour
2016-08-25 7:29 ` Julien Boibessot
0 siblings, 1 reply; 15+ messages in thread
From: Romain Naour @ 2016-08-22 19:49 UTC (permalink / raw)
To: buildroot
Hi Julien, Thomas,
Le 09/08/2016 ? 16:07, Romain Naour a ?crit :
> Hi Thomas, All,
>
> [snip]
>
>>> arm | host-efl-1.17.2 | NOK | http://autobuild.buildroot.net/results/89bf12f8333d47af0cb5775c859e26f300af56cc/
>>
>> edje_cc: Critical. Unable to open temp file "(null)" for pre-processor.
>>
>> Romain? This looks like a transient error, but I'm not sure.
>
> I already seen this issue on autobuilders but I'm not able to reproduce it
> locally...
Julien, this issue occurs only on your autobuilder, can you verify if it
reproducible. If yes, can you send me the usual files log (config.log, build log
etc)
http://autobuild.buildroot.net/?reason=host-efl-1.17.2
Best regards,
Romain
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] Analysis of build results for 2016-08-08
2016-08-22 19:49 ` Romain Naour
@ 2016-08-25 7:29 ` Julien Boibessot
2016-08-25 22:37 ` Arnout Vandecappelle
[not found] ` <975a1c39-2a4d-164c-411b-8357601b570f@essensium.com>
0 siblings, 2 replies; 15+ messages in thread
From: Julien Boibessot @ 2016-08-25 7:29 UTC (permalink / raw)
To: buildroot
Hello Romain,
On 22/08/2016 21:49, Romain Naour wrote:
> Hi Julien, Thomas,
>
> Le 09/08/2016 ? 16:07, Romain Naour a ?crit :
>> Hi Thomas, All,
>>
>> [snip]
>>
>>>> arm | host-efl-1.17.2 | NOK | http://autobuild.buildroot.net/results/89bf12f8333d47af0cb5775c859e26f300af56cc/
>>> edje_cc: Critical. Unable to open temp file "(null)" for pre-processor.
>>>
>>> Romain? This looks like a transient error, but I'm not sure.
>> I already seen this issue on autobuilders but I'm not able to reproduce it
>> locally...
> Julien, this issue occurs only on your autobuilder, can you verify if it
> reproducible. If yes, can you send me the usual files log (config.log, build log
> etc)
yes, it's 100% reproducible.
Best regards,
Julien
^ permalink raw reply [flat|nested] 15+ messages in thread* [Buildroot] Analysis of build results for 2016-08-08
2016-08-25 7:29 ` Julien Boibessot
@ 2016-08-25 22:37 ` Arnout Vandecappelle
2016-09-03 15:05 ` Julien Boibessot
[not found] ` <975a1c39-2a4d-164c-411b-8357601b570f@essensium.com>
1 sibling, 1 reply; 15+ messages in thread
From: Arnout Vandecappelle @ 2016-08-25 22:37 UTC (permalink / raw)
To: buildroot
On 25-08-16 09:29, Julien Boibessot wrote:
> Hello Romain,
>
> On 22/08/2016 21:49, Romain Naour wrote:
>> Hi Julien, Thomas,
>>
>> Le 09/08/2016 ? 16:07, Romain Naour a ?crit :
>>> Hi Thomas, All,
>>>
>>> [snip]
>>>
>>>>> arm | host-efl-1.17.2 | NOK | http://autobuild.buildroot.net/results/89bf12f8333d47af0cb5775c859e26f300af56cc/
>>>> edje_cc: Critical. Unable to open temp file "(null)" for pre-processor.
>>>>
>>>> Romain? This looks like a transient error, but I'm not sure.
>>> I already seen this issue on autobuilders but I'm not able to reproduce it
>>> locally...
>> Julien, this issue occurs only on your autobuilder, can you verify if it
>> reproducible. If yes, can you send me the usual files log (config.log, build log
>> etc)
> yes, it's 100% reproducible.
Looking at the source of edje_cc, it's mkstemp() that fails. Do you have TMPDIR
or XDG_RUNTIME_DIR pointing to some location that is not writable or doesn't exist?
Regards,
Arnout
--
.signature.html
Arnout Vandecappelle arnout dot vandecappelle at essensium dot com
Senior Embedded Software Architect . . . . . . +32-478-010353 (mobile)
Essensium, Mind division . . . . . . . . . . . . . . http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium . . . . . BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 15+ messages in thread* [Buildroot] Analysis of build results for 2016-08-08
2016-08-25 22:37 ` Arnout Vandecappelle
@ 2016-09-03 15:05 ` Julien Boibessot
2016-09-05 8:14 ` Arnout Vandecappelle
0 siblings, 1 reply; 15+ messages in thread
From: Julien Boibessot @ 2016-09-03 15:05 UTC (permalink / raw)
To: buildroot
Hello,
Arnout,
On 26/08/2016 00:37, Arnout Vandecappelle wrote:
> On 25-08-16 09:29, Julien Boibessot wrote:
>> Hello Romain,
>>
>> On 22/08/2016 21:49, Romain Naour wrote:
>>> Hi Julien, Thomas,
>>>
>>> Le 09/08/2016 ? 16:07, Romain Naour a ?crit :
>>>> Hi Thomas, All,
>>>>
>>>> [snip]
>>>>
>>>>>> arm | host-efl-1.17.2 | NOK | http://autobuild.buildroot.net/results/89bf12f8333d47af0cb5775c859e26f300af56cc/
>>>>> edje_cc: Critical. Unable to open temp file "(null)" for pre-processor.
>>>>>
>>>>> Romain? This looks like a transient error, but I'm not sure.
>>>> I already seen this issue on autobuilders but I'm not able to reproduce it
>>>> locally...
>>> Julien, this issue occurs only on your autobuilder, can you verify if it
>>> reproducible. If yes, can you send me the usual files log (config.log, build log
>>> etc)
>> yes, it's 100% reproducible.
> Looking at the source of edje_cc, it's mkstemp() that fails. Do you have TMPDIR
> or XDG_RUNTIME_DIR pointing to some location that is not writable or doesn't exist?
XDG_RUNTIME_DIR is indeed pointing to a directory that is not writable
for user launching the build.
export XDG_RUNTIME_DIR=/tmp fixes the host-efl build.
Where should I set this envt variable ?
(Build is launched through ssh+su on my build server)
Regards,
Julien
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] Analysis of build results for 2016-08-08
2016-09-03 15:05 ` Julien Boibessot
@ 2016-09-05 8:14 ` Arnout Vandecappelle
2016-09-05 9:15 ` Yann E. MORIN
0 siblings, 1 reply; 15+ messages in thread
From: Arnout Vandecappelle @ 2016-09-05 8:14 UTC (permalink / raw)
To: buildroot
On 03-09-16 17:05, Julien Boibessot wrote:
> Hello,
>
> Arnout,
>
> On 26/08/2016 00:37, Arnout Vandecappelle wrote:
[snip]
>> Looking at the source of edje_cc, it's mkstemp() that fails. Do you have TMPDIR
>> or XDG_RUNTIME_DIR pointing to some location that is not writable or doesn't exist?
>
> XDG_RUNTIME_DIR is indeed pointing to a directory that is not writable
> for user launching the build.
> export XDG_RUNTIME_DIR=/tmp fixes the host-efl build.
> Where should I set this envt variable ?
>
> (Build is launched through ssh+su on my build server)
I guess you should unset XDG_RUNTIME_DIR somewhere in that script :-) Or maybe
buildroot-test should do that? AFAICS it currently doesn't do any environment
cleanups, but maybe it should?
Regards,
Arnout
>
> Regards,
> Julien
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] Analysis of build results for 2016-08-08
2016-09-05 8:14 ` Arnout Vandecappelle
@ 2016-09-05 9:15 ` Yann E. MORIN
0 siblings, 0 replies; 15+ messages in thread
From: Yann E. MORIN @ 2016-09-05 9:15 UTC (permalink / raw)
To: buildroot
Julien, All,
On 2016-09-05 10:14 +0200, Arnout Vandecappelle spake thusly:
> On 03-09-16 17:05, Julien Boibessot wrote:
> > On 26/08/2016 00:37, Arnout Vandecappelle wrote:
> [snip]
> >> Looking at the source of edje_cc, it's mkstemp() that fails. Do you have TMPDIR
> >> or XDG_RUNTIME_DIR pointing to some location that is not writable or doesn't exist?
> >
> > XDG_RUNTIME_DIR is indeed pointing to a directory that is not writable
> > for user launching the build.
> > export XDG_RUNTIME_DIR=/tmp fixes the host-efl build.
> > Where should I set this envt variable ?
> >
> > (Build is launched through ssh+su on my build server)
>
> I guess you should unset XDG_RUNTIME_DIR somewhere in that script :-)
Most probably, use 'su -', instead of just 'su', so that the environment
from the calling user is reset.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <975a1c39-2a4d-164c-411b-8357601b570f@essensium.com>]
* [Buildroot] Analysis of build results for 2016-08-08
[not found] ` <975a1c39-2a4d-164c-411b-8357601b570f@essensium.com>
@ 2016-08-26 21:29 ` Romain Naour
0 siblings, 0 replies; 15+ messages in thread
From: Romain Naour @ 2016-08-26 21:29 UTC (permalink / raw)
To: buildroot
Hi Arnout, All,
Le 25/08/2016 ? 23:52, Arnout Vandecappelle a ?crit :
> On 25-08-16 09:29, Julien Boibessot wrote:
>> Hello Romain,
>>
>> On 22/08/2016 21:49, Romain Naour wrote:
>>> Hi Julien, Thomas,
>>>
>>> Le 09/08/2016 ? 16:07, Romain Naour a ?crit :
>>>> Hi Thomas, All,
>>>>
>>>> [snip]
>>>>
>>>>>> arm | host-efl-1.17.2 | NOK | http://autobuild.buildroot.net/results/89bf12f8333d47af0cb5775c859e26f300af56cc/
>>>>> edje_cc: Critical. Unable to open temp file "(null)" for pre-processor.
>>>>>
>>>>> Romain? This looks like a transient error, but I'm not sure.
>>>> I already seen this issue on autobuilders but I'm not able to reproduce it
>>>> locally...
>>> Julien, this issue occurs only on your autobuilder, can you verify if it
>>> reproducible. If yes, can you send me the usual files log (config.log, build log
>>> etc)
>> yes, it's 100% reproducible.
>
> Looking at the source of edje_cc, it's mkstemp() that fails. Do you have TMPDIR
> or XDG_RUNTIME_DIR pointing to some location that is not writable or doesn't exist?
Thanks for the investigation.
I came to the same conclusion that mkstemp() (eina_file_mkstemp) fails for some
reason on Julien's autobuilders... without any clue.
Best regards,
Romain
>
>
> Regards,
> Arnout
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] Analysis of build results for 2016-08-08
2016-08-09 12:15 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (2 preceding siblings ...)
2016-08-09 14:07 ` Romain Naour
@ 2016-08-09 17:58 ` Yann E. MORIN
2016-08-09 21:23 ` Yann E. MORIN
3 siblings, 1 reply; 15+ messages in thread
From: Yann E. MORIN @ 2016-08-09 17:58 UTC (permalink / raw)
To: buildroot
Thomas, All,
On 2016-08-09 14:15 +0200, Thomas Petazzoni spake thusly:
> > arm | kmsxx-a706f157b86e906968080... | NOK | http://autobuild.buildroot.net/results/1f005c46b927fbeeffb11d843c2c3f18308bb5b9/
> Lots and lots of errors. Maxime, Yann, any idea?
This is a static build, so it looks like it is missign a library to
link to. I've started a build here to investigate a bit more...
> > arm | systemd-231 | NOK | http://autobuild.buildroot.net/results/3bba46b91e6c2a2c5a8c7e0739ccf0b3d8efadff/
> src/import/export-raw.c: In function 'reflink_snapshot':
> src/import/export-raw.c:271:26: error: 'O_TMPFILE' undeclared (first use in this function)
> new_fd = open(d, O_TMPFILE|O_CLOEXEC|O_NOCTTY|O_RDWR, 0600);
> ^
> Yann, Maxime, you are our systemd people, could you have a look?
I already sent two "fixes" for that:
http://lists.busybox.net/pipermail/buildroot/2016-July/167292.html
http://lists.busybox.net/pipermail/buildroot/2016-July/167296.html
Here it goes again:
- O_TMPFILE was added in kernel headers 3.11
- O_TMPFILE was added in glibc-2.18
However, even when the kernel headers are recent enough but glibc is
not, then O_TMPFILE is not available. One must have glibc >= 2.19;
having kernel headers older than 3.11 does not seem to be a problem:
http://lists.busybox.net/pipermail/buildroot/2016-July/167793.html
The toolchain is the codesourcery ARM 2014.05 which is using kernel
headers 3.13 (OK) but a glibc-2.18 (not OK).
Since we do not have symbols with the version of the C library, we can't
have systemd hidden whn glibc is "too old".
Except for that second patch of mine, above, which just hid systemd for
this toolchain, I don;t see what we could do, baring adding AT_LEAST_X_Y
symbols for glibc...
> > nios2 | weston-1.11.0 | NOK | http://autobuild.buildroot.net/results/f49a9cbb7bdc5d9e05dcf0a20bd83f059e234e74/
> src/compositor-rdp.c:875:2: error: stray '\302' in program
I've had a look at the code, and indeed there is a "non-breakable space"
which is U8+C2A0 (U+A0) in the definition of the NSC_RESET macro on line
61 for the RDP compositor.
I'll send a patch upstream tonight.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 15+ messages in thread* [Buildroot] Analysis of build results for 2016-08-08
2016-08-09 17:58 ` Yann E. MORIN
@ 2016-08-09 21:23 ` Yann E. MORIN
0 siblings, 0 replies; 15+ messages in thread
From: Yann E. MORIN @ 2016-08-09 21:23 UTC (permalink / raw)
To: buildroot
Thomas, Maxime, All,
On 2016-08-09 19:58 +0200, Yann E. MORIN spake thusly:
> On 2016-08-09 14:15 +0200, Thomas Petazzoni spake thusly:
> > > arm | kmsxx-a706f157b86e906968080... | NOK | http://autobuild.buildroot.net/results/1f005c46b927fbeeffb11d843c2c3f18308bb5b9/
> > Lots and lots of errors. Maxime, Yann, any idea?
>
> This is a static build, so it looks like it is missign a library to
> link to. I've started a build here to investigate a bit more...
I am not able to reproduce this build failure... :-/
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 15+ messages in thread