Discussion:
[Buildroot] [autobuild.buildroot.net] Build results for 2016-01-21
Thomas Petazzoni
2016-01-22 07:30:21 UTC
Permalink
Build statistics for 2016-01-21
===============================

success : 241
failures : 132
timeouts : 4
TOTAL : 377

Classification of failures by reason
====================================

libv4l-1.8.1 | 50
boost-1.60.0 | 15
host-vboot-utils-bbdd62f9b0... | 9
ltp-testsuite-20150903 | 4
qt-4.8.7 | 4
lttng-tools-2.7.1 | 3
libdrm-2.4.66 | 2
mesa3d-11.1.1 | 2
host-gdb-6be65fb56ea6694a92... | 2
erlang-17.5 | 2
libsoil-20080707 | 2
libnss-3.21 | 2
mosh-1.2.5 | 2
ruby-2.3.0 | 2
bind-9.10.3-P2 | 2
make[2]: *** [Source/WebCor... | 1
imagemagick-6.9.2-10 | 1
rt-tests-v0.89 | 1
setools-3.3.8 | 1
host-efl-1.15.3 | 1
nfs-utils-1.3.3 | 1
pinentry-0.9.4 | 1
aumix-2.8 | 1
libcap-ng-0.7.4 | 1
iperf3-3.1 | 1
libubox-e88d816d6e462180f03... | 1
gdk-pixbuf-2.32.3 | 1
slang-2.3.0 | 1
gst1-libav-1.6.3 | 1
iproute2-4.4.0 | 1
mplayer-1.2 | 1
webkitgtk24-2.4.9 | 1
madplay-0.15.2b | 1
strongswan-5.3.5 | 1
mp4v2-2.0.0 | 1
php-5.6.17 | 1
trousers-0.3.13 | 1
make[1]: *** Waiting for un... | 1
dvbsnoop-1.4.50 | 1
iucode-tool-1cbd73013cd4c6b... | 1
zxing-cpp-fa34227d26e0b388e... | 1
hidapi-d17db57b9d4354752e0a... | 1
stunnel-5.28 | 1
make[1]: *** [all] Terminated | 1
pptp-linux-1.8.0 | 1
qextserialport-ada321a9ee46... | 1
tar-1.28 | 1
sconeserver-3b886c3dda6eda3... | 1

Detail of failures
===================

arm | aumix-2.8 | NOK | http://autobuild.buildroot.net/results/c8c7f9a799d1af507a6edd5e02b0bbc8b7b5d068/
mipsel | bind-9.10.3-P2 | NOK | http://autobuild.buildroot.net/results/62f386829193c747176ace05e4b26826fcabbf59/
mips64el | bind-9.10.3-P2 | NOK | http://autobuild.buildroot.net/results/a92fa5dc5d9d6742d61d4d293f7eac97c5355dfe/
arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/c7d987a51f2b2b731fb60e0e741361bbfb4ff230/
x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/b2c860fc8fbc7a025bcd3c04e9b43b04f029ead3/
arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/5a33d69d2c11e3013b73b3f6c1d8ab3a31facf62/
arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/a7c7eb7c2f477f8a19c1b364f746dfd31bf18a3d/
arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/fb2f5cbe28a41161df7e3c5b2f6a36242daf5374/
xtensa | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/179345a92e0c1db1b8d5bccb27c6b93e484f9b6d/
i686 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/8612864811bbb04d655a6040869ccb81396d7737/
arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/51c54c85010c61245a4ef51d4e602974809d077f/
arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/e474243b83233c008fc2351c77eba35269e95439/
xtensa | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/30898a3c7a5fceb1bd14a287064b96e04fba7921/
microblazeel | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/d5d159dc004e28fed537b84fae76afb0734b2ec0/
microblazeel | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/71e9dbb63b91980723554651071fdc3d7a2250f2/
mips64el | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/3ee30fe28f709c63c9a0e2d0d91440d855ff73a9/
xtensa | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/c48523b0bc50c61a9dd1bb691cd3fe3b05fdc1a7/
sh4 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/04553f5d6b73b0a97901995674b0876c33d062f5/
arm | dvbsnoop-1.4.50 | NOK | http://autobuild.buildroot.net/results/be64a45ac158b9057fb3e7ef9b515250acc77187/
sparc | erlang-17.5 | NOK | http://autobuild.buildroot.net/results/20cd87c6a05c91ee223b813040d9d10fa923b174/
x86_64 | erlang-17.5 | NOK | http://autobuild.buildroot.net/results/e4ab3fa4a121f7d7edb0263f02aac2ee836905a7/
arm | gdk-pixbuf-2.32.3 | NOK | http://autobuild.buildroot.net/results/f271386d3cefad4a4971bc8698848b4563498e6b/
mips64el | gst1-libav-1.6.3 | NOK | http://autobuild.buildroot.net/results/1a0eb189ad91a7f2fb7285f4225555a0a0febda2/
xtensa | hidapi-d17db57b9d4354752e0a... | NOK | http://autobuild.buildroot.net/results/a5b0d3816953b5477d7938cf001fb048fee7462b/
arm | host-efl-1.15.3 | NOK | http://autobuild.buildroot.net/results/e178371c2c3bf42d59c6fc26409e098081239ccb/
microblazeel | host-gdb-6be65fb56ea6694a92... | NOK | http://autobuild.buildroot.net/results/d35f6ee7643a695af7db3739ff480d25b99ee051/
microblazeel | host-gdb-6be65fb56ea6694a92... | NOK | http://autobuild.buildroot.net/results/09f4a89e463b6ccbca01cce1d38eb849c17ed6e1/
nios2 | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/0e8d5ab5127b5e40c58912fe16504e3fcb941e69/
arm | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/10f61d4cc5f6fdac231185d577493e0e82c5d091/
microblazeel | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/bdcb9bbd7a07f0bde1b575bbf7ae88d006a1e823/
arm | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/a25de6a6e8d68fd86ebf2c5805c6fe31d5860656/
arm | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/f00e14e2360544ffe7501247dddfcb701631646d/
mips64el | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/95491e089e6e18bfddbf6d7d19450026e9a349f5/
mips64el | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/936d66543e2db55309af115ead64ded24f31661c/
arm | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/25409dfeb7ce5806115092eb341e201d680ab974/
bfin | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/1a45412939a3f9d6fa59d086d834a3b4a4bffef7/
nios2 | imagemagick-6.9.2-10 | NOK | http://autobuild.buildroot.net/results/0bf3a2a284b7d4712ab1530562d3b8164fc75e88/
arm | iperf3-3.1 | NOK | http://autobuild.buildroot.net/results/50e34db9e273ebb7b8a9198dec254f6b22e26eff/
x86_64 | iproute2-4.4.0 | NOK | http://autobuild.buildroot.net/results/d3d79b55cb19987d5d5c0da9c0f0d25697697c05/
x86_64 | iucode-tool-1cbd73013cd4c6b... | NOK | http://autobuild.buildroot.net/results/7f8626db69500a84a393053a485f04180c565673/
nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/183df75a853c3b0e2617c9219a356c5531aa523d/
x86_64 | libdrm-2.4.66 | NOK | http://autobuild.buildroot.net/results/7d444611f8efa40e0eb81ac88365416ef553fcd5/
x86_64 | libdrm-2.4.66 | NOK | http://autobuild.buildroot.net/results/6287fa5a754610f04f0df93bf611676d982f5cff/
powerpc | libnss-3.21 | NOK | http://autobuild.buildroot.net/results/cdae10070b9a97066dbfd0fb2c2004d9bd1fdd43/
powerpc | libnss-3.21 | NOK | http://autobuild.buildroot.net/results/0df8b1f78b671ff05b2ecbf9c4cf08b8898e2d43/
i686 | libsoil-20080707 | NOK | http://autobuild.buildroot.net/results/8ff91ab8e52000eb34dd8f662520cf1b31490cf5/
x86_64 | libsoil-20080707 | NOK | http://autobuild.buildroot.net/results/ea77d6b23aca0cb1cf527e6c16ddf5eba957a69c/
sparc | libubox-e88d816d6e462180f03... | NOK | http://autobuild.buildroot.net/results/4feaa9089ee9a183c5086b791bea35c0156945af/
mips64el | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/4d63874fe2efda8ac7aa3a8c82affa99f0ce5af0/
nios2 | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/00346ced295f481eca192668fd1f4958efa0e5a6/
mips64el | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/01d0608f4a7c83a289c74d30e54fbc4af989de31/
powerpc | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/005d3f3720682316de3db4fcddb8c49ec51997c7/
sparc64 | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/0cf734a5e0733fb139cca55f5ef176230c63b0f8/
nios2 | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/f7cbc43e0a42dc19070b38077078a6a488a6530b/
mips64el | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/ce684085a2222bd0db953f3ed3dc9955915f1237/
sparc64 | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/74257e93c05d6da09deaf995da3a1d8713ee80a1/
i686 | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/b8021fbf8128abc6a0babb12090c2b403b072e02/
mips64el | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/07dc750f77b75f261b16bed36483090a1ef6b070/
sparc | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/8c30bb8a459016db30ebb75c4dae817a78f0f7a4/
xtensa | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/e7a2341cbbcf514f4cd6754a5a36cebd6556a757/
arm | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/439dacf8fac84fc8ab2cb7252667c15b9bbb5bc2/
mips64el | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/7202c3f47f3ef8b6c2e62473bbb64fe765bf6a41/
powerpc | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/62a5d6a749f48ec48f25577b19f0132081d5f06a/
arc | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/696a93fb421f6ec53e5dffec7bb86fd8ab8fb45f/
arc | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/d6e3ae78a3d3e4ebe25fc1fd8d492984539eeea7/
mips64el | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/74d62b518180f55a6b35bbd3f4b7b476d344225b/
microblazeel | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/2e72a285d63a97ea12d20dbe42b6e52febb889fe/
powerpc | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/62ee62fbc8866a7150249a35f3ed3befa3381f33/
arm | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/6ad432608090c1c8ab9ca2e001a09dd11181a3df/
arc | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/f615149c40763fbf3168fd871c3073894b5f4e7d/
sh4a | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/96d3d2070de95cf1d440d9520b75109455354173/
sh4a | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/7f99bf2de6674666a4bee985d700f8cd37e0414d/
sh4 | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/dd9aa57ea24b3c8b894d30205cd4f796202382c0/
sparc | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/9571f6697bd6fd134534466fdd5349e16c5a7406/
powerpc | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/b8bfaffa92a6a392c7d3b584d1ffdac079bc1907/
arm | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/66972a4ae0aef21d29c3b0f1b7a1d286dd67518d/
sh4a | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/865b59935fb05ff77bd116703646b678c130c862/
microblazeel | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/befe0262424e7eef1406f1b55a3eeac2b31e5b32/
sparc64 | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/644b97921ad61ddece2be038cff3119b10a5682b/
nios2 | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/62c2644c5b5db7dc6c31c08137fa4a80ec95a840/
powerpc | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/01bbb4192d546b0939d5b98b334934da6b24adfe/
sh4 | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/f337e891a5a606223370401cec8ff14fca457447/
aarch64 | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/924b8e8622caf153040c3dab41f7a7830ad5c157/
i686 | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/5b6222653e86c75c7cb9fa3186e3bc0afa19e0e1/
powerpc | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/1d057d7f5304011f773d66282ee8fe2b1bf01c2f/
arm | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/301487b4e7aea85265261645e9dd6566659b16a5/
powerpc | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/3a23787919f72694287db4e062543eddabbb6f66/
sparc | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/8fbc2d7e4a9961e3db1f377d1c01d1f54885e30e/
xtensa | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/5de8deb2ee50756cc95c2e58fd606512da55c31c/
powerpc | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/e0d0304805208a968ff359d53ad48bc14134c14f/
powerpc | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/855fcb1ed9c290a19baeebd09e8dce9baf3e98e1/
powerpc | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/e6c48a60f923ea523fa461a44c85f5836a4dbb0e/
aarch64 | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/fb9337c8b0e7e120e2a58b4df4922669651aedef/
arm | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/f2cd64f147c15f7b9267c2208145b7041c6fb6c3/
mips | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/916de7078dd0661f9c761b0433c084f607f9fdb9/
sparc | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/eedb958d3ca7b4ad6a52c83bbd2edff7fdcb4957/
i686 | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/96be8ad4293c15b3cfdbae5a1ead7f428ce7c790/
powerpc | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/7ef60c5827b103d45cae17b3ef006a8a7757d1dd/
mips64el | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/3a2b141d90b28a2954fa0ad3104cba81d648d2a3/
mipsel | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/70aa227c8a289631c2973474cfaef5973756dd5c/
mips64el | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/2b8c777c76b7e5d5a426045f5a3872d6b71faa56/
mipsel | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/3f19dd459400ac7fca39e69dd280def6a547f8b6/
arm | lttng-tools-2.7.1 | NOK | http://autobuild.buildroot.net/results/b48bc7ad4bede4d16c079da0ae1121e6796a0e8d/
arm | lttng-tools-2.7.1 | NOK | http://autobuild.buildroot.net/results/25dcb19c3dd32e50990f9b45053d71ea18746a80/
arm | lttng-tools-2.7.1 | NOK | http://autobuild.buildroot.net/results/a3f93498811491d37ba13d024e33e68a8bc7ba18/
x86_64 | madplay-0.15.2b | NOK | http://autobuild.buildroot.net/results/2561190b274d71666c4bdf3c569b02063cefdb30/
arm | make[1]: *** Waiting for un... | TIM | http://autobuild.buildroot.net/results/bf11d5702a59b9271ae29ef76ff6e6218758f095/
x86_64 | make[1]: *** [all] Terminated | TIM | http://autobuild.buildroot.net/results/3ebffe635ce59552b3f682e433baf0e7f1fa68b2/
x86_64 | make[2]: *** [Source/WebCor... | TIM | http://autobuild.buildroot.net/results/64d3b6734da72d1d9f0f379db64ac31863f1f3de/
microblazeel | mesa3d-11.1.1 | NOK | http://autobuild.buildroot.net/results/0d71cd6edccd390106636cc0c4acfe5a8dca112a/
microblazeel | mesa3d-11.1.1 | NOK | http://autobuild.buildroot.net/results/6567477b87c081db97a9c2bf84af182a9a281193/
mipsel | mosh-1.2.5 | NOK | http://autobuild.buildroot.net/results/3f9443a76d2f8811720748b487e045eec23ec338/
mipsel | mosh-1.2.5 | NOK | http://autobuild.buildroot.net/results/104b8fae4ff5918353e0e6a7ac050e2f04d701c1/
xtensa | mp4v2-2.0.0 | NOK | http://autobuild.buildroot.net/results/bff7436a800eeea92c0c92bd2846b0f2b31947fd/
aarch64 | mplayer-1.2 | NOK | http://autobuild.buildroot.net/results/aadce770cf86ded813a78f936f0a6d4441845907/
powerpc | nfs-utils-1.3.3 | NOK | http://autobuild.buildroot.net/results/fe3be93988e585a84ae3116a0c327e1e2c95ad08/
arm | php-5.6.17 | NOK | http://autobuild.buildroot.net/results/0bbae90d05f14ac1fdbac7d8d69d4e6fd922e301/
arm | pinentry-0.9.4 | NOK | http://autobuild.buildroot.net/results/bd886cd10a8f52647296de2ff50270f25532756e/
arm | pptp-linux-1.8.0 | NOK | http://autobuild.buildroot.net/results/56dd530d53489220d0080480310b8dc150cf1b2e/
arc | qextserialport-ada321a9ee46... | NOK | http://autobuild.buildroot.net/results/d6565367f83cc845495e5e5f60935b71d04ef2da/
nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/aa1492777c5f60ab45921618f64910ca4d048e5f/
nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/a74810f0fce398c41fef11b8e2b8e1a52ffdb46a/
nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/cb70d195cf9b9b5ae09b83a40ef767cc8f699a9c/
arm | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/53e7e122e96b4b96c0f5feb4f26055b3f5ad8096/
arm | rt-tests-v0.89 | NOK | http://autobuild.buildroot.net/results/a6f6502e55fd68803f3ff8b4b76cce6601e101db/
bfin | ruby-2.3.0 | NOK | http://autobuild.buildroot.net/results/268d29bd910c17b1fccad5d13ce281238080efd2/
bfin | ruby-2.3.0 | NOK | http://autobuild.buildroot.net/results/1eb3d1ca20ce81fa2b10593d9393fb130558a706/
arm | sconeserver-3b886c3dda6eda3... | NOK | http://autobuild.buildroot.net/results/178bdfb062949fb10b9d6b9830975aa57702b3ae/
sparc64 | setools-3.3.8 | NOK | http://autobuild.buildroot.net/results/328192a8c561f3517bb0f9ebafb59d09e4f4b3ae/
mips64el | slang-2.3.0 | NOK | http://autobuild.buildroot.net/results/3c1fef2163b8a194ede70040da87af95bf5dc331/
arm | strongswan-5.3.5 | NOK | http://autobuild.buildroot.net/results/601d8dc1654d8733db49b195139e12437663034c/
mipsel | stunnel-5.28 | NOK | http://autobuild.buildroot.net/results/3448dc253a4a86450f15fb225374bd1e643dacd1/
arc | tar-1.28 | NOK | http://autobuild.buildroot.net/results/e9c5df490264a2d9ff5160187bda75431493d666/
arc | trousers-0.3.13 | NOK | http://autobuild.buildroot.net/results/7009e334e51adce37353c5d4f618fb28678f6114/
arm | webkitgtk24-2.4.9 | NOK | http://autobuild.buildroot.net/results/c660d29b0184daf7d16045b595e48d3c73ab521a/
x86_64 | zxing-cpp-fa34227d26e0b388e... | TIM | http://autobuild.buildroot.net/results/41ca3109600cb3e327f1b9a56556e49d3b405056/
--
http://autobuild.buildroot.net
Thomas Petazzoni
2016-01-22 09:29:57 UTC
Permalink
Hello,

Gustavo, Carsten, Frank, Vicente, Alan, Romain, Bernd, Thomas, Peter,
Max, Joao, Maxime, Sonic, Simon, Waldemar, please see below, there are
some questions for you. Thanks!
Post by Thomas Petazzoni
arm | aumix-2.8 | NOK | http://autobuild.buildroot.net/results/c8c7f9a799d1af507a6edd5e02b0bbc8b7b5d068/
gettext/libintl handling issue.
Post by Thomas Petazzoni
mipsel | bind-9.10.3-P2 | NOK | http://autobuild.buildroot.net/results/62f386829193c747176ace05e4b26826fcabbf59/
mips64el | bind-9.10.3-P2 | NOK | http://autobuild.buildroot.net/results/a92fa5dc5d9d6742d61d4d293f7eac97c5355dfe/
rbt.c:116:15: error: two or more data types in declaration specifiers
isc_uint32_t ptrsize;
^
rbt.c:116:22: error: expected identifier or '(' before ';' token
isc_uint32_t ptrsize;

Gustavo, can you have a look ? I think this error already popped up in the past, no?
Post by Thomas Petazzoni
arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/c7d987a51f2b2b731fb60e0e741361bbfb4ff230/
x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/b2c860fc8fbc7a025bcd3c04e9b43b04f029ead3/
arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/5a33d69d2c11e3013b73b3f6c1d8ab3a31facf62/
arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/a7c7eb7c2f477f8a19c1b364f746dfd31bf18a3d/
arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/fb2f5cbe28a41161df7e3c5b2f6a36242daf5374/
xtensa | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/179345a92e0c1db1b8d5bccb27c6b93e484f9b6d/
i686 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/8612864811bbb04d655a6040869ccb81396d7737/
arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/51c54c85010c61245a4ef51d4e602974809d077f/
arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/e474243b83233c008fc2351c77eba35269e95439/
xtensa | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/30898a3c7a5fceb1bd14a287064b96e04fba7921/
microblazeel | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/d5d159dc004e28fed537b84fae76afb0734b2ec0/
microblazeel | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/71e9dbb63b91980723554651071fdc3d7a2250f2/
mips64el | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/3ee30fe28f709c63c9a0e2d0d91440d855ff73a9/
xtensa | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/c48523b0bc50c61a9dd1bb691cd3fe3b05fdc1a7/
sh4 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/04553f5d6b73b0a97901995674b0876c33d062f5/
The FE_* issue. I tried to have a look at the other day. It seems like
the Boost code does check for FE_*, but it does by running tests with
the host compiler... So it concludes that fenv.h support is OK, but
then it really builds with the target compiler and fails. But the boost
build system is so... that I'm not even sure.
Post by Thomas Petazzoni
arm | dvbsnoop-1.4.50 | NOK | http://autobuild.buildroot.net/results/be64a45ac158b9057fb3e7ef9b515250acc77187/
Still the u_long problem. Carsten ?
Post by Thomas Petazzoni
sparc | erlang-17.5 | NOK | http://autobuild.buildroot.net/results/20cd87c6a05c91ee223b813040d9d10fa923b174/
libatomic_ops not usable. Probably need to disable erlang on Sparc and
be done with it?
Post by Thomas Petazzoni
x86_64 | erlang-17.5 | NOK | http://autobuild.buildroot.net/results/e4ab3fa4a121f7d7edb0263f02aac2ee836905a7/
sys/common/erl_poll.c: In function 'update_pollset':
sys/common/erl_poll.h:132:5: error: '__uint32_t' undeclared (first use in this function)
((__uint32_t) (EV))
^
sys/common/erl_poll.c:1150:24: note: in expansion of macro 'ERTS_POLL_EV_E2N'
epe_templ.events = ERTS_POLL_EV_E2N(ps->fds_status[fd].events);
^
sys/common/erl_poll.h:132:5: note: each undeclared identifier is reported only once for each function it appears in
((__uint32_t) (EV))
^
sys/common/erl_poll.c:1150:24: note: in expansion of macro 'ERTS_POLL_EV_E2N'
epe_templ.events = ERTS_POLL_EV_E2N(ps->fds_status[fd].events);
^

Musl build issue. Frank, can you have a look at this one ?
Post by Thomas Petazzoni
arm | gdk-pixbuf-2.32.3 | NOK | http://autobuild.buildroot.net/results/f271386d3cefad4a4971bc8698848b4563498e6b/
./.libs/libgdk_pixbuf-2.0.so: undefined reference to `libintl_bind_textdomain_codeset'
./.libs/libgdk_pixbuf-2.0.so: undefined reference to `libintl_bindtextdomain'
./.libs/libgdk_pixbuf-2.0.so: undefined reference to `libintl_gettext'

Gustavo, can you have a look ?
Post by Thomas Petazzoni
mips64el | gst1-libav-1.6.3 | NOK | http://autobuild.buildroot.net/results/1a0eb189ad91a7f2fb7285f4225555a0a0febda2/
libavformat/aacdec.c:1:0: error: '-mips64r2' conflicts with the other architecture options, which specify a mips64 processor

Vicente, this one is for you :-)
Post by Thomas Petazzoni
xtensa | hidapi-d17db57b9d4354752e0a... | NOK | http://autobuild.buildroot.net/results/a5b0d3816953b5477d7938cf001fb048fee7462b/
Weird:

make[3]: *** No rule to make target `hidtest.o', needed by `hidtest-libusb'. Stop.

Alan, hidapi is your thing, would you mind having a look ?
Post by Thomas Petazzoni
arm | host-efl-1.15.3 | NOK | http://autobuild.buildroot.net/results/e178371c2c3bf42d59c6fc26409e098081239ccb/
lib/evas/filters/evas_filter_parser.c: In function '_lua_backtrace':
lib/evas/filters/evas_filter_parser.c:2434:20: error: 'LUA_GLOBALSINDEX' undeclared (first use in this function)
lua_getfield(L, LUA_GLOBALSINDEX, "debug");

Romain ? This is host-efl, maybe we need to disable Lua support or
something ?
Post by Thomas Petazzoni
microblazeel | host-gdb-6be65fb56ea6694a92... | NOK | http://autobuild.buildroot.net/results/d35f6ee7643a695af7db3739ff480d25b99ee051/
microblazeel | host-gdb-6be65fb56ea6694a92... | NOK | http://autobuild.buildroot.net/results/09f4a89e463b6ccbca01cce1d38eb849c17ed6e1/
The documentation issue. Romain, you looked into this a while ago, why
does it pop up again on Microblaze specifically ?

Maybe we can switch to the mainline gdb for Microblaze ?
Post by Thomas Petazzoni
nios2 | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/0e8d5ab5127b5e40c58912fe16504e3fcb941e69/
arm | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/10f61d4cc5f6fdac231185d577493e0e82c5d091/
microblazeel | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/bdcb9bbd7a07f0bde1b575bbf7ae88d006a1e823/
arm | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/a25de6a6e8d68fd86ebf2c5805c6fe31d5860656/
arm | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/f00e14e2360544ffe7501247dddfcb701631646d/
mips64el | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/95491e089e6e18bfddbf6d7d19450026e9a349f5/
mips64el | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/936d66543e2db55309af115ead64ded24f31661c/
arm | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/25409dfeb7ce5806115092eb341e201d680ab974/
bfin | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/1a45412939a3f9d6fa59d086d834a3b4a4bffef7/
Would be fixed by http://patchwork.ozlabs.org/patch/571347/.
Post by Thomas Petazzoni
nios2 | imagemagick-6.9.2-10 | NOK | http://autobuild.buildroot.net/results/0bf3a2a284b7d4712ab1530562d3b8164fc75e88/
The usual:

assertion fail elf32-nios2.c:1038

This is being fixed at
https://sourceware.org/bugzilla/show_bug.cgi?id=19405. In the mean
time, we could disable on NIOS II maybe ?
Post by Thomas Petazzoni
arm | iperf3-3.1 | NOK | http://autobuild.buildroot.net/results/50e34db9e273ebb7b8a9198dec254f6b22e26eff/
iperf.h:71:21: error: field 'tcpInfo' has incomplete type
struct tcp_info tcpInfo; /* getsockopt(TCP_INFO) for Linux, {Free,Net}BSD */

musl build issue.

Gustavo, you added the iperf3 package, can you have a look ?
Post by Thomas Petazzoni
x86_64 | iproute2-4.4.0 | NOK | http://autobuild.buildroot.net/results/d3d79b55cb19987d5d5c0da9c0f0d25697697c05/
Already fixed by
https://git.busybox.net/buildroot/commit/?id=11d7b8b64aa171823bc4c97e3cce43884d078ecf.
Post by Thomas Petazzoni
x86_64 | iucode-tool-1cbd73013cd4c6b... | NOK | http://autobuild.buildroot.net/results/7f8626db69500a84a393053a485f04180c565673/
Fixed by https://git.busybox.net/buildroot/commit/?id=6a774f400b20612cb77836a47aaf62ea72422fb8.
Post by Thomas Petazzoni
nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/183df75a853c3b0e2617c9219a356c5531aa523d/
Will be fixed once we bump to binutils 2.26. Romain, maybe we should
disable libcap-ng in the mean time ?
Post by Thomas Petazzoni
x86_64 | libdrm-2.4.66 | NOK | http://autobuild.buildroot.net/results/7d444611f8efa40e0eb81ac88365416ef553fcd5/
x86_64 | libdrm-2.4.66 | NOK | http://autobuild.buildroot.net/results/6287fa5a754610f04f0df93bf611676d982f5cff/
Musl build issue. Bernd, can you have a look ?
Post by Thomas Petazzoni
powerpc | libnss-3.21 | NOK | http://autobuild.buildroot.net/results/cdae10070b9a97066dbfd0fb2c2004d9bd1fdd43/
powerpc | libnss-3.21 | NOK | http://autobuild.buildroot.net/results/0df8b1f78b671ff05b2ecbf9c4cf08b8898e2d43/
Fixed by https://git.busybox.net/buildroot/commit/?id=b8fb4903fb858bc81eab6ac5bd37c801853594cb.
Post by Thomas Petazzoni
i686 | libsoil-20080707 | NOK | http://autobuild.buildroot.net/results/8ff91ab8e52000eb34dd8f662520cf1b31490cf5/
x86_64 | libsoil-20080707 | NOK | http://autobuild.buildroot.net/results/ea77d6b23aca0cb1cf527e6c16ddf5eba957a69c/
These are really weird. The patch doesn't apply when the build takes
place on my build server, but it does apply when I test things locally
on my machine. A difference in the version of patch ?
Post by Thomas Petazzoni
sparc | libubox-e88d816d6e462180f03... | NOK | http://autobuild.buildroot.net/results/4feaa9089ee9a183c5086b791bea35c0156945af/
Atomic issue strikes again.
Post by Thomas Petazzoni
mips64el | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/4d63874fe2efda8ac7aa3a8c82affa99f0ce5af0/
[.... many more of this issue ....]

Fixed by
https://git.busybox.net/buildroot/commit/?id=343ec915e3f7cb6f83ef114cd6c5e5f3502d8f4a.
Post by Thomas Petazzoni
mips64el | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/3a2b141d90b28a2954fa0ad3104cba81d648d2a3/
mipsel | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/70aa227c8a289631c2973474cfaef5973756dd5c/
mips64el | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/2b8c777c76b7e5d5a426045f5a3872d6b71faa56/
mipsel | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/3f19dd459400ac7fca39e69dd280def6a547f8b6/
tirpc/tests_pack/rpc_suite/tirpc/tirpc_auth_authdes_create/tirpc_authdes_create.c:50: undefined reference to `authdes_create'
collect2: error: ld returned 1 exit status

Thomas, you touched the ltp-testsuite/tirpc handling recently IIRC.
Interestingly, this problem only occurs on MIPS apparently. Thomas,
Vicente, can you have a look ?
Post by Thomas Petazzoni
arm | lttng-tools-2.7.1 | NOK | http://autobuild.buildroot.net/results/b48bc7ad4bede4d16c079da0ae1121e6796a0e8d/
arm | lttng-tools-2.7.1 | NOK | http://autobuild.buildroot.net/results/25dcb19c3dd32e50990f9b45053d71ea18746a80/
arm | lttng-tools-2.7.1 | NOK | http://autobuild.buildroot.net/results/a3f93498811491d37ba13d024e33e68a8bc7ba18/
checking for dlopen in -lc... no
configure: error: Cannot find dlopen in libdl nor libc. Use LDFLAGS=-Ldir to specify their location.

In a static linking only situation.

Samuel, can you have a look ? Most likely we should simply disable
lttng-tools for static only scenarios.
Post by Thomas Petazzoni
x86_64 | madplay-0.15.2b | NOK | http://autobuild.buildroot.net/results/2561190b274d71666c4bdf3c569b02063cefdb30/
./relocatable.c: In function 'libintl_relocate':
./relocatable.c:402:40: error: 'INSTALLPREFIX' undeclared (first use in this function)
const char *orig_installprefix = INSTALLPREFIX;

Musl related ? Not sure. Peter, you added the madplay package back in
2007, so can you have a look ? :-)
Post by Thomas Petazzoni
microblazeel | mesa3d-11.1.1 | NOK | http://autobuild.buildroot.net/results/0d71cd6edccd390106636cc0c4acfe5a8dca112a/
microblazeel | mesa3d-11.1.1 | NOK | http://autobuild.buildroot.net/results/6567477b87c081db97a9c2bf84af182a9a281193/
Another atomic issue: __sync_val_compare_and_swap_1.
Post by Thomas Petazzoni
mipsel | mosh-1.2.5 | NOK | http://autobuild.buildroot.net/results/3f9443a76d2f8811720748b487e045eec23ec338/
mipsel | mosh-1.2.5 | NOK | http://autobuild.buildroot.net/results/104b8fae4ff5918353e0e6a7ac050e2f04d701c1/
Vicente, this is with your new mips toolchains, SSP library problem.
Can you have a look ?
Post by Thomas Petazzoni
xtensa | mp4v2-2.0.0 | NOK | http://autobuild.buildroot.net/results/bff7436a800eeea92c0c92bd2846b0f2b31947fd/
/tmp/cchH5TCg.s:23436: Error: value of 38619 too large for field of 2 bytes at 2889

Toolchain problem. Max can you have a look ?
Post by Thomas Petazzoni
aarch64 | mplayer-1.2 | NOK | http://autobuild.buildroot.net/results/aadce770cf86ded813a78f936f0a6d4441845907/
libavutil/aarch64/cpu.c:25:32: error: 'HAVE_ARMV8' undeclared (first use in this function)
return AV_CPU_FLAG_ARMV8 * HAVE_ARMV8 |
^
libavutil/aarch64/cpu.c:25:32: note: each undeclared identifier is reported only once for each function it appears in

Joao, you enabled mplayer on AArch64, can you have a look please ?
Post by Thomas Petazzoni
powerpc | nfs-utils-1.3.3 | NOK | http://autobuild.buildroot.net/results/fe3be93988e585a84ae3116a0c327e1e2c95ad08/
Still the same build issue:

cache.c: In function 'same_path':
cache.c:429:22: error: field 'fh' has incomplete type
cache.c:436:2: warning: implicit declaration of function 'name_to_handle_at' [-Wimplicit-function-declaration]
Makefile:613: recipe for target 'mountd-cache.o' failed

Maxime ? I gave you some hints about this one, can you cook a patch ?
Post by Thomas Petazzoni
arm | php-5.6.17 | NOK | http://autobuild.buildroot.net/results/0bbae90d05f14ac1fdbac7d8d69d4e6fd922e301/
Forgets to link with pthread in a static linking scenario.

Gustavo ?
Post by Thomas Petazzoni
arm | pinentry-0.9.4 | NOK | http://autobuild.buildroot.net/results/bd886cd10a8f52647296de2ff50270f25532756e/
Weird C++ error:

error: member 'QChar std::__cxx11::basic_string<QChar, std::char_traits<QChar>, secmem::alloc<QChar> >::<anonymous union>::_M_local_buf [8]' with constructor not allowed in union

Vicente, you added this package, so can you have a look ?
Post by Thomas Petazzoni
arm | pptp-linux-1.8.0 | NOK | http://autobuild.buildroot.net/results/56dd530d53489220d0080480310b8dc150cf1b2e/
Musl build issue. Gustavo ?
Post by Thomas Petazzoni
arc | qextserialport-ada321a9ee46... | NOK | http://autobuild.buildroot.net/results/d6565367f83cc845495e5e5f60935b71d04ef2da/
Toolchain issue it seems:

/home/test/autobuild/instance-1/output/host/opt/ext-toolchain/bin/../lib/gcc/arc-buildroot-linux-uclibc/4.8.4/../../../../arc-buildroot-linux-uclibc/bin/ld: /home/test/autobuild/instance-1/output/host/usr/arc-buildroot-linux-uclibc/sysroot/usr/lib/libglib-2.0.a(libglib_2_0_la-gmain.o): relocation R_ARC_32_ME against `.rodata.str1.4' can not be used when making a shared object; recompile with -fPIC

Alexey ?
Post by Thomas Petazzoni
nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/aa1492777c5f60ab45921618f64910ca4d048e5f/
nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/a74810f0fce398c41fef11b8e2b8e1a52ffdb46a/
nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/cb70d195cf9b9b5ae09b83a40ef767cc8f699a9c/
Toolchain issues. Being fixed in upstream gcc, but we should disable
with external NIOS2 toolchain anyway.

Romain ?
Post by Thomas Petazzoni
arm | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/53e7e122e96b4b96c0f5feb4f26055b3f5ad8096/
Full static configuration fails with:

/home/test/autobuild/instance-1/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.9.3/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: cannot find -ldl

See if we can, get rid of the libdl dependency or make qt (or one of
its sub-option) depend on dynamic library.
Post by Thomas Petazzoni
arm | rt-tests-v0.89 | NOK | http://autobuild.buildroot.net/results/a6f6502e55fd68803f3ff8b4b76cce6601e101db/
In file included from src/lib/rt-get_cpu.c:4:0:
src/include/rt-get_cpu.h:9:19: fatal error: dlfcn.h: No such file or directory
#include <dlfcn.h>

Should depend on dynamic library.
Post by Thomas Petazzoni
bfin | ruby-2.3.0 | NOK | http://autobuild.buildroot.net/results/268d29bd910c17b1fccad5d13ce281238080efd2/
bfin | ruby-2.3.0 | NOK | http://autobuild.buildroot.net/results/1eb3d1ca20ce81fa2b10593d9393fb130558a706/
process.c: In function 'rb_spawn_process':
process.c:3921: warning: passing argument 2 of 'rb_ary_new_from_values' from incompatible pointer type
process.c:3923: error: 'status' undeclared (first use in this function)
process.c:3923: error: (Each undeclared identifier is reported only once
process.c:3923: error: for each function it appears in.)

Sonic, this is a Blackfin problem, can you have a look ?
Post by Thomas Petazzoni
arm | sconeserver-3b886c3dda6eda3... | NOK | http://autobuild.buildroot.net/results/178bdfb062949fb10b9d6b9830975aa57702b3ae/
Static configuration, fails with:

checking for mpfr_init in -lmpfr... no
configure: error: libraries 'mpfr' and 'gmp' are required for the maths module

Simon, can you have a look ?
Post by Thomas Petazzoni
sparc64 | setools-3.3.8 | NOK | http://autobuild.buildroot.net/results/328192a8c561f3517bb0f9ebafb59d09e4f4b3ae/
policy_scan.o: In function `yyget_out':
policy_scan.c:(.text+0x504): relocation truncated to fit: R_SPARC_GOT13 against symbol `yyout' defined in .bss section in policy_scan.o
policy_scan.o: In function `yyget_leng':
policy_scan.c:(.text+0x520): relocation truncated to fit: R_SPARC_GOT13 against symbol `yyleng' defined in COMMON section in policy_scan.o

Waldemar, this is a toolchain problem, can you have a look ?
Post by Thomas Petazzoni
mips64el | slang-2.3.0 | NOK | http://autobuild.buildroot.net/results/3c1fef2163b8a194ede70040da87af95bf5dc331/
/home/buildroot/autobuild/run/instance-2/output/host/usr/mips64el-buildroot-linux-uclibc/sysroot/usr/lib/../lib64/libreadline.a(display.o): In function `cr':
display.c:(.text+0x208): undefined reference to `tputs'
display.c:(.text+0x210): undefined reference to `tputs'

Static linking problem.

Vicente, in commit 41d6f177d226b9014f5a14d0d05ca843f482d94f, you added
some patches to fix static linking. Seems like there are more
problems :-)
Post by Thomas Petazzoni
arm | strongswan-5.3.5 | NOK | http://autobuild.buildroot.net/results/601d8dc1654d8733db49b195139e12437663034c/
plugins/plugin_loader.c: In function 'load_plugin':
plugins/plugin_loader.c:359:13: error: 'RTLD_LAZY' undeclared (first use in this function)
int flag = RTLD_LAZY;

Needs dynamic library ?
Post by Thomas Petazzoni
mipsel | stunnel-5.28 | NOK | http://autobuild.buildroot.net/results/3448dc253a4a86450f15fb225374bd1e643dacd1/
Vicente, this is with your new MIPS toolchain, SSP problem:

/home/peko/autobuild/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-linux-gnu/bin/ld: cannot find -lssp_nonshared
/home/peko/autobuild/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-linux-gnu/bin/ld: cannot find -lssp
Post by Thomas Petazzoni
arc | tar-1.28 | NOK | http://autobuild.buildroot.net/results/e9c5df490264a2d9ff5160187bda75431493d666/
../gnu/libgnu.a(quotearg.o): In function `quote':
quotearg.c:(.text+0xdac): multiple definition of `quote'
/home/buildroot/buildroot-test/instance-1/output/host/usr/arc-buildroot-linux-uclibc/sysroot/usr/lib/libacl.a(quote.o):/home/buildroot/buildroot-test/instance-1/output/build/acl-2.2.52/libmisc/quote.c:27: first defined here

I don't think it's specific to ARC. Anyone to have a look ?
Post by Thomas Petazzoni
arc | trousers-0.3.13 | NOK | http://autobuild.buildroot.net/results/7009e334e51adce37353c5d4f618fb28678f6114/
PIE problem, patch pending.
Post by Thomas Petazzoni
arm | webkitgtk24-2.4.9 | NOK | http://autobuild.buildroot.net/results/c660d29b0184daf7d16045b595e48d3c73ab521a/
checking for GLES2/gl2.h... yes
checking whether to use OpenGL ES 2 support... configure: error: Cannot enable OpenGL ES 2 support without EGL enabled.

Gustavo ?

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
Thomas De Schampheleire
2016-01-22 09:36:54 UTC
Permalink
On Fri, Jan 22, 2016 at 10:29 AM, Thomas Petazzoni
<***@free-electrons.com> wrote:
[..]
Post by Thomas Petazzoni
Post by Thomas Petazzoni
mips64el | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/3a2b141d90b28a2954fa0ad3104cba81d648d2a3/
mipsel | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/70aa227c8a289631c2973474cfaef5973756dd5c/
mips64el | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/2b8c777c76b7e5d5a426045f5a3872d6b71faa56/
mipsel | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/3f19dd459400ac7fca39e69dd280def6a547f8b6/
tirpc/tests_pack/rpc_suite/tirpc/tirpc_auth_authdes_create/tirpc_authdes_create.c:50: undefined reference to `authdes_create'
collect2: error: ld returned 1 exit status
Thomas, you touched the ltp-testsuite/tirpc handling recently IIRC.
Interestingly, this problem only occurs on MIPS apparently. Thomas,
Vicente, can you have a look ?
Yes, I have noticed this same problem very recently here and have a
local patch which I will submit. It seems my original patch did not
disable all required tests.

/Thomas
Gustavo Zacarias
2016-01-22 11:26:57 UTC
Permalink
Post by Thomas Petazzoni
Post by Thomas Petazzoni
mipsel | bind-9.10.3-P2 | NOK | http://autobuild.buildroot.net/results/62f386829193c747176ace05e4b26826fcabbf59/
mips64el | bind-9.10.3-P2 | NOK | http://autobuild.buildroot.net/results/a92fa5dc5d9d6742d61d4d293f7eac97c5355dfe/
rbt.c:116:15: error: two or more data types in declaration specifiers
isc_uint32_t ptrsize;
^
rbt.c:116:22: error: expected identifier or '(' before ';' token
isc_uint32_t ptrsize;
Gustavo, can you have a look ? I think this error already popped up in the past, no?
Hi.
Finally nailed it down, it's uclibc's fault, basically it #defines
ptrsize in bits/setjmp.h for mips.
Waldemar: you did that in 70a04a287a2875c82e6822c36e071afba5b63a62
(uclibc), unfortunately it will be hard to get rid of, we'll have to
live with this for some time.
I can patch bind to not use ptrsize (say, rename it to pointersize or
something like that) and that fixes it, however it definitely won't be
upstreamable (i don't even want to show my face to explain why it's
necessary).
This could affect other programs in the future i believe.
Regards.
Waldemar Brodkorb
2016-01-22 18:38:06 UTC
Permalink
Hi Thomas,
Thomas Petazzoni wrote,
Post by Thomas Petazzoni
Hello,
Gustavo, Carsten, Frank, Vicente, Alan, Romain, Bernd, Thomas, Peter,
Max, Joao, Maxime, Sonic, Simon, Waldemar, please see below, there are
some questions for you. Thanks!
libatomic_ops not usable. Probably need to disable erlang on Sparc and
be done with it?
You got a patch for it, a while back :=)
http://patchwork.ozlabs.org/patch/553137/

best regards
Waldemar
Romain Naour
2016-01-22 23:19:36 UTC
Permalink
Hi Thomas,
Post by Thomas Petazzoni
Hello,
Gustavo, Carsten, Frank, Vicente, Alan, Romain, Bernd, Thomas, Peter,
Max, Joao, Maxime, Sonic, Simon, Waldemar, please see below, there are
some questions for you. Thanks!
Post by Thomas Petazzoni
arm | host-efl-1.15.3 | NOK | http://autobuild.buildroot.net/results/e178371c2c3bf42d59c6fc26409e098081239ccb/
lib/evas/filters/evas_filter_parser.c:2434:20: error: 'LUA_GLOBALSINDEX' undeclared (first use in this function)
lua_getfield(L, LUA_GLOBALSINDEX, "debug");
Romain ? This is host-efl, maybe we need to disable Lua support or
something ?
It's a lua 5.1 vs 5.2 and 5.3 issue.

It's a complete mess because there is an uptream patch [1] that try to fixes the
build issue, but not completely.

The build fail with the following error due to compatibility mode in lua
(LUA_COMPAT_ALL and LUA_COMPAT_5_1):

lib/evas/.libs/libevas.so: undefined reference to `luaL_openlib'
collect2: error: ld returned 1 exit status

Also the patch break the build for lua 5.1...
So, I think it's safe to add a dependency on lua 5.1 and report the problem
upstream.

[1]
https://git.enlightenment.org/core/efl.git/commit/?id=6124d0733657e425001ce51f526aea3bb8dc54e7
Post by Thomas Petazzoni
Post by Thomas Petazzoni
microblazeel | host-gdb-6be65fb56ea6694a92... | NOK | http://autobuild.buildroot.net/results/d35f6ee7643a695af7db3739ff480d25b99ee051/
microblazeel | host-gdb-6be65fb56ea6694a92... | NOK | http://autobuild.buildroot.net/results/09f4a89e463b6ccbca01cce1d38eb849c17ed6e1/
The documentation issue. Romain, you looked into this a while ago, why
does it pop up again on Microblaze specifically ?
I think this build failure is here since we SED into the Makefile to remove the
documentation.

But I gave up on the patch for upstream...
Post by Thomas Petazzoni
Maybe we can switch to the mainline gdb for Microblaze ?
Why not. The latest gdb version was 7.5.1 when gdb for Microblaze was added to
Buildroot. Now we have at least 7.7.x.
Post by Thomas Petazzoni
Post by Thomas Petazzoni
nios2 | imagemagick-6.9.2-10 | NOK | http://autobuild.buildroot.net/results/0bf3a2a284b7d4712ab1530562d3b8164fc75e88/
assertion fail elf32-nios2.c:1038
This is being fixed at
https://sourceware.org/bugzilla/show_bug.cgi?id=19405. In the mean
time, we could disable on NIOS II maybe ?
Yes maybe.
Post by Thomas Petazzoni
Post by Thomas Petazzoni
nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/183df75a853c3b0e2617c9219a356c5531aa523d/
Will be fixed once we bump to binutils 2.26. Romain, maybe we should
disable libcap-ng in the mean time ?
binutils 2.26 should be released in a few days, hopefully.
Post by Thomas Petazzoni
Post by Thomas Petazzoni
nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/aa1492777c5f60ab45921618f64910ca4d048e5f/
nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/a74810f0fce398c41fef11b8e2b8e1a52ffdb46a/
nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/cb70d195cf9b9b5ae09b83a40ef767cc8f699a9c/
Toolchain issues. Being fixed in upstream gcc, but we should disable
with external NIOS2 toolchain anyway.
Romain ?
This patch should be fine:
http://patchwork.ozlabs.org/patch/561414/

Best regards,
Romain
Post by Thomas Petazzoni
Thomas
Thomas Petazzoni
2016-01-23 08:32:09 UTC
Permalink
Hello,
Post by Romain Naour
Post by Thomas Petazzoni
Romain ? This is host-efl, maybe we need to disable Lua support or
something ?
It's a lua 5.1 vs 5.2 and 5.3 issue.
It's a complete mess because there is an uptream patch [1] that try to fixes the
build issue, but not completely.
The build fail with the following error due to compatibility mode in lua
lib/evas/.libs/libevas.so: undefined reference to `luaL_openlib'
collect2: error: ld returned 1 exit status
Also the patch break the build for lua 5.1...
So, I think it's safe to add a dependency on lua 5.1 and report the problem
upstream.
So you would make the *target* EFL package depend on lua 5.1, so that
the *host* EFL package also gets built against the host Lua 5.1 ?

I guess there is no way of disabling Lua support ? :-)

So, yes, in the mean time, please add the dependency, and report the
problem upstream. BTW, did you test the --enable-lua-old option that
is mentioned in
https://git.enlightenment.org/core/efl.git/commit/?id=6124d0733657e425001ce51f526aea3bb8dc54e7,
which you pointed ?
Post by Romain Naour
Post by Thomas Petazzoni
Post by Thomas Petazzoni
microblazeel | host-gdb-6be65fb56ea6694a92... | NOK | http://autobuild.buildroot.net/results/d35f6ee7643a695af7db3739ff480d25b99ee051/
microblazeel | host-gdb-6be65fb56ea6694a92... | NOK | http://autobuild.buildroot.net/results/09f4a89e463b6ccbca01cce1d38eb849c17ed6e1/
The documentation issue. Romain, you looked into this a while ago, why
does it pop up again on Microblaze specifically ?
I think this build failure is here since we SED into the Makefile to remove the
documentation.
I don't understand. Isn't the SED precisely here to prevent the
documentation from being built ?
Post by Romain Naour
But I gave up on the patch for upstream...
What was the feedback ?
Post by Romain Naour
Post by Thomas Petazzoni
Maybe we can switch to the mainline gdb for Microblaze ?
Why not. The latest gdb version was 7.5.1 when gdb for Microblaze was added to
Buildroot. Now we have at least 7.7.x.
I think we should try to use the mainline gdb. We have a Microblaze
Qemu configuration, so we can at least do some basic testing here.
Post by Romain Naour
Post by Thomas Petazzoni
Post by Thomas Petazzoni
nios2 | imagemagick-6.9.2-10 | NOK | http://autobuild.buildroot.net/results/0bf3a2a284b7d4712ab1530562d3b8164fc75e88/
assertion fail elf32-nios2.c:1038
This is being fixed at
https://sourceware.org/bugzilla/show_bug.cgi?id=19405. In the mean
time, we could disable on NIOS II maybe ?
Yes maybe.
Can you submit a patch ?
Post by Romain Naour
Post by Thomas Petazzoni
Post by Thomas Petazzoni
nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/183df75a853c3b0e2617c9219a356c5531aa523d/
Will be fixed once we bump to binutils 2.26. Romain, maybe we should
disable libcap-ng in the mean time ?
binutils 2.26 should be released in a few days, hopefully.
Ok, good.
Post by Romain Naour
Post by Thomas Petazzoni
Post by Thomas Petazzoni
nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/aa1492777c5f60ab45921618f64910ca4d048e5f/
nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/a74810f0fce398c41fef11b8e2b8e1a52ffdb46a/
nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/cb70d195cf9b9b5ae09b83a40ef767cc8f699a9c/
Toolchain issues. Being fixed in upstream gcc, but we should disable
with external NIOS2 toolchain anyway.
Romain ?
http://patchwork.ozlabs.org/patch/561414/
Thanks. The only thing that bothers me a bit is that we will likely
forget to remove all those "depends on BR2_nios2". But I guess we don't
really have the choice.

Thanks,

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
Romain Naour
2016-01-23 10:47:30 UTC
Permalink
Hi Thomas,
Post by Thomas Petazzoni
Hello,
Post by Romain Naour
Post by Thomas Petazzoni
Romain ? This is host-efl, maybe we need to disable Lua support or
something ?
It's a lua 5.1 vs 5.2 and 5.3 issue.
It's a complete mess because there is an uptream patch [1] that try to fixes the
build issue, but not completely.
The build fail with the following error due to compatibility mode in lua
lib/evas/.libs/libevas.so: undefined reference to `luaL_openlib'
collect2: error: ld returned 1 exit status
Also the patch break the build for lua 5.1...
So, I think it's safe to add a dependency on lua 5.1 and report the problem
upstream.
So you would make the *target* EFL package depend on lua 5.1, so that
the *host* EFL package also gets built against the host Lua 5.1 ?
Yes.
I didn't have the issue during the EFL bump since Lua 5.1 was the default choice
in Buildroot until recently.
Post by Thomas Petazzoni
I guess there is no way of disabling Lua support ? :-)
No indeed, we have the choice between old lua and luajit.
Post by Thomas Petazzoni
So, yes, in the mean time, please add the dependency, and report the
problem upstream. BTW, did you test the --enable-lua-old option that
is mentioned in
https://git.enlightenment.org/core/efl.git/commit/?id=6124d0733657e425001ce51f526aea3bb8dc54e7,
which you pointed ?
I have a small series (not yet submitted) enabling luajit :)
Post by Thomas Petazzoni
Post by Romain Naour
Post by Thomas Petazzoni
Post by Thomas Petazzoni
microblazeel | host-gdb-6be65fb56ea6694a92... | NOK | http://autobuild.buildroot.net/results/d35f6ee7643a695af7db3739ff480d25b99ee051/
microblazeel | host-gdb-6be65fb56ea6694a92... | NOK | http://autobuild.buildroot.net/results/09f4a89e463b6ccbca01cce1d38eb849c17ed6e1/
The documentation issue. Romain, you looked into this a while ago, why
does it pop up again on Microblaze specifically ?
I think this build failure is here since we SED into the Makefile to remove the
documentation.
I don't understand. Isn't the SED precisely here to prevent the
documentation from being built ?
I didn't investigate further but it seems we remove something in the Makefile
with the SED command that break the build.
Post by Thomas Petazzoni
Post by Romain Naour
But I gave up on the patch for upstream...
What was the feedback ?
https://sourceware.org/ml/gdb-patches/2015-09/msg00579.html

I don't remember if I tried with this proposal:
https://sourceware.org/ml/gdb-patches/2015-09/msg00572.html
Post by Thomas Petazzoni
Post by Romain Naour
Post by Thomas Petazzoni
Maybe we can switch to the mainline gdb for Microblaze ?
Why not. The latest gdb version was 7.5.1 when gdb for Microblaze was added to
Buildroot. Now we have at least 7.7.x.
I think we should try to use the mainline gdb. We have a Microblaze
Qemu configuration, so we can at least do some basic testing here.
Post by Romain Naour
Post by Thomas Petazzoni
Post by Thomas Petazzoni
nios2 | imagemagick-6.9.2-10 | NOK | http://autobuild.buildroot.net/results/0bf3a2a284b7d4712ab1530562d3b8164fc75e88/
assertion fail elf32-nios2.c:1038
This is being fixed at
https://sourceware.org/bugzilla/show_bug.cgi?id=19405. In the mean
time, we could disable on NIOS II maybe ?
Yes maybe.
Can you submit a patch ?
Post by Romain Naour
Post by Thomas Petazzoni
Post by Thomas Petazzoni
nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/183df75a853c3b0e2617c9219a356c5531aa523d/
Will be fixed once we bump to binutils 2.26. Romain, maybe we should
disable libcap-ng in the mean time ?
binutils 2.26 should be released in a few days, hopefully.
Ok, good.
Post by Romain Naour
Post by Thomas Petazzoni
Post by Thomas Petazzoni
nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/aa1492777c5f60ab45921618f64910ca4d048e5f/
nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/a74810f0fce398c41fef11b8e2b8e1a52ffdb46a/
nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/cb70d195cf9b9b5ae09b83a40ef767cc8f699a9c/
Toolchain issues. Being fixed in upstream gcc, but we should disable
with external NIOS2 toolchain anyway.
Romain ?
http://patchwork.ozlabs.org/patch/561414/
Thanks. The only thing that bothers me a bit is that we will likely
forget to remove all those "depends on BR2_nios2". But I guess we don't
really have the choice.
Indeed...
Also, we should disable gcc 4.9.x and binutils 2.25.x for niosII for the
internal toolchain.

I'll send a small series doing that.

Best regards,
Romain
Post by Thomas Petazzoni
Thanks,
Thomas
Frank Hunleth
2016-01-23 01:07:18 UTC
Permalink
Hi Thomas,

On Fri, Jan 22, 2016 at 4:29 AM, Thomas Petazzoni
Post by Thomas Petazzoni
Post by Thomas Petazzoni
sparc | erlang-17.5 | NOK | http://autobuild.buildroot.net/results/20cd87c6a05c91ee223b813040d9d10fa923b174/
libatomic_ops not usable. Probably need to disable erlang on Sparc and
be done with it?
The qemu_sparc64_sun4u_defconfig with Erlang enabled works so I think
that it is just sparc_v8. I saw several comments and Waldemar's patch
concerning atomic_ops support on sparc. I'll hold off sending a patch
for this issue unless directed otherwise.
Post by Thomas Petazzoni
Post by Thomas Petazzoni
x86_64 | erlang-17.5 | NOK | http://autobuild.buildroot.net/results/e4ab3fa4a121f7d7edb0263f02aac2ee836905a7/
sys/common/erl_poll.h:132:5: error: '__uint32_t' undeclared (first use in this function)
((__uint32_t) (EV))
^
sys/common/erl_poll.c:1150:24: note: in expansion of macro 'ERTS_POLL_EV_E2N'
epe_templ.events = ERTS_POLL_EV_E2N(ps->fds_status[fd].events);
^
sys/common/erl_poll.h:132:5: note: each undeclared identifier is reported only once for each function it appears in
((__uint32_t) (EV))
^
sys/common/erl_poll.c:1150:24: note: in expansion of macro 'ERTS_POLL_EV_E2N'
epe_templ.events = ERTS_POLL_EV_E2N(ps->fds_status[fd].events);
^
Musl build issue. Frank, can you have a look at this one ?
Yes. Hopefully there's a patch in Alpine Linux that addresses this.
I'll take a look after I get the other Erlang updates out of the way.

Frank
Samuel Martin
2016-01-23 10:55:41 UTC
Permalink
Hi Thomas, all,

On Fri, Jan 22, 2016 at 10:29 AM, Thomas Petazzoni
<***@free-electrons.com> wrote:
[...]
Post by Thomas Petazzoni
Post by Thomas Petazzoni
arm | lttng-tools-2.7.1 | NOK | http://autobuild.buildroot.net/results/b48bc7ad4bede4d16c079da0ae1121e6796a0e8d/
arm | lttng-tools-2.7.1 | NOK | http://autobuild.buildroot.net/results/25dcb19c3dd32e50990f9b45053d71ea18746a80/
arm | lttng-tools-2.7.1 | NOK | http://autobuild.buildroot.net/results/a3f93498811491d37ba13d024e33e68a8bc7ba18/
checking for dlopen in -lc... no
configure: error: Cannot find dlopen in libdl nor libc. Use LDFLAGS=-Ldir to specify their location.
In a static linking only situation.
Samuel, can you have a look ? Most likely we should simply disable
lttng-tools for static only scenarios.
Indeed.
Patches just sent ;-)
http://patchwork.ozlabs.org/patch/572083/
http://patchwork.ozlabs.org/patch/572084/

Regards,
--
Samuel
Joao Pinto
2016-01-26 12:02:46 UTC
Permalink
Hi Thomas,

Could you tell me what changed in the Buildroot ecosystem to generate such "new"
errors?

Joao
Post by Thomas Petazzoni
Hello,
Gustavo, Carsten, Frank, Vicente, Alan, Romain, Bernd, Thomas, Peter,
Max, Joao, Maxime, Sonic, Simon, Waldemar, please see below, there are
some questions for you. Thanks!
Post by Thomas Petazzoni
arm | aumix-2.8 | NOK | http://autobuild.buildroot.net/results/c8c7f9a799d1af507a6edd5e02b0bbc8b7b5d068/
gettext/libintl handling issue.
Post by Thomas Petazzoni
mipsel | bind-9.10.3-P2 | NOK | http://autobuild.buildroot.net/results/62f386829193c747176ace05e4b26826fcabbf59/
mips64el | bind-9.10.3-P2 | NOK | http://autobuild.buildroot.net/results/a92fa5dc5d9d6742d61d4d293f7eac97c5355dfe/
rbt.c:116:15: error: two or more data types in declaration specifiers
isc_uint32_t ptrsize;
^
rbt.c:116:22: error: expected identifier or '(' before ';' token
isc_uint32_t ptrsize;
Gustavo, can you have a look ? I think this error already popped up in the past, no?
Post by Thomas Petazzoni
arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/c7d987a51f2b2b731fb60e0e741361bbfb4ff230/
x86_64 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/b2c860fc8fbc7a025bcd3c04e9b43b04f029ead3/
arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/5a33d69d2c11e3013b73b3f6c1d8ab3a31facf62/
arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/a7c7eb7c2f477f8a19c1b364f746dfd31bf18a3d/
arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/fb2f5cbe28a41161df7e3c5b2f6a36242daf5374/
xtensa | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/179345a92e0c1db1b8d5bccb27c6b93e484f9b6d/
i686 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/8612864811bbb04d655a6040869ccb81396d7737/
arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/51c54c85010c61245a4ef51d4e602974809d077f/
arc | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/e474243b83233c008fc2351c77eba35269e95439/
xtensa | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/30898a3c7a5fceb1bd14a287064b96e04fba7921/
microblazeel | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/d5d159dc004e28fed537b84fae76afb0734b2ec0/
microblazeel | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/71e9dbb63b91980723554651071fdc3d7a2250f2/
mips64el | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/3ee30fe28f709c63c9a0e2d0d91440d855ff73a9/
xtensa | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/c48523b0bc50c61a9dd1bb691cd3fe3b05fdc1a7/
sh4 | boost-1.60.0 | NOK | http://autobuild.buildroot.net/results/04553f5d6b73b0a97901995674b0876c33d062f5/
The FE_* issue. I tried to have a look at the other day. It seems like
the Boost code does check for FE_*, but it does by running tests with
the host compiler... So it concludes that fenv.h support is OK, but
then it really builds with the target compiler and fails. But the boost
build system is so... that I'm not even sure.
Post by Thomas Petazzoni
arm | dvbsnoop-1.4.50 | NOK | http://autobuild.buildroot.net/results/be64a45ac158b9057fb3e7ef9b515250acc77187/
Still the u_long problem. Carsten ?
Post by Thomas Petazzoni
sparc | erlang-17.5 | NOK | http://autobuild.buildroot.net/results/20cd87c6a05c91ee223b813040d9d10fa923b174/
libatomic_ops not usable. Probably need to disable erlang on Sparc and
be done with it?
Post by Thomas Petazzoni
x86_64 | erlang-17.5 | NOK | http://autobuild.buildroot.net/results/e4ab3fa4a121f7d7edb0263f02aac2ee836905a7/
sys/common/erl_poll.h:132:5: error: '__uint32_t' undeclared (first use in this function)
((__uint32_t) (EV))
^
sys/common/erl_poll.c:1150:24: note: in expansion of macro 'ERTS_POLL_EV_E2N'
epe_templ.events = ERTS_POLL_EV_E2N(ps->fds_status[fd].events);
^
sys/common/erl_poll.h:132:5: note: each undeclared identifier is reported only once for each function it appears in
((__uint32_t) (EV))
^
sys/common/erl_poll.c:1150:24: note: in expansion of macro 'ERTS_POLL_EV_E2N'
epe_templ.events = ERTS_POLL_EV_E2N(ps->fds_status[fd].events);
^
Musl build issue. Frank, can you have a look at this one ?
Post by Thomas Petazzoni
arm | gdk-pixbuf-2.32.3 | NOK | http://autobuild.buildroot.net/results/f271386d3cefad4a4971bc8698848b4563498e6b/
./.libs/libgdk_pixbuf-2.0.so: undefined reference to `libintl_bind_textdomain_codeset'
./.libs/libgdk_pixbuf-2.0.so: undefined reference to `libintl_bindtextdomain'
./.libs/libgdk_pixbuf-2.0.so: undefined reference to `libintl_gettext'
Gustavo, can you have a look ?
Post by Thomas Petazzoni
mips64el | gst1-libav-1.6.3 | NOK | http://autobuild.buildroot.net/results/1a0eb189ad91a7f2fb7285f4225555a0a0febda2/
libavformat/aacdec.c:1:0: error: '-mips64r2' conflicts with the other architecture options, which specify a mips64 processor
Vicente, this one is for you :-)
Post by Thomas Petazzoni
xtensa | hidapi-d17db57b9d4354752e0a... | NOK | http://autobuild.buildroot.net/results/a5b0d3816953b5477d7938cf001fb048fee7462b/
make[3]: *** No rule to make target `hidtest.o', needed by `hidtest-libusb'. Stop.
Alan, hidapi is your thing, would you mind having a look ?
Post by Thomas Petazzoni
arm | host-efl-1.15.3 | NOK | http://autobuild.buildroot.net/results/e178371c2c3bf42d59c6fc26409e098081239ccb/
lib/evas/filters/evas_filter_parser.c:2434:20: error: 'LUA_GLOBALSINDEX' undeclared (first use in this function)
lua_getfield(L, LUA_GLOBALSINDEX, "debug");
Romain ? This is host-efl, maybe we need to disable Lua support or
something ?
Post by Thomas Petazzoni
microblazeel | host-gdb-6be65fb56ea6694a92... | NOK | http://autobuild.buildroot.net/results/d35f6ee7643a695af7db3739ff480d25b99ee051/
microblazeel | host-gdb-6be65fb56ea6694a92... | NOK | http://autobuild.buildroot.net/results/09f4a89e463b6ccbca01cce1d38eb849c17ed6e1/
The documentation issue. Romain, you looked into this a while ago, why
does it pop up again on Microblaze specifically ?
Maybe we can switch to the mainline gdb for Microblaze ?
Post by Thomas Petazzoni
nios2 | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/0e8d5ab5127b5e40c58912fe16504e3fcb941e69/
arm | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/10f61d4cc5f6fdac231185d577493e0e82c5d091/
microblazeel | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/bdcb9bbd7a07f0bde1b575bbf7ae88d006a1e823/
arm | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/a25de6a6e8d68fd86ebf2c5805c6fe31d5860656/
arm | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/f00e14e2360544ffe7501247dddfcb701631646d/
mips64el | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/95491e089e6e18bfddbf6d7d19450026e9a349f5/
mips64el | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/936d66543e2db55309af115ead64ded24f31661c/
arm | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/25409dfeb7ce5806115092eb341e201d680ab974/
bfin | host-vboot-utils-bbdd62f9b0... | NOK | http://autobuild.buildroot.net/results/1a45412939a3f9d6fa59d086d834a3b4a4bffef7/
Would be fixed by http://patchwork.ozlabs.org/patch/571347/.
Post by Thomas Petazzoni
nios2 | imagemagick-6.9.2-10 | NOK | http://autobuild.buildroot.net/results/0bf3a2a284b7d4712ab1530562d3b8164fc75e88/
assertion fail elf32-nios2.c:1038
This is being fixed at
https://sourceware.org/bugzilla/show_bug.cgi?id=19405. In the mean
time, we could disable on NIOS II maybe ?
Post by Thomas Petazzoni
arm | iperf3-3.1 | NOK | http://autobuild.buildroot.net/results/50e34db9e273ebb7b8a9198dec254f6b22e26eff/
iperf.h:71:21: error: field 'tcpInfo' has incomplete type
struct tcp_info tcpInfo; /* getsockopt(TCP_INFO) for Linux, {Free,Net}BSD */
musl build issue.
Gustavo, you added the iperf3 package, can you have a look ?
Post by Thomas Petazzoni
x86_64 | iproute2-4.4.0 | NOK | http://autobuild.buildroot.net/results/d3d79b55cb19987d5d5c0da9c0f0d25697697c05/
Already fixed by
https://git.busybox.net/buildroot/commit/?id=11d7b8b64aa171823bc4c97e3cce43884d078ecf.
Post by Thomas Petazzoni
x86_64 | iucode-tool-1cbd73013cd4c6b... | NOK | http://autobuild.buildroot.net/results/7f8626db69500a84a393053a485f04180c565673/
Fixed by https://git.busybox.net/buildroot/commit/?id=6a774f400b20612cb77836a47aaf62ea72422fb8.
Post by Thomas Petazzoni
nios2 | libcap-ng-0.7.4 | NOK | http://autobuild.buildroot.net/results/183df75a853c3b0e2617c9219a356c5531aa523d/
Will be fixed once we bump to binutils 2.26. Romain, maybe we should
disable libcap-ng in the mean time ?
Post by Thomas Petazzoni
x86_64 | libdrm-2.4.66 | NOK | http://autobuild.buildroot.net/results/7d444611f8efa40e0eb81ac88365416ef553fcd5/
x86_64 | libdrm-2.4.66 | NOK | http://autobuild.buildroot.net/results/6287fa5a754610f04f0df93bf611676d982f5cff/
Musl build issue. Bernd, can you have a look ?
Post by Thomas Petazzoni
powerpc | libnss-3.21 | NOK | http://autobuild.buildroot.net/results/cdae10070b9a97066dbfd0fb2c2004d9bd1fdd43/
powerpc | libnss-3.21 | NOK | http://autobuild.buildroot.net/results/0df8b1f78b671ff05b2ecbf9c4cf08b8898e2d43/
Fixed by https://git.busybox.net/buildroot/commit/?id=b8fb4903fb858bc81eab6ac5bd37c801853594cb.
Post by Thomas Petazzoni
i686 | libsoil-20080707 | NOK | http://autobuild.buildroot.net/results/8ff91ab8e52000eb34dd8f662520cf1b31490cf5/
x86_64 | libsoil-20080707 | NOK | http://autobuild.buildroot.net/results/ea77d6b23aca0cb1cf527e6c16ddf5eba957a69c/
These are really weird. The patch doesn't apply when the build takes
place on my build server, but it does apply when I test things locally
on my machine. A difference in the version of patch ?
Post by Thomas Petazzoni
sparc | libubox-e88d816d6e462180f03... | NOK | http://autobuild.buildroot.net/results/4feaa9089ee9a183c5086b791bea35c0156945af/
Atomic issue strikes again.
Post by Thomas Petazzoni
mips64el | libv4l-1.8.1 | NOK | http://autobuild.buildroot.net/results/4d63874fe2efda8ac7aa3a8c82affa99f0ce5af0/
[.... many more of this issue ....]
Fixed by
https://git.busybox.net/buildroot/commit/?id=343ec915e3f7cb6f83ef114cd6c5e5f3502d8f4a.
Post by Thomas Petazzoni
mips64el | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/3a2b141d90b28a2954fa0ad3104cba81d648d2a3/
mipsel | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/70aa227c8a289631c2973474cfaef5973756dd5c/
mips64el | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/2b8c777c76b7e5d5a426045f5a3872d6b71faa56/
mipsel | ltp-testsuite-20150903 | NOK | http://autobuild.buildroot.net/results/3f19dd459400ac7fca39e69dd280def6a547f8b6/
tirpc/tests_pack/rpc_suite/tirpc/tirpc_auth_authdes_create/tirpc_authdes_create.c:50: undefined reference to `authdes_create'
collect2: error: ld returned 1 exit status
Thomas, you touched the ltp-testsuite/tirpc handling recently IIRC.
Interestingly, this problem only occurs on MIPS apparently. Thomas,
Vicente, can you have a look ?
Post by Thomas Petazzoni
arm | lttng-tools-2.7.1 | NOK | http://autobuild.buildroot.net/results/b48bc7ad4bede4d16c079da0ae1121e6796a0e8d/
arm | lttng-tools-2.7.1 | NOK | http://autobuild.buildroot.net/results/25dcb19c3dd32e50990f9b45053d71ea18746a80/
arm | lttng-tools-2.7.1 | NOK | http://autobuild.buildroot.net/results/a3f93498811491d37ba13d024e33e68a8bc7ba18/
checking for dlopen in -lc... no
configure: error: Cannot find dlopen in libdl nor libc. Use LDFLAGS=-Ldir to specify their location.
In a static linking only situation.
Samuel, can you have a look ? Most likely we should simply disable
lttng-tools for static only scenarios.
Post by Thomas Petazzoni
x86_64 | madplay-0.15.2b | NOK | http://autobuild.buildroot.net/results/2561190b274d71666c4bdf3c569b02063cefdb30/
./relocatable.c:402:40: error: 'INSTALLPREFIX' undeclared (first use in this function)
const char *orig_installprefix = INSTALLPREFIX;
Musl related ? Not sure. Peter, you added the madplay package back in
2007, so can you have a look ? :-)
Post by Thomas Petazzoni
microblazeel | mesa3d-11.1.1 | NOK | http://autobuild.buildroot.net/results/0d71cd6edccd390106636cc0c4acfe5a8dca112a/
microblazeel | mesa3d-11.1.1 | NOK | http://autobuild.buildroot.net/results/6567477b87c081db97a9c2bf84af182a9a281193/
Another atomic issue: __sync_val_compare_and_swap_1.
Post by Thomas Petazzoni
mipsel | mosh-1.2.5 | NOK | http://autobuild.buildroot.net/results/3f9443a76d2f8811720748b487e045eec23ec338/
mipsel | mosh-1.2.5 | NOK | http://autobuild.buildroot.net/results/104b8fae4ff5918353e0e6a7ac050e2f04d701c1/
Vicente, this is with your new mips toolchains, SSP library problem.
Can you have a look ?
Post by Thomas Petazzoni
xtensa | mp4v2-2.0.0 | NOK | http://autobuild.buildroot.net/results/bff7436a800eeea92c0c92bd2846b0f2b31947fd/
/tmp/cchH5TCg.s:23436: Error: value of 38619 too large for field of 2 bytes at 2889
Toolchain problem. Max can you have a look ?
Post by Thomas Petazzoni
aarch64 | mplayer-1.2 | NOK | http://autobuild.buildroot.net/results/aadce770cf86ded813a78f936f0a6d4441845907/
libavutil/aarch64/cpu.c:25:32: error: 'HAVE_ARMV8' undeclared (first use in this function)
return AV_CPU_FLAG_ARMV8 * HAVE_ARMV8 |
^
libavutil/aarch64/cpu.c:25:32: note: each undeclared identifier is reported only once for each function it appears in
Joao, you enabled mplayer on AArch64, can you have a look please ?
Post by Thomas Petazzoni
powerpc | nfs-utils-1.3.3 | NOK | http://autobuild.buildroot.net/results/fe3be93988e585a84ae3116a0c327e1e2c95ad08/
cache.c:429:22: error: field 'fh' has incomplete type
cache.c:436:2: warning: implicit declaration of function 'name_to_handle_at' [-Wimplicit-function-declaration]
Makefile:613: recipe for target 'mountd-cache.o' failed
Maxime ? I gave you some hints about this one, can you cook a patch ?
Post by Thomas Petazzoni
arm | php-5.6.17 | NOK | http://autobuild.buildroot.net/results/0bbae90d05f14ac1fdbac7d8d69d4e6fd922e301/
Forgets to link with pthread in a static linking scenario.
Gustavo ?
Post by Thomas Petazzoni
arm | pinentry-0.9.4 | NOK | http://autobuild.buildroot.net/results/bd886cd10a8f52647296de2ff50270f25532756e/
error: member 'QChar std::__cxx11::basic_string<QChar, std::char_traits<QChar>, secmem::alloc<QChar> >::<anonymous union>::_M_local_buf [8]' with constructor not allowed in union
Vicente, you added this package, so can you have a look ?
Post by Thomas Petazzoni
arm | pptp-linux-1.8.0 | NOK | http://autobuild.buildroot.net/results/56dd530d53489220d0080480310b8dc150cf1b2e/
Musl build issue. Gustavo ?
Post by Thomas Petazzoni
arc | qextserialport-ada321a9ee46... | NOK | http://autobuild.buildroot.net/results/d6565367f83cc845495e5e5f60935b71d04ef2da/
/home/test/autobuild/instance-1/output/host/opt/ext-toolchain/bin/../lib/gcc/arc-buildroot-linux-uclibc/4.8.4/../../../../arc-buildroot-linux-uclibc/bin/ld: /home/test/autobuild/instance-1/output/host/usr/arc-buildroot-linux-uclibc/sysroot/usr/lib/libglib-2.0.a(libglib_2_0_la-gmain.o): relocation R_ARC_32_ME against `.rodata.str1.4' can not be used when making a shared object; recompile with -fPIC
Alexey ?
Post by Thomas Petazzoni
nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/aa1492777c5f60ab45921618f64910ca4d048e5f/
nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/a74810f0fce398c41fef11b8e2b8e1a52ffdb46a/
nios2 | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/cb70d195cf9b9b5ae09b83a40ef767cc8f699a9c/
Toolchain issues. Being fixed in upstream gcc, but we should disable
with external NIOS2 toolchain anyway.
Romain ?
Post by Thomas Petazzoni
arm | qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/53e7e122e96b4b96c0f5feb4f26055b3f5ad8096/
/home/test/autobuild/instance-1/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.9.3/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: cannot find -ldl
See if we can, get rid of the libdl dependency or make qt (or one of
its sub-option) depend on dynamic library.
Post by Thomas Petazzoni
arm | rt-tests-v0.89 | NOK | http://autobuild.buildroot.net/results/a6f6502e55fd68803f3ff8b4b76cce6601e101db/
src/include/rt-get_cpu.h:9:19: fatal error: dlfcn.h: No such file or directory
#include <dlfcn.h>
Should depend on dynamic library.
Post by Thomas Petazzoni
bfin | ruby-2.3.0 | NOK | http://autobuild.buildroot.net/results/268d29bd910c17b1fccad5d13ce281238080efd2/
bfin | ruby-2.3.0 | NOK | http://autobuild.buildroot.net/results/1eb3d1ca20ce81fa2b10593d9393fb130558a706/
process.c:3921: warning: passing argument 2 of 'rb_ary_new_from_values' from incompatible pointer type
process.c:3923: error: 'status' undeclared (first use in this function)
process.c:3923: error: (Each undeclared identifier is reported only once
process.c:3923: error: for each function it appears in.)
Sonic, this is a Blackfin problem, can you have a look ?
Post by Thomas Petazzoni
arm | sconeserver-3b886c3dda6eda3... | NOK | http://autobuild.buildroot.net/results/178bdfb062949fb10b9d6b9830975aa57702b3ae/
checking for mpfr_init in -lmpfr... no
configure: error: libraries 'mpfr' and 'gmp' are required for the maths module
Simon, can you have a look ?
Post by Thomas Petazzoni
sparc64 | setools-3.3.8 | NOK | http://autobuild.buildroot.net/results/328192a8c561f3517bb0f9ebafb59d09e4f4b3ae/
policy_scan.c:(.text+0x504): relocation truncated to fit: R_SPARC_GOT13 against symbol `yyout' defined in .bss section in policy_scan.o
policy_scan.c:(.text+0x520): relocation truncated to fit: R_SPARC_GOT13 against symbol `yyleng' defined in COMMON section in policy_scan.o
Waldemar, this is a toolchain problem, can you have a look ?
Post by Thomas Petazzoni
mips64el | slang-2.3.0 | NOK | http://autobuild.buildroot.net/results/3c1fef2163b8a194ede70040da87af95bf5dc331/
display.c:(.text+0x208): undefined reference to `tputs'
display.c:(.text+0x210): undefined reference to `tputs'
Static linking problem.
Vicente, in commit 41d6f177d226b9014f5a14d0d05ca843f482d94f, you added
some patches to fix static linking. Seems like there are more
problems :-)
Post by Thomas Petazzoni
arm | strongswan-5.3.5 | NOK | http://autobuild.buildroot.net/results/601d8dc1654d8733db49b195139e12437663034c/
plugins/plugin_loader.c:359:13: error: 'RTLD_LAZY' undeclared (first use in this function)
int flag = RTLD_LAZY;
Needs dynamic library ?
Post by Thomas Petazzoni
mipsel | stunnel-5.28 | NOK | http://autobuild.buildroot.net/results/3448dc253a4a86450f15fb225374bd1e643dacd1/
/home/peko/autobuild/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-linux-gnu/bin/ld: cannot find -lssp_nonshared
/home/peko/autobuild/instance-0/output/host/opt/ext-toolchain/bin/../lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-linux-gnu/bin/ld: cannot find -lssp
Post by Thomas Petazzoni
arc | tar-1.28 | NOK | http://autobuild.buildroot.net/results/e9c5df490264a2d9ff5160187bda75431493d666/
quotearg.c:(.text+0xdac): multiple definition of `quote'
/home/buildroot/buildroot-test/instance-1/output/host/usr/arc-buildroot-linux-uclibc/sysroot/usr/lib/libacl.a(quote.o):/home/buildroot/buildroot-test/instance-1/output/build/acl-2.2.52/libmisc/quote.c:27: first defined here
I don't think it's specific to ARC. Anyone to have a look ?
Post by Thomas Petazzoni
arc | trousers-0.3.13 | NOK | http://autobuild.buildroot.net/results/7009e334e51adce37353c5d4f618fb28678f6114/
PIE problem, patch pending.
Post by Thomas Petazzoni
arm | webkitgtk24-2.4.9 | NOK | http://autobuild.buildroot.net/results/c660d29b0184daf7d16045b595e48d3c73ab521a/
checking for GLES2/gl2.h... yes
checking whether to use OpenGL ES 2 support... configure: error: Cannot enable OpenGL ES 2 support without EGL enabled.
Gustavo ?
Thomas
Thomas Petazzoni
2016-01-26 13:26:18 UTC
Permalink
Joao,
Post by Joao Pinto
Could you tell me what changed in the Buildroot ecosystem to generate such "new"
errors?
So you're talking about the mplayer failure on AArch64. I believe the
main change that took place is that after you enabled it on AArch64,
mplayer was bumped to version 1.2. Maybe the AArch64 build problem
appeared with the bump to version 1.2.

Could you investigate if that's the case, if mplayer upstream already
has a fix for the issue, and if not, see if the issue can be fixed
easily ?

Thanks,

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
Joao Pinto
2016-01-27 11:37:31 UTC
Permalink
Hi,

Just checked and apparently MPlayer 1.2.x already supports AARCH64 so I think
the patch
https://git.busybox.net/buildroot/commit/?id=c93805207e24df082495f4d050bc2f29f3d19dd6
is no longer necessary.
Post by Thomas Petazzoni
Joao,
Post by Joao Pinto
Could you tell me what changed in the Buildroot ecosystem to generate such "new"
errors?
So you're talking about the mplayer failure on AArch64. I believe the
main change that took place is that after you enabled it on AArch64,
mplayer was bumped to version 1.2. Maybe the AArch64 build problem
appeared with the bump to version 1.2.
Could you investigate if that's the case, if mplayer upstream already
has a fix for the issue, and if not, see if the issue can be fixed
easily ?
Thanks,
Thomas
Thanks,
Joao
Thomas Petazzoni
2016-01-27 12:16:16 UTC
Permalink
Dear Joao Pinto,
Post by Joao Pinto
Just checked and apparently MPlayer 1.2.x already supports AARCH64 so I think
the patch
https://git.busybox.net/buildroot/commit/?id=c93805207e24df082495f4d050bc2f29f3d19dd6
is no longer necessary.
Sorry, I don't understand. You're talking about MPlayer, which clearly
doesn't build for AArch64, and you point to a commit about sysvinit.

Could you explain ?

Thanks,

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
Joao Pinto
2016-01-27 14:25:29 UTC
Permalink
Dear Thomas,

Wrong commit, sorry.
Please consider this one:
https://git.busybox.net/buildroot/commit/?id=1fc839e436a2a745bc7996545b1f60df5670df63

Joao
Post by Thomas Petazzoni
Dear Joao Pinto,
Post by Joao Pinto
Just checked and apparently MPlayer 1.2.x already supports AARCH64 so I think
the patch
https://git.busybox.net/buildroot/commit/?id=c93805207e24df082495f4d050bc2f29f3d19dd6
is no longer necessary.
Sorry, I don't understand. You're talking about MPlayer, which clearly
doesn't build for AArch64, and you point to a commit about sysvinit.
Could you explain ?
Thanks,
Thomas
Thomas Petazzoni
2016-01-27 15:09:57 UTC
Permalink
Joao,
Post by Joao Pinto
Wrong commit, sorry.
https://git.busybox.net/buildroot/commit/?id=1fc839e436a2a745bc7996545b1f60df5670df63
I still don't understand. The previous version of MPlayer was building
fine for AArch64, so you enabled support for AArch64, which was good.

But now, because there is a regression on the new version of MPlayer
which makes it fail to build on AArch64, you want to completely disable
the MPlayer package for AArch64 ? It seems like a very strange
solution. Instead, what about investigating the regression and fixing
it ?

Thanks,

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
Joao Pinto
2016-01-27 15:13:40 UTC
Permalink
Thomas,

According to the MPlayer team, version 1.2.x already supports AARCH64, so there
is no sense on applying the patch for this new version.
Post by Thomas Petazzoni
Joao,
Post by Joao Pinto
Wrong commit, sorry.
https://git.busybox.net/buildroot/commit/?id=1fc839e436a2a745bc7996545b1f60df5670df63
I still don't understand. The previous version of MPlayer was building
fine for AArch64, so you enabled support for AArch64, which was good.
But now, because there is a regression on the new version of MPlayer
which makes it fail to build on AArch64, you want to completely disable
the MPlayer package for AArch64 ? It seems like a very strange
solution. Instead, what about investigating the regression and fixing
it ?
Thanks,
Thomas
Joao
Bernd Kuhls
2016-01-26 21:06:01 UTC
Permalink
Post by Thomas Petazzoni
Post by Thomas Petazzoni
arm | aumix-2.8 | NOK |
http://autobuild.buildroot.net/results/
c8c7f9a799d1af507a6edd5e02b0bbc8b7b5d068/
Post by Thomas Petazzoni
gettext/libintl handling issue.
Hi Thomas,

fixed by http://patchwork.ozlabs.org/patch/573473/

Regards, Bernd
Peter Korsgaard
2016-01-27 17:18:46 UTC
Permalink
Hi,
Post by Thomas Petazzoni
Post by Thomas Petazzoni
x86_64 | madplay-0.15.2b | NOK | http://autobuild.buildroot.net/results/2561190b274d71666c4bdf3c569b02063cefdb30/
./relocatable.c:402:40: error: 'INSTALLPREFIX' undeclared (first use in this function)
const char *orig_installprefix = INSTALLPREFIX;
Musl related ? Not sure. Peter, you added the madplay package back in
2007, so can you have a look ? :-)
Heh, I don't recall any details from 2007 - But I've taken a look and
pushed a fix. It was indeed musl related.
--
Venlig hilsen,
Peter Korsgaard
Max Filippov
2016-02-03 09:37:10 UTC
Permalink
On Fri, Jan 22, 2016 at 12:29 PM, Thomas Petazzoni
Post by Thomas Petazzoni
Post by Thomas Petazzoni
xtensa | mp4v2-2.0.0 | NOK | http://autobuild.buildroot.net/results/bff7436a800eeea92c0c92bd2846b0f2b31947fd/
/tmp/cchH5TCg.s:23436: Error: value of 38619 too large for field of 2 bytes at 2889
Toolchain problem. Max can you have a look ?
Fixed by https://patchwork.ozlabs.org/patch/577797/
--
Thanks.
-- Max
Ricardo Martincoski
2016-01-23 12:33:20 UTC
Permalink
Post by Thomas Petazzoni
Post by Thomas Petazzoni
i686 | libsoil-20080707 | NOK | http://autobuild.buildroot.net/results/8ff91ab8e52000eb34dd8f662520cf1b31490cf5/
x86_64 | libsoil-20080707 | NOK | http://autobuild.buildroot.net/results/ea77d6b23aca0cb1cf527e6c16ddf5eba957a69c/
These are really weird. The patch doesn't apply when the build takes
place on my build server, but it does apply when I test things locally
on my machine. A difference in the version of patch ?
This error occurs when applying a patch that changes a file with spaces
in the name.
When applying a patch generated by diff v3.3 (the newest version [2]),
the tool patch needs to be version 2.7 or any later to ensure any patch
will be applied.
libsoil is the only package today that patches a file with space in the
name.


Using patch v2.6:
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 23.
2 out of 2 hunks FAILED -- saving rejects to file 'projects/makefile/alternate Makefile.txt".rej'
Patch failed! Please fix 0001-fix-makefile.patch!

Using patch v2.6.1:
can't find file to patch at input line 11
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Various makefile fixes to allow cross compilation
|
|Partly ported from
|http://anonscm.debian.org/cgit/pkg-games/libsoil.git/tree/debian/patches/linking_correctly.patch
|
|Signed-off-by: Bernd Kuhls <***@t-online.de>
|
|diff -uNr "soil.org/projects/makefile/alternate Makefile.txt" "soil/projects/makefile/alternate Makefile.txt"
|--- "soil.org/projects/makefile/alternate Makefile.txt" 2008-07-07 18:13:28.000000000 +0200
|+++ "soil/projects/makefile/alternate Makefile.txt" 2015-11-07 11:15:04.140106336 +0100
--------------------------
No file to patch. Skipping patch.
2 out of 2 hunks ignored
Patch failed! Please fix 0001-fix-makefile.patch!


The output of "diff -purN" when there are spaces in the name of a
changed file depends on the tool version:
diff <= v3.2 does not add double quotes to filenames
diff >= v3.3 adds double quotes to filenames

The tool 'patch' can handle patches with spaces in the name of a
changed file depending on the tool version:
patch >= 2.5.9 can handle unquoted filenames
patch >= 2.7 can handle both quoted and unquoted filenames


Solution 1: Add patch >= 2.7 as prerequisite to the manual (patch v2.7
is from 2012 [2]).
http://patchwork.ozlabs.org/patch/572097/

Solution 2: Add patch >= 2.5.9 as prerequisite to the manual (patch
v2.5.9 is from 2004 [2]), address on the manual
'Format and licensing of the package patches' the workaround needed when
a file changed by a patch has spaces in its name, apply the workaround
to libsoil (either use diff 3.2 or manually remove the quotes from the
filename inside the patch).

Solution 3: Create host-patch. Almost every package would depend on it.
I don't known if it would be feasible since gcc has patches.


[1] http://ftp.gnu.org/gnu/diffutils/
[2] http://ftp.gnu.org/gnu/patch/

I didn't investigate other formats of patch, e.g. git patch.

Regards,
Ricardo
Thomas Petazzoni
2016-01-23 12:55:47 UTC
Permalink
Ricardo,

First of all, thanks a lot for this great investigation! Definitely
very useful!
Post by Ricardo Martincoski
This error occurs when applying a patch that changes a file with spaces
in the name.
When applying a patch generated by diff v3.3 (the newest version [2]),
the tool patch needs to be version 2.7 or any later to ensure any patch
will be applied.
libsoil is the only package today that patches a file with space in the
name.
Aah, this explains the problem. My build server has patch version 2.6.
Post by Ricardo Martincoski
Solution 1: Add patch >= 2.7 as prerequisite to the manual (patch v2.7
is from 2012 [2]).
http://patchwork.ozlabs.org/patch/572097/
Not really acceptable, as we want to support old distros. Especially
when this is really needed only for one package.
Post by Ricardo Martincoski
Solution 2: Add patch >= 2.5.9 as prerequisite to the manual (patch
v2.5.9 is from 2004 [2]), address on the manual
'Format and licensing of the package patches' the workaround needed when
a file changed by a patch has spaces in its name, apply the workaround
to libsoil (either use diff 3.2 or manually remove the quotes from the
filename inside the patch).
Seems like the best solution. Can you cook such patches (both to the
manual, and the change to libsoil) ?

BTW, why would we need to require patch >= 2.5.9 ? Just to support file
name with spaces ?
Post by Ricardo Martincoski
Solution 3: Create host-patch. Almost every package would depend on it.
I don't known if it would be feasible since gcc has patches.
We only build gcc for the target, so we could certainly build
host-patch. However, this really seems overkill to solve the problem of
just one package, for which there is a separate solution (your solution
2).

Thanks again for your investigation. I'm looking forward to seeing your
patches implementing solution (2).

Best regards,

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
Thomas De Schampheleire
2016-01-23 13:03:33 UTC
Permalink
On Jan 23, 2016 1:56 PM, "Thomas Petazzoni" <
Post by Thomas Petazzoni
Ricardo,
First of all, thanks a lot for this great investigation! Definitely
very useful!
Post by Ricardo Martincoski
This error occurs when applying a patch that changes a file with spaces
in the name.
When applying a patch generated by diff v3.3 (the newest version [2]),
the tool patch needs to be version 2.7 or any later to ensure any patch
will be applied.
libsoil is the only package today that patches a file with space in the
name.
Aah, this explains the problem. My build server has patch version 2.6.
Post by Ricardo Martincoski
Solution 1: Add patch >= 2.7 as prerequisite to the manual (patch v2.7
is from 2012 [2]).
http://patchwork.ozlabs.org/patch/572097/
Not really acceptable, as we want to support old distros. Especially
when this is really needed only for one package.
Post by Ricardo Martincoski
Solution 2: Add patch >= 2.5.9 as prerequisite to the manual (patch
v2.5.9 is from 2004 [2]), address on the manual
'Format and licensing of the package patches' the workaround needed when
a file changed by a patch has spaces in its name, apply the workaround
to libsoil (either use diff 3.2 or manually remove the quotes from the
filename inside the patch).
Seems like the best solution. Can you cook such patches (both to the
manual, and the change to libsoil) ?
BTW, why would we need to require patch >= 2.5.9 ? Just to support file
name with spaces ?
Post by Ricardo Martincoski
Solution 3: Create host-patch. Almost every package would depend on it.
I don't known if it would be feasible since gcc has patches.
We only build gcc for the target, so we could certainly build
host-patch. However, this really seems overkill to solve the problem of
just one package, for which there is a separate solution (your solution
2).
Thanks again for your investigation. I'm looking forward to seeing your
patches implementing solution (2).
What happens if you first make a symlink alternate_makefile -> 'alternate
makefile' and apply the patch on the link? Will patch modify the linked
file?

If so it could be an alternative solution.

/Thomas
Ricardo Martincoski
2016-01-23 13:56:00 UTC
Permalink
date: Sat, Jan 23 02:03 PM +01:00 2016
subject: Re: [Buildroot] Analysis of build failures
On Jan 23, 2016 1:56 PM, "Thomas Petazzoni" <
Post by Thomas Petazzoni
Ricardo,
First of all, thanks a lot for this great investigation! Definitely
very useful!
Post by Ricardo Martincoski
This error occurs when applying a patch that changes a file with spaces
in the name.
When applying a patch generated by diff v3.3 (the newest version [2]),
the tool patch needs to be version 2.7 or any later to ensure any patch
will be applied.
libsoil is the only package today that patches a file with space in the
name.
Aah, this explains the problem. My build server has patch version 2.6.
Post by Ricardo Martincoski
Solution 1: Add patch >= 2.7 as prerequisite to the manual (patch v2.7
is from 2012 [2]).
http://patchwork.ozlabs.org/patch/572097/
Not really acceptable, as we want to support old distros. Especially
when this is really needed only for one package.
Ok. I changed the state of this patch to Rejected.
Post by Thomas Petazzoni
Post by Ricardo Martincoski
Solution 2: Add patch >= 2.5.9 as prerequisite to the manual (patch
v2.5.9 is from 2004 [2]), address on the manual
'Format and licensing of the package patches' the workaround needed when
a file changed by a patch has spaces in its name, apply the workaround
to libsoil (either use diff 3.2 or manually remove the quotes from the
filename inside the patch).
Seems like the best solution. Can you cook such patches (both to the
manual, and the change to libsoil) ?
Yes. No problem.
Post by Thomas Petazzoni
BTW, why would we need to require patch >= 2.5.9 ? Just to support file
name with spaces ?
Yes.
Post by Thomas Petazzoni
Post by Ricardo Martincoski
Solution 3: Create host-patch. Almost every package would depend on it.
I don't known if it would be feasible since gcc has patches.
We only build gcc for the target, so we could certainly build
host-patch. However, this really seems overkill to solve the problem of
just one package, for which there is a separate solution (your solution
2).
Thanks again for your investigation. I'm looking forward to seeing your
patches implementing solution (2).
What happens if you first make a symlink alternate_makefile -> 'alternate
makefile' and apply the patch on the link? Will patch modify the linked
file?
I tested using patch 2.6.
Unfortunately patch breaks the symlink, so I end up with alternate_makefile
patched but 'alternate makefile' remains unpatched.
If so it could be an alternative solution.
/Thomas
Regards,
Ricardo
Thomas De Schampheleire
2016-01-23 14:26:13 UTC
Permalink
On Jan 23, 2016 2:56 PM, "Ricardo Martincoski" <
On Sat, Jan 23, 2016 at 11:03 AM, Thomas De Schampheleire <
date: Sat, Jan 23 02:03 PM +01:00 2016
subject: Re: [Buildroot] Analysis of build failures
On Jan 23, 2016 1:56 PM, "Thomas Petazzoni" <
Post by Thomas Petazzoni
Ricardo,
First of all, thanks a lot for this great investigation! Definitely
very useful!
Post by Ricardo Martincoski
This error occurs when applying a patch that changes a file with spaces
in the name.
When applying a patch generated by diff v3.3 (the newest version [2]),
the tool patch needs to be version 2.7 or any later to ensure any patch
will be applied.
libsoil is the only package today that patches a file with space in the
name.
Aah, this explains the problem. My build server has patch version 2.6.
Post by Ricardo Martincoski
Solution 1: Add patch >= 2.7 as prerequisite to the manual (patch v2.7
is from 2012 [2]).
http://patchwork.ozlabs.org/patch/572097/
Not really acceptable, as we want to support old distros. Especially
when this is really needed only for one package.
Ok. I changed the state of this patch to Rejected.
Post by Thomas Petazzoni
Post by Ricardo Martincoski
Solution 2: Add patch >= 2.5.9 as prerequisite to the manual (patch
v2.5.9 is from 2004 [2]), address on the manual
'Format and licensing of the package patches' the workaround needed when
a file changed by a patch has spaces in its name, apply the workaround
to libsoil (either use diff 3.2 or manually remove the quotes from the
filename inside the patch).
Seems like the best solution. Can you cook such patches (both to the
manual, and the change to libsoil) ?
Yes. No problem.
Post by Thomas Petazzoni
BTW, why would we need to require patch >= 2.5.9 ? Just to support file
name with spaces ?
Yes.
Post by Thomas Petazzoni
Post by Ricardo Martincoski
Solution 3: Create host-patch. Almost every package would depend on it.
I don't known if it would be feasible since gcc has patches.
We only build gcc for the target, so we could certainly build
host-patch. However, this really seems overkill to solve the problem of
just one package, for which there is a separate solution (your solution
2).
Thanks again for your investigation. I'm looking forward to seeing your
patches implementing solution (2).
What happens if you first make a symlink alternate_makefile -> 'alternate
makefile' and apply the patch on the link? Will patch modify the linked
file?
I tested using patch 2.6.
Unfortunately patch breaks the symlink, so I end up with
alternate_makefile
patched but 'alternate makefile' remains unpatched.
I guess a hard link would work here, then. Care to try?

Thanks,
Thomas
Thomas Petazzoni
2016-01-23 14:42:20 UTC
Permalink
Thomas,
Post by Thomas De Schampheleire
I guess a hard link would work here, then. Care to try?
But why would we do that? If I understood Ricardo's e-mail, a simple
change to the patch (remove the double quotes) would make it just work.

So why are we looking for a complicated solution here ?

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
Ricardo Martincoski
2016-01-23 15:16:00 UTC
Permalink
Post by Thomas Petazzoni
Post by Thomas De Schampheleire
I guess a hard link would work here, then. Care to try?
Between the 2 e-mails I tested using hard link.
Using patch v2.6, the hardlinks get unlinked too.

patch v2.7.1 has --follow-symlinks but its use is discouraged in the man page.
Post by Thomas Petazzoni
But why would we do that? If I understood Ricardo's e-mail, a simple
change to the patch (remove the double quotes) would make it just work.
So why are we looking for a complicated solution here ?
Just to be clear, removing the double quotes makes it work with
patch 2.5.9 or later.
Patch 2.5.4 can't handle spaces in filenames.
(I tested using only the versions with tarballs available, that's the cause of
the gap 2.5.9 -> 2.5.4, see http://ftp.gnu.org/gnu/patch/)

I am sending the first version of the patch series.
Probably it will need some rewording, since it's my first patch to the manual.

Regards,
Ricardo
Thomas Petazzoni
2016-01-23 15:58:16 UTC
Permalink
Hello,
Post by Ricardo Martincoski
Just to be clear, removing the double quotes makes it work with
patch 2.5.9 or later.
Patch 2.5.4 can't handle spaces in filenames.
(I tested using only the versions with tarballs available, that's the cause of
the gap 2.5.9 -> 2.5.4, see http://ftp.gnu.org/gnu/patch/)
RHEL4 uses patch 2.5.4
(http://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/os/i386/SRPMS/).
RHEL4 was released January 2005

RHEL5 also seems to be using patch 2.5.4
(http://ftp.redhat.com/pub/redhat/linux/enterprise/5Client/en/os/SRPMS/).
RHEL5 was released March 2007.

It's only starting at RHEL6 that patch 2.6 starts to be used
(http://ftp.redhat.com/pub/redhat/linux/enterprise/6Client/en/os/SRPMS/).
RHEL6 was released November 2010.

Thomas DS, you are one of our users relying on very old enterprise
distros. Are you still on RHEL 4/5 ?

Best regards,

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
Thomas De Schampheleire
2016-01-23 16:07:29 UTC
Permalink
On Jan 23, 2016 4:58 PM, "Thomas Petazzoni" <
Post by Thomas Petazzoni
Hello,
Post by Ricardo Martincoski
Just to be clear, removing the double quotes makes it work with
patch 2.5.9 or later.
Patch 2.5.4 can't handle spaces in filenames.
(I tested using only the versions with tarballs available, that's the cause of
the gap 2.5.9 -> 2.5.4, see http://ftp.gnu.org/gnu/patch/)
RHEL4 uses patch 2.5.4
(http://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/os/i386/SRPMS/).
RHEL4 was released January 2005
RHEL5 also seems to be using patch 2.5.4
(http://ftp.redhat.com/pub/redhat/linux/enterprise/5Client/en/os/SRPMS/).
RHEL5 was released March 2007.
It's only starting at RHEL6 that patch 2.6 starts to be used
(http://ftp.redhat.com/pub/redhat/linux/enterprise/6Client/en/os/SRPMS/).
RHEL6 was released November 2010.
Thomas DS, you are one of our users relying on very old enterprise
distros. Are you still on RHEL 4/5 ?
There are some of our users still on RHEL4 (hopefully not too much anymore)
and RHEL5 (not negligible yet).

That said, libsoil is not something we use, so if the problem is limited to
that we're fine.

/Thomas
Ricardo Martincoski
2016-01-23 17:14:22 UTC
Permalink
Hello,
Post by Thomas De Schampheleire
On Jan 23, 2016 4:58 PM, "Thomas Petazzoni" <
Post by Thomas Petazzoni
Hello,
Post by Ricardo Martincoski
Just to be clear, removing the double quotes makes it work with
patch 2.5.9 or later.
Patch 2.5.4 can't handle spaces in filenames.
(I tested using only the versions with tarballs available, that's the
cause of
Post by Thomas Petazzoni
Post by Ricardo Martincoski
the gap 2.5.9 -> 2.5.4, see http://ftp.gnu.org/gnu/patch/)
RHEL4 uses patch 2.5.4
(http://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/os/i386/SRPMS/).
RHEL4 was released January 2005
RHEL5 also seems to be using patch 2.5.4
(http://ftp.redhat.com/pub/redhat/linux/enterprise/5Client/en/os/SRPMS/).
RHEL5 was released March 2007.
It's only starting at RHEL6 that patch 2.6 starts to be used
(http://ftp.redhat.com/pub/redhat/linux/enterprise/6Client/en/os/SRPMS/).
RHEL6 was released November 2010.
Thomas DS, you are one of our users relying on very old enterprise
distros. Are you still on RHEL 4/5 ?
There are some of our users still on RHEL4 (hopefully not too much anymore)
and RHEL5 (not negligible yet).
That said, libsoil is not something we use, so if the problem is limited to
that we're fine.
/Thomas
Maybe there is a solution that does not limit the version of patch, following
the idea of symlinks or hardlinks.
It still needs more tests, but it seems to work with patch 2.5.4.
I created 2 hooks, one before patching to rename the file, and other after to
rename it back.

See example below. I used POST_EXTRACT instead of PRE_PATCH because some
developer could use 'make package-extract', create a copy of the extracted
directory, edit the needed files and then use diff to create the patch.
This way hand-editing the patch would not be needed.

Please let me know if you agree with this approach.

Regards,
Ricardo

diff --git package/libsoil/0001-fix-makefile.patch package/libsoil/0001-fix-makefile.patch
index 3b80048..310d264 100644
--- package/libsoil/0001-fix-makefile.patch
+++ package/libsoil/0001-fix-makefile.patch
@@ -5,9 +5,9 @@ http://anonscm.debian.org/cgit/pkg-games/libsoil.git/tree/debian/patches/linking

Signed-off-by: Bernd Kuhls <***@t-online.de>

-diff -uNr "soil.org/projects/makefile/alternate Makefile.txt" "soil/projects/makefile/alternate Makefile.txt"
---- "soil.org/projects/makefile/alternate Makefile.txt" 2008-07-07 18:13:28.000000000 +0200
-+++ "soil/projects/makefile/alternate Makefile.txt" 2015-11-07 11:15:04.140106336 +0100
+diff -uNr soil.org/projects/makefile/alternate_Makefile.txt soil/projects/makefile/alternate_Makefile.txt
+--- soil.org/projects/makefile/alternate_Makefile.txt 2008-07-07 18:13:28.000000000 +0200
++++ soil/projects/makefile/alternate_Makefile.txt 2015-11-07 11:15:04.140106336 +0100
@@ -1,8 +1,8 @@
MAKE = make
-CC = gcc
diff --git package/libsoil/libsoil.mk package/libsoil/libsoil.mk
index eb8c2ce..1aca345 100644
--- package/libsoil/libsoil.mk
+++ package/libsoil/libsoil.mk
@@ -18,6 +18,18 @@ define LIBSOIL_EXTRACT_CMDS
mv $(@D)/Simple\ OpenGL\ Image\ Library/* $(@D)
endef

+define REMOVE_SPACE_FROM_FILENAME
+ cd $(@D)/projects/makefile/ && \
+ mv alternate\ Makefile.txt alternate_Makefile.txt
+endef
+LIBSOIL_POST_EXTRACT_HOOKS += REMOVE_SPACE_FROM_FILENAME
+
+define ADD_SPACE_BACK_TO_FILENAME
+ cd $(@D)/projects/makefile/ && \
+ mv alternate_Makefile.txt alternate\ Makefile.txt
+endef
+LIBSOIL_POST_PATCH_HOOKS += ADD_SPACE_BACK_TO_FILENAME
+
define LIBSOIL_BUILD_CMDS
$(MAKE) $(TARGET_CONFIGURE_OPTS) -f $(LIBSOIL_MAKEFILE) \
-C $(@D)/src
Thomas Petazzoni
2016-01-23 20:48:22 UTC
Permalink
Ricardo,
Post by Ricardo Martincoski
Maybe there is a solution that does not limit the version of patch, following
the idea of symlinks or hardlinks.
It still needs more tests, but it seems to work with patch 2.5.4.
I created 2 hooks, one before patching to rename the file, and other after to
rename it back.
See example below. I used POST_EXTRACT instead of PRE_PATCH because some
developer could use 'make package-extract', create a copy of the extracted
directory, edit the needed files and then use diff to create the patch.
This way hand-editing the patch would not be needed.
Please let me know if you agree with this approach.
I think you can remove the post patch hook, i.e keep the file named
with the _, and simply adjust:

LIBSOIL_MAKEFILE = "../projects/makefile/alternate Makefile.txt"

to:

LIBSOIL_MAKEFILE = ../projects/makefile/alternate_Makefile.txt

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
Continue reading on narkive:
Loading...