* [Buildroot] [autobuild.buildroot.net] Build results for 2017-02-16
2017-02-17 21:12 ` Yann E. MORIN
@ 2017-02-17 22:01 ` Yann E. MORIN
2017-02-17 22:02 ` Waldemar Brodkorb
` (3 subsequent siblings)
4 siblings, 0 replies; 19+ messages in thread
From: Yann E. MORIN @ 2017-02-17 22:01 UTC (permalink / raw)
To: buildroot
All,
On 2017-02-17 22:12 +0100, Yann E. MORIN spake thusly:
> > i686 | freerdp-17834af7bb378f85a3b... | NOK | http://autobuild.buildroot.net/results/b7f95e39d5b6984594fbf1e7549ddb3cf281600c
> Tries to link with host libraries. I'll take it.
I was not able to reproduce... :-(
> > or1k | gpsd-3.16 | NOK | http://autobuild.buildroot.net/results/c24dd55e773167be182f40ae723e82d3f71c6eba
> error: field 'uc_mcontext' has incomplete type
Waldemar has sent a patch to fix all those ucontext issues on or1k:
https://patchwork.ozlabs.org/patch/729373/
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 19+ messages in thread* [Buildroot] [autobuild.buildroot.net] Build results for 2017-02-16
2017-02-17 21:12 ` Yann E. MORIN
2017-02-17 22:01 ` Yann E. MORIN
@ 2017-02-17 22:02 ` Waldemar Brodkorb
2017-02-18 8:49 ` Peter Korsgaard
` (2 subsequent siblings)
4 siblings, 0 replies; 19+ messages in thread
From: Waldemar Brodkorb @ 2017-02-17 22:02 UTC (permalink / raw)
To: buildroot
Hi Yann,
Yann E. MORIN wrote,
> Fabrice, J?rg, Simon, Jonathan, Will, James, Gustavo, Wojciech,
> Waldemar, Bernd, Adam, Eric, Julien B., Julien C., Peter, Vicente,
> Cyril, Sam, Samuel, Spenser,
>
> There are questions for each of you below. Could you please take a
> moment to have a look?
>
> On 2017-02-17 08:28 +0100, Thomas Petazzoni spake thusly:
> > or1k | alljoyn-16.04.00a | NOK | http://autobuild.buildroot.net/results/cd963404761070623489ee74df3e69f5052f40a1
> > or1k | alljoyn-16.04.00a | NOK | http://autobuild.buildroot.net/results/99e6e01f0d85fe8eb5d9b09fcc3971b577c9ba6b
> > or1k | alljoyn-16.04.00a | NOK | http://autobuild.buildroot.net/results/e5b471dbb91ef2a15844a9ee6d1a83a38f7cc07d
>
> error: 'printf' was not declared in this scope
>
> Fabrice?
There is already a patch on the list, it is just unclear why this is
only happening for or1k toolchain. Maybe an issue in the modified gcc
5, which is in use.
> > i586 | bctoolbox-0.4.0 | NOK | http://autobuild.buildroot.net/results/bd4cca6e7706a68dd6c16a7bb409185c9f006a57
> > m68k | bctoolbox-0.4.0 | NOK | http://autobuild.buildroot.net/results/4118477ac02732b99b8bb3db8bef43290edbc5de
>
> Neither mbedtls nor poarslsl detected. Patches by J?rg on the list (in
> this order):
> https://patchwork.ozlabs.org/patch/728005/
> https://patchwork.ozlabs.org/patch/728007/
> https://patchwork.ozlabs.org/patch/728004/
> https://patchwork.ozlabs.org/patch/728006/
>
> > arm | czmq-5205ec201e97c3a652c17e... | NOK | http://autobuild.buildroot.net/results/9d0cbb045a21d6b97d33f791c90eacd84198dee8
> > arm | czmq-5205ec201e97c3a652c17e... | NOK | http://autobuild.buildroot.net/results/5179aade1ddfe3975b17f49b534e84ba1a55bdab
> > arm | czmq-5205ec201e97c3a652c17e... | NOK | http://autobuild.buildroot.net/results/9330594ec5870f255edd8a2df81052257d228cfd
> > arm | czmq-5205ec201e97c3a652c17e... | NOK | http://autobuild.buildroot.net/results/0b87eb16d3bdef25e618f5c54181d18a465ef655
>
> undefined reference to `pthread_cancel_init'
> undefined reference to `__libgcc_s_resume'
>
> Probably needs NPTL. Simon?
uClibc-ng static ARM issue, patch sent.
> > or1k | dawgdic-16ac537ba9883ff01b6... | NOK | http://autobuild.buildroot.net/results/81047e13f4d7896abae1036e098303e6bf68a0e7
>
> error: 'strtoll' is not a member of 'std'
>
> C+11 stuff... Jonathan?
>
> > mips64el | dbus-1.10.16 | NOK | http://autobuild.buildroot.net/results/2a4d8539c2a325eec5ade5e06452294e32cb12b7
>
> Transient download error. Ignore.
>
> > arm | enchant-1.6.0 | NOK | http://autobuild.buildroot.net/results/70d72b5e767965726a1e5eca437f3efc4af92c86
>
> multiple definition of `_Unwind_Resume'
> undefined reference to `pthread_cancel_init'
> undefined reference to `__libgcc_s_resume'
>
> Probably needs NPTL. Will?
uClibc-ng static ARM issue, patch sent.
> > i686 | freerdp-17834af7bb378f85a3b... | NOK | http://autobuild.buildroot.net/results/b7f95e39d5b6984594fbf1e7549ddb3cf281600c
>
> Tries to link with host libraries. I'll take it.
>
> > arm | glibmm-2.50.0 | NOK | http://autobuild.buildroot.net/results/fb14e37aaf453874d1c33e5ed73b9c751ace5ae3
> > arm | glibmm-2.50.0 | NOK | http://autobuild.buildroot.net/results/774a8dd489760bc213ac7cf3e8040cee6a4e2437
> > arm | glibmm-2.50.0 | NOK | http://autobuild.buildroot.net/results/80aba6b26a21914197388baf73ada4b79952db13
> > arm | glibmm-2.50.0 | NOK | http://autobuild.buildroot.net/results/a2bda0553eff5e415e622aa7a38763d838ae43c2
>
> multiple definition of `_Unwind_Resume'
> undefined reference to `pthread_cancel_init'
> undefined reference to `__libgcc_s_resume'
>
> Probably needs NPTL. James?
uClibc-ng static ARM issue, patch sent.
> > or1k | gpsd-3.16 | NOK | http://autobuild.buildroot.net/results/c24dd55e773167be182f40ae723e82d3f71c6eba
>
> error: field 'uc_mcontext' has incomplete type
>
> Some ucontext issue on or1k (see below, there are more)... Waldemar, Gustavo?
uClibc-ng or1k issue, patch sent.
> > or1k | gstreamer1-1.10.3 | NOK | http://autobuild.buildroot.net/results/717d78ce0935749f477bdf3133b6f20057a28c01
>
> error "Could not detect architecture; don't know whether it supports
> unaligned access! Please file a bug."
>
> Not available on or1k? Gustavo?
>
> > or1k | jack2-v1.9.10 | NOK | http://autobuild.buildroot.net/results/470eac9012c5a551ace8079e1bdb3ffbc5a73c1e
>
> Again some ucontext issue on or1k. Waldemar, Wojciech?
uClibc-ng or1k issue, patch sent.
> > or1k | jsoncpp-1.7.7 | NOK | http://autobuild.buildroot.net/results/8d5145eaca2939206b88ea5abfef9bd11fefca69
>
> error: 'snprintf' is not a member of 'std'
>
> Some C++11 trickery again? Bernd?
Maybe something similar to alljoyn issue?
> > microblazeel | kmod-23 | NOK | http://autobuild.buildroot.net/results/aef1b915ffd3e5678af8682727c22c5618edfd89
>
> collect2: fatal error: ld terminated with signal 11 [Segmentation fault]
>
> Spenser?
Interesting. uClibc-ng toolchain, I will take a look.
> > x86_64 | libcec-4.0.2 | NOK | http://autobuild.buildroot.net/results/e7505f36d7c2cfaf7527515b2e3014c2e8e2c5ca
>
> undefined reference to `std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> >::basic_string
> (std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> >&&)@GLIBCXX_3.4.21'
>
> Some ugly C++11 issue? Bernd?
>
> > aarch64 | libepoxy-v1.3.1 | NOK | http://autobuild.buildroot.net/results/0a266f54e2938f7479232b7acec1834250f6c064
>
> error: conflicting types for 'khronos_uint64_t'
>
> Gustavo?
>
> > or1k | libnfc-1.7.1 | NOK | http://autobuild.buildroot.net/results/d8715a2b3783d877edf91bb14a80d36eac749b36
>
> Yet another or1k ucontext issue... Waldemar, Simon?
uClibc-ng or1k issue, patch sent.
> > microblazeel | libnss-3.27.2 | NOK | http://autobuild.buildroot.net/results/638a65453879777a0d5bdb29231034cd261b41c0
>
> collect2: fatal error: ld terminated with signal 11 [Segmentation fault]
>
> Booo... Spenser, any idea?
>
> > microblazeel | make[4]: *** [all-recursive... | TIM | http://autobuild.buildroot.net/results/92c165a970b9d8912c5ca50ed3567478cd2a2b3d
>
> Timeout, but weird: the ffmpeg build started at 3850 seconds (a bit more
> than one hour) and the timeout is supposed to be 8h, so the ffmpeg build
> did not finish after about 7h...
>
> > i686 | mplayer-1.3.0 | NOK | http://autobuild.buildroot.net/results/8ace02ec35eaa691c65c95240ecf7caa8137ea70
>
> error: 'asm' operand has impossible constraints
> __asm__ volatile(
>
> Bernd?
>
> > powerpc64le | mpv-0.23.0 | NOK | http://autobuild.buildroot.net/results/4ba59ebb2cd16ed7e70c67e89f5f80c5b803d3c3
> > powerpc64 | mpv-0.23.0 | NOK | http://autobuild.buildroot.net/results/b97341c59b9c6f7dbdfe59cd770e0c285be8fa06
> > powerpc64le | mpv-0.23.0 | NOK | http://autobuild.buildroot.net/results/741535d8d9c75acebeff96679d4f1ac6ecbc5f61
>
> Patch on the list:
> https://patchwork.ozlabs.org/patch/706869/
>
> > sh4a | opencv-2.4.13 | NOK | http://autobuild.buildroot.net/results/2944568f9623f1377e987a1dadde5ea8cc428c5f
>
> error: 'SIZE_MAX' was not declared in this scope
>
> Missing header? Samuel?
>
> > arc | opentyrian-9c9f0ec3532b | NOK | http://autobuild.buildroot.net/results/89864a1cf0d8b27b3efdf3c36ccb3244e88a6746
>
> undefined reference to `dl_iterate_phdr'
> ld: GOT and PLT relocations cannot be fixed with a non dynamic linker
Some bells are ringing. We have a buildroot uclibc-ng toolchain with
BR2_STATIC_LIBS=y. But I see no explicit -static in CFLAGS/LDFLAGS
for this package, which might be the reason for the failure.
> Static linking issue. Julien B.?
>
> > x86_64 | oracle-mysql-5.1.73 | NOK | http://autobuild.buildroot.net/results/e9ff38bea523df79331de3004939ee39b446d723
>
> error: narrowing conversion [...] from 'char' to 'uchar...'
>
> Damn gcc6... ;-) Should be easy; any taker?
>
> > nios2 | qt5base-5.6.2 | NOK | http://autobuild.buildroot.net/results/a02c4da118c2d0f90016c5e3c8877782d6882f96
>
> ld: BFD (Sourcery CodeBench Lite 2016.11-32) 2.26.51 assertion fail
>
> > nios2 | qt5base-5.8.0 | NOK | http://autobuild.buildroot.net/results/116931f17c4eb4977638ca0392bd6024e05d4ff9
>
> #error Target architecture was not detected as supported by
> Double-Conversion.
>
> No qt5 on nios2?
>
> > arm | qt5base-5.8.0 | NOK | http://autobuild.buildroot.net/results/41a0559f0d3c760ba9aad77dea4ed43e25b63ac4
>
> Project ERROR: Library 'libpng' is not defined.
>
> But it is enabled in the build. Dependency issue?
>
> > arm | qt5base-5.8.0 | NOK | http://autobuild.buildroot.net/results/8f55bdbdce189c14baed772bb74eb41a0f8ce83c
>
> #error "ARM architecture too old"
>
> arm920t is an armv4. Surely we would not expect something big as Qt5 to
> stil work on such an old beast...
>
> Julien C., for the other three qt5 failures: any idea?
>
>
> > powerpc | qt5location-5.6.2 | NOK | http://autobuild.buildroot.net/results/1fd4195d3e941f4963a1957e4194b4e05e7bb909
>
> ld: BFD (crosstool-NG hg+-c65fcf8a34b7) 2.24 assertion fail
>
> Cyril, Gustavo, Sam: you're the PPC experts?
>
> > mipsel | qt5webkit-5.6.2 | NOK | http://autobuild.buildroot.net/results/48a78b16a63448e1ac91efa7ae0ca77b2b9dba49
>
> Error: opcode not supported on this processor: mips32r6 (mips32r6) `movz $v0,$t8,$t7'
>
> Julien C., Peter S., Vicente?
>
> > microblazeel | samba4-4.5.5 | NOK | http://autobuild.buildroot.net/results/d4f2f7381e1313758816b91aacad664240a2beac
>
> Needs NPTL, patch on the list:
> https://patchwork.ozlabs.org/patch/729320/
>
> > or1k | skalibs-2.4.0.2 | NOK | http://autobuild.buildroot.net/results/8cf276e18d935fe03059941f56786bfd210b700d
>
> error: field 'uc_mcontext' has incomplete type
>
> Again an or1k ucointext issue. Waldemar, Eric?
uClibc-ng or1k issue, patch sent.
> > microblazeel | slang-2.3.0 | NOK | http://autobuild.buildroot.net/results/716eced276823a225c30fd2534d88bfe0d90ac33
>
> undefined reference to `tputs'
>
> Needs ncurses, static linking issue?
>
> > x86_64 | sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/28c76e4125134b729f99099c3a53c1dcc55d0f12
> > arm | sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/558fd8acb31afd0a57c0c01020f73d9ee17a7bd9
> > arm | sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/fd599fd32ceab165a4926044e42f543c03179dec
> > xtensa | sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/3bba96405442dd97bdecfdc7865e4e13927fd327
> > arm | sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/7e96654503efcc79d386e13e23c21031738d493c
> > mips64el | sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/bd4c8eb1687713062e5b1ebbcde7f464c13779f1
> > x86_64 | sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/59f8410ba54e6ebbd7b65fd36f6b192a11f1262a
> > powerpc | sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/6ec46927ce16cf2b159805872ebef363c75e7551
> > arc | sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/8005ec840ac748970f6c4d49a3b5f1e2f1b69adc
>
> configure: error: You need to have ncurses forms library installed to
> compile sngrep.
>
> ncurses is disabled in this config. Adam?
>
> > arm | wavpack-5.1.0 | NOK | http://autobuild.buildroot.net/results/2d31a3295e51c5866fedae4adb0aa464e5079987
> > arm | wavpack-5.1.0 | NOK | http://autobuild.buildroot.net/results/e240455fc0bc6141988b5e1209f1a9b85b016361
>
> The wchar issue raised by Thomas upstream, which has a patch:
> https://github.com/dbry/WavPack/commit/876fc3f3907e871d0938ac6c8c5252f5f31abd1f
>
> Gustavo?
>
> Thank you all for looking in these issue! ;-)
best regards
Waldemar
^ permalink raw reply [flat|nested] 19+ messages in thread* [Buildroot] [autobuild.buildroot.net] Build results for 2017-02-16
2017-02-17 21:12 ` Yann E. MORIN
2017-02-17 22:01 ` Yann E. MORIN
2017-02-17 22:02 ` Waldemar Brodkorb
@ 2017-02-18 8:49 ` Peter Korsgaard
2017-02-20 12:41 ` Thomas Petazzoni
2017-02-24 14:37 ` Julien Boibessot
4 siblings, 0 replies; 19+ messages in thread
From: Peter Korsgaard @ 2017-02-18 8:49 UTC (permalink / raw)
To: buildroot
>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
Hi,
Thanks for the big review!
>> or1k | gstreamer1-1.10.3 | NOK |
>> http://autobuild.buildroot.net/results/717d78ce0935749f477bdf3133b6f20057a28c01
> error "Could not detect architecture; don't know whether it supports
> unaligned access! Please file a bug."
> Not available on or1k? Gustavo?
Gstreamer just needs to be told if or1k support unaligned access or
not. I don't know much about openrisc, but as it is mips like I would
think not.
Same issue for gstreamer 0.10. We already have logic in gstreamer1.mk to
handle this, but from a quick look it seems upstream no longer detects
this in the configure script but instead using a bunch of ifdefs in
gstconfig.h.
I will send patches to fix both gstreamer versions.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-02-16
2017-02-17 21:12 ` Yann E. MORIN
` (2 preceding siblings ...)
2017-02-18 8:49 ` Peter Korsgaard
@ 2017-02-20 12:41 ` Thomas Petazzoni
2017-02-20 14:59 ` Waldemar Brodkorb
` (3 more replies)
2017-02-24 14:37 ` Julien Boibessot
4 siblings, 4 replies; 19+ messages in thread
From: Thomas Petazzoni @ 2017-02-20 12:41 UTC (permalink / raw)
To: buildroot
Hello,
Thanks a lot for doing this analysis. A few comments below.
On Fri, 17 Feb 2017 22:12:42 +0100, Yann E. MORIN wrote:
> On 2017-02-17 08:28 +0100, Thomas Petazzoni spake thusly:
> > or1k | alljoyn-16.04.00a | NOK | http://autobuild.buildroot.net/results/cd963404761070623489ee74df3e69f5052f40a1
> > or1k | alljoyn-16.04.00a | NOK | http://autobuild.buildroot.net/results/99e6e01f0d85fe8eb5d9b09fcc3971b577c9ba6b
> > or1k | alljoyn-16.04.00a | NOK | http://autobuild.buildroot.net/results/e5b471dbb91ef2a15844a9ee6d1a83a38f7cc07d
>
> error: 'printf' was not declared in this scope
>
> Fabrice?
For this one and the jsoncpp-1.7.7 you reported below, what I find
weird is that they happen *only* on or1k. or1k is using gcc 5.x, and
lots of other architectures are using gcc 5.x.
So I would *really* like to understand why we get those alljoyn and
jsoncpp failures specifically on or1k and not on other architectures.
> > i586 | bctoolbox-0.4.0 | NOK | http://autobuild.buildroot.net/results/bd4cca6e7706a68dd6c16a7bb409185c9f006a57
> > m68k | bctoolbox-0.4.0 | NOK | http://autobuild.buildroot.net/results/4118477ac02732b99b8bb3db8bef43290edbc5de
>
> Neither mbedtls nor poarslsl detected. Patches by J?rg on the list (in
> this order):
> https://patchwork.ozlabs.org/patch/728005/
> https://patchwork.ozlabs.org/patch/728007/
> https://patchwork.ozlabs.org/patch/728004/
> https://patchwork.ozlabs.org/patch/728006/
I'll apply.
> > or1k | dawgdic-16ac537ba9883ff01b6... | NOK | http://autobuild.buildroot.net/results/81047e13f4d7896abae1036e098303e6bf68a0e7
>
> error: 'strtoll' is not a member of 'std'
>
> C+11 stuff... Jonathan?
Same or1k question as above: why does it happen only on or1k, and not
on other architectures?
> > arm | glibmm-2.50.0 | NOK | http://autobuild.buildroot.net/results/fb14e37aaf453874d1c33e5ed73b9c751ace5ae3
> > arm | glibmm-2.50.0 | NOK | http://autobuild.buildroot.net/results/774a8dd489760bc213ac7cf3e8040cee6a4e2437
> > arm | glibmm-2.50.0 | NOK | http://autobuild.buildroot.net/results/80aba6b26a21914197388baf73ada4b79952db13
> > arm | glibmm-2.50.0 | NOK | http://autobuild.buildroot.net/results/a2bda0553eff5e415e622aa7a38763d838ae43c2
>
> multiple definition of `_Unwind_Resume'
> undefined reference to `pthread_cancel_init'
> undefined reference to `__libgcc_s_resume'
>
> Probably needs NPTL. James?
Nope, nope, all those issues were issues in uClibc-ng. Waldemar has
sent a patch, I applied it, and I'm currently rebuilding all the
pre-built toolchains.
> > or1k | gpsd-3.16 | NOK | http://autobuild.buildroot.net/results/c24dd55e773167be182f40ae723e82d3f71c6eba
>
> error: field 'uc_mcontext' has incomplete type
>
> Some ucontext issue on or1k (see below, there are more)... Waldemar, Gustavo?
Waldemar has sent a uClibc-ng patch to fix this, I applied it, rebuild
of the toolchain in progress.
> > x86_64 | libcec-4.0.2 | NOK | http://autobuild.buildroot.net/results/e7505f36d7c2cfaf7527515b2e3014c2e8e2c5ca
>
> undefined reference to `std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> >::basic_string
> (std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> >&&)@GLIBCXX_3.4.21'
>
> Some ugly C++11 issue? Bernd?
This one has been there for a long time, since we bumped libcec to
4.0.2. I will revert the version bump in the next days if no fix is
proposed.
> > aarch64 | libepoxy-v1.3.1 | NOK | http://autobuild.buildroot.net/results/0a266f54e2938f7479232b7acec1834250f6c064
>
> error: conflicting types for 'khronos_uint64_t'
>
> Gustavo?
This one is more an odroid-mali bug:
BR2_PACKAGE_PROVIDES_LIBEGL="odroid-mali"
BR2_PACKAGE_PROVIDES_LIBGLES="odroid-mali"
I've already asked Dagg to have a look, but never had an answer.
> > microblazeel | make[4]: *** [all-recursive... | TIM | http://autobuild.buildroot.net/results/92c165a970b9d8912c5ca50ed3567478cd2a2b3d
>
> Timeout, but weird: the ffmpeg build started at 3850 seconds (a bit more
> than one hour) and the timeout is supposed to be 8h, so the ffmpeg build
> did not finish after about 7h...
Perhaps an infinite loop in the compiler. Happens sometimes on complex
code such as ffmpeg, and not very widely used architectures such as
microblaze.
> > powerpc64le | mpv-0.23.0 | NOK | http://autobuild.buildroot.net/results/4ba59ebb2cd16ed7e70c67e89f5f80c5b803d3c3
> > powerpc64 | mpv-0.23.0 | NOK | http://autobuild.buildroot.net/results/b97341c59b9c6f7dbdfe59cd770e0c285be8fa06
> > powerpc64le | mpv-0.23.0 | NOK | http://autobuild.buildroot.net/results/741535d8d9c75acebeff96679d4f1ac6ecbc5f61
>
> Patch on the list:
> https://patchwork.ozlabs.org/patch/706869/
The original fix from Sam has been applied by Peter.
> > sh4a | opencv-2.4.13 | NOK | http://autobuild.buildroot.net/results/2944568f9623f1377e987a1dadde5ea8cc428c5f
>
> error: 'SIZE_MAX' was not declared in this scope
>
> Missing header? Samuel?
This is the same issue as the one fixed for libraw in
d246cf5fd01bb0d20a0e64194ffed514ea8dd0aa. It's annoying that the issue
is in the jasper package, but we have to fix it in all packages using
jasper. Not sure what can be done about it though.
> > x86_64 | oracle-mysql-5.1.73 | NOK | http://autobuild.buildroot.net/results/e9ff38bea523df79331de3004939ee39b446d723
>
> error: narrowing conversion [...] from 'char' to 'uchar...'
>
> Damn gcc6... ;-) Should be easy; any taker?
I had a quick look, it's not that trivial if you want the correct fix.
And of course, mysql 5.1.73 is very very old, upstream is now at 5.7.17
(https://dev.mysql.com/downloads/mysql/). So I would like to suggest
that we mark oracle-mysql as BR2_BROKEN, and wait to see if anyone is
interested to fix this during the next release cycle.
> > nios2 | qt5base-5.6.2 | NOK | http://autobuild.buildroot.net/results/a02c4da118c2d0f90016c5e3c8877782d6882f96
>
> ld: BFD (Sourcery CodeBench Lite 2016.11-32) 2.26.51 assertion fail
>
> > nios2 | qt5base-5.8.0 | NOK | http://autobuild.buildroot.net/results/116931f17c4eb4977638ca0392bd6024e05d4ff9
>
> #error Target architecture was not detected as supported by
> Double-Conversion.
>
> No qt5 on nios2?
For those two issues, we have an exception in the autobuilders:
https://git.buildroot.org/buildroot-test/tree/scripts/autobuild-run#n500.
It's just that the autobuild-run script is not up-to-date on all
machines.
> > arm | qt5base-5.8.0 | NOK | http://autobuild.buildroot.net/results/41a0559f0d3c760ba9aad77dea4ed43e25b63ac4
>
> Project ERROR: Library 'libpng' is not defined.
>
> But it is enabled in the build. Dependency issue?
That's the freetype issue, patches from Peter Seiderer are on the list,
needs review.
> > arm | qt5base-5.8.0 | NOK | http://autobuild.buildroot.net/results/8f55bdbdce189c14baed772bb74eb41a0f8ce83c
>
> #error "ARM architecture too old"
>
> arm920t is an armv4. Surely we would not expect something big as Qt5 to
> stil work on such an old beast...
Fix by Peter Korsgaard already.
> > powerpc | qt5location-5.6.2 | NOK | http://autobuild.buildroot.net/results/1fd4195d3e941f4963a1957e4194b4e05e7bb909
>
> ld: BFD (crosstool-NG hg+-c65fcf8a34b7) 2.24 assertion fail
>
> Cyril, Gustavo, Sam: you're the PPC experts?
At some point, I will have to get rid of the Crosstool-NG toolchains I
believe.
> > mipsel | qt5webkit-5.6.2 | NOK | http://autobuild.buildroot.net/results/48a78b16a63448e1ac91efa7ae0ca77b2b9dba49
>
> Error: opcode not supported on this processor: mips32r6 (mips32r6) `movz $v0,$t8,$t7'
>
> Julien C., Peter S., Vicente?
This one is definitely for Vicente to look at.
> > x86_64 | sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/28c76e4125134b729f99099c3a53c1dcc55d0f12
> > arm | sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/558fd8acb31afd0a57c0c01020f73d9ee17a7bd9
> > arm | sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/fd599fd32ceab165a4926044e42f543c03179dec
> > xtensa | sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/3bba96405442dd97bdecfdc7865e4e13927fd327
> > arm | sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/7e96654503efcc79d386e13e23c21031738d493c
> > mips64el | sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/bd4c8eb1687713062e5b1ebbcde7f464c13779f1
> > x86_64 | sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/59f8410ba54e6ebbd7b65fd36f6b192a11f1262a
> > powerpc | sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/6ec46927ce16cf2b159805872ebef363c75e7551
> > arc | sngrep-v1.4.2 | NOK | http://autobuild.buildroot.net/results/8005ec840ac748970f6c4d49a3b5f1e2f1b69adc
>
> configure: error: You need to have ncurses forms library installed to
> compile sngrep.
>
> ncurses is disabled in this config. Adam?
ncurses is definitely enabled, so is ncurses-wchar.
> > arm | wavpack-5.1.0 | NOK | http://autobuild.buildroot.net/results/2d31a3295e51c5866fedae4adb0aa464e5079987
> > arm | wavpack-5.1.0 | NOK | http://autobuild.buildroot.net/results/e240455fc0bc6141988b5e1209f1a9b85b016361
>
> The wchar issue raised by Thomas upstream, which has a patch:
> https://github.com/dbry/WavPack/commit/876fc3f3907e871d0938ac6c8c5252f5f31abd1f
I think J?rg has submitted a patch, no?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 19+ messages in thread* [Buildroot] [autobuild.buildroot.net] Build results for 2017-02-16
2017-02-20 12:41 ` Thomas Petazzoni
@ 2017-02-20 14:59 ` Waldemar Brodkorb
2017-02-20 15:10 ` Thomas Petazzoni
2017-02-20 18:14 ` Bernd Kuhls
` (2 subsequent siblings)
3 siblings, 1 reply; 19+ messages in thread
From: Waldemar Brodkorb @ 2017-02-20 14:59 UTC (permalink / raw)
To: buildroot
Hi,
Thomas Petazzoni wrote,
> Hello,
>
> Thanks a lot for doing this analysis. A few comments below.
>
> On Fri, 17 Feb 2017 22:12:42 +0100, Yann E. MORIN wrote:
>
> > On 2017-02-17 08:28 +0100, Thomas Petazzoni spake thusly:
> > > or1k | alljoyn-16.04.00a | NOK | http://autobuild.buildroot.net/results/cd963404761070623489ee74df3e69f5052f40a1
> > > or1k | alljoyn-16.04.00a | NOK | http://autobuild.buildroot.net/results/99e6e01f0d85fe8eb5d9b09fcc3971b577c9ba6b
> > > or1k | alljoyn-16.04.00a | NOK | http://autobuild.buildroot.net/results/e5b471dbb91ef2a15844a9ee6d1a83a38f7cc07d
> >
> > error: 'printf' was not declared in this scope
> >
> > Fabrice?
>
> For this one and the jsoncpp-1.7.7 you reported below, what I find
> weird is that they happen *only* on or1k. or1k is using gcc 5.x, and
> lots of other architectures are using gcc 5.x.
>
> So I would *really* like to understand why we get those alljoyn and
> jsoncpp failures specifically on or1k and not on other architectures.
>
> > > i586 | bctoolbox-0.4.0 | NOK | http://autobuild.buildroot.net/results/bd4cca6e7706a68dd6c16a7bb409185c9f006a57
> > > m68k | bctoolbox-0.4.0 | NOK | http://autobuild.buildroot.net/results/4118477ac02732b99b8bb3db8bef43290edbc5de
> >
> > Neither mbedtls nor poarslsl detected. Patches by J?rg on the list (in
> > this order):
> > https://patchwork.ozlabs.org/patch/728005/
> > https://patchwork.ozlabs.org/patch/728007/
> > https://patchwork.ozlabs.org/patch/728004/
> > https://patchwork.ozlabs.org/patch/728006/
>
> I'll apply.
>
> > > or1k | dawgdic-16ac537ba9883ff01b6... | NOK | http://autobuild.buildroot.net/results/81047e13f4d7896abae1036e098303e6bf68a0e7
> >
> > error: 'strtoll' is not a member of 'std'
> >
> > C+11 stuff... Jonathan?
>
> Same or1k question as above: why does it happen only on or1k, and not
> on other architectures?
I am not entirely sure, but can the reason for this be this patch we
apply on top of gcc 5.4.x
package/gcc/5.4.0/850-libstdcxx-uclibc-c99.patch?
I think all failures relate to some C++ header failures. Can anybody
try with this patch applied?
best regards
Waldemar
^ permalink raw reply [flat|nested] 19+ messages in thread* [Buildroot] [autobuild.buildroot.net] Build results for 2017-02-16
2017-02-20 14:59 ` Waldemar Brodkorb
@ 2017-02-20 15:10 ` Thomas Petazzoni
0 siblings, 0 replies; 19+ messages in thread
From: Thomas Petazzoni @ 2017-02-20 15:10 UTC (permalink / raw)
To: buildroot
Hello,
On Mon, 20 Feb 2017 15:59:33 +0100, Waldemar Brodkorb wrote:
> I am not entirely sure, but can the reason for this be this patch we
> apply on top of gcc 5.4.x
> package/gcc/5.4.0/850-libstdcxx-uclibc-c99.patch?
>
> I think all failures relate to some C++ header failures. Can anybody
> try with this patch applied?
Indeed could be the reason. Worth checking before we apply tons of
patches to individual packages.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-02-16
2017-02-20 12:41 ` Thomas Petazzoni
2017-02-20 14:59 ` Waldemar Brodkorb
@ 2017-02-20 18:14 ` Bernd Kuhls
2017-02-20 22:40 ` Peter Korsgaard
2017-02-21 8:05 ` Arnout Vandecappelle
3 siblings, 0 replies; 19+ messages in thread
From: Bernd Kuhls @ 2017-02-20 18:14 UTC (permalink / raw)
To: buildroot
Hi Thomas,
Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote
in news:20170220134111.1bc02a9f at free-electrons.com:
>> > x86_64 | libcec-4.0.2 | NOK |
>> > http://autobuild.buildroot.net/results/e7505f36d7c2cfaf7527515b2
>> > e3014c2e8e2c5ca
>>
>> undefined reference to `std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> >::basic_string
>> (std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> >&&)@GLIBCXX_3.4.21'
>>
>> Some ugly C++11 issue? Bernd?
> This one has been there for a long time, since we bumped libcec to
> 4.0.2. I will revert the version bump in the next days if no fix is
> proposed.
Afaics there are two different build failures with libcec-4.0.2.
I could not reproduce the one you mentioned here using this defconfig:
http://autobuild.buildroot.net/results/38b/38ba94fe0db1544e78fd69dcbd77a452e1
21deba/
I could however reproduce the other build failure, like this one:
http://autobuild.buildroot.net/results/faa/faa5270be0a54043891db9baf50a217eae
2c575f/
I posted my findings here: http://lists.busybox.net/pipermail/buildroot/2017-
February/184248.html
Regards, Bernd
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-02-16
2017-02-20 12:41 ` Thomas Petazzoni
2017-02-20 14:59 ` Waldemar Brodkorb
2017-02-20 18:14 ` Bernd Kuhls
@ 2017-02-20 22:40 ` Peter Korsgaard
2017-02-20 22:46 ` Thomas Petazzoni
2017-02-21 8:05 ` Arnout Vandecappelle
3 siblings, 1 reply; 19+ messages in thread
From: Peter Korsgaard @ 2017-02-20 22:40 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
>> > x86_64 | oracle-mysql-5.1.73 | NOK |
>> > http://autobuild.buildroot.net/results/e9ff38bea523df79331de3004939ee39b446d723
>>
>> error: narrowing conversion [...] from 'char' to 'uchar...'
>>
>> Damn gcc6... ;-) Should be easy; any taker?
> I had a quick look, it's not that trivial if you want the correct fix.
> And of course, mysql 5.1.73 is very very old, upstream is now at 5.7.17
> (https://dev.mysql.com/downloads/mysql/). So I would like to suggest
> that we mark oracle-mysql as BR2_BROKEN, and wait to see if anyone is
> interested to fix this during the next release cycle.
I agree. There has also recently been some security issues, but like you
say our package is ancient.
Will you send a patch?
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-02-16
2017-02-20 22:40 ` Peter Korsgaard
@ 2017-02-20 22:46 ` Thomas Petazzoni
2017-02-20 22:59 ` Peter Korsgaard
0 siblings, 1 reply; 19+ messages in thread
From: Thomas Petazzoni @ 2017-02-20 22:46 UTC (permalink / raw)
To: buildroot
Hello,
On Mon, 20 Feb 2017 23:40:39 +0100, Peter Korsgaard wrote:
> I agree. There has also recently been some security issues, but like you
> say our package is ancient.
>
> Will you send a patch?
I'll try, but it's not a one-liner. If you make oracle-mysql
unavailable, then the only mysql provider is mariadb. But mariadb has
an additional BR2_PACKAGE_LIBAIO_ARCH_SUPPORTS dependency, which needs
to be propagated to all reverse dependencies of BR2_PACKAGE_MYSQL.
Not sure how to handle this case: there are quite a few packages
selecting mysql:
package/collectd/Config.in: select BR2_PACKAGE_MYSQL
package/dovecot/Config.in: select BR2_PACKAGE_MYSQL
package/kodi/Config.in: select BR2_PACKAGE_MYSQL
package/poco/Config.in: select BR2_PACKAGE_MYSQL
package/qt/Config.sql.in: select BR2_PACKAGE_MYSQL
package/qt5/qt5base/Config.in: select BR2_PACKAGE_MYSQL
package/sconeserver/Config.in: select BR2_PACKAGE_MYSQL
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-02-16
2017-02-20 22:46 ` Thomas Petazzoni
@ 2017-02-20 22:59 ` Peter Korsgaard
0 siblings, 0 replies; 19+ messages in thread
From: Peter Korsgaard @ 2017-02-20 22:59 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> Hello,
> On Mon, 20 Feb 2017 23:40:39 +0100, Peter Korsgaard wrote:
>> I agree. There has also recently been some security issues, but like you
>> say our package is ancient.
>>
>> Will you send a patch?
> I'll try, but it's not a one-liner. If you make oracle-mysql
> unavailable, then the only mysql provider is mariadb. But mariadb has
> an additional BR2_PACKAGE_LIBAIO_ARCH_SUPPORTS dependency, which needs
> to be propagated to all reverse dependencies of BR2_PACKAGE_MYSQL.
Gaah :/
> Not sure how to handle this case: there are quite a few packages
> selecting mysql:
> package/collectd/Config.in: select BR2_PACKAGE_MYSQL
> package/dovecot/Config.in: select BR2_PACKAGE_MYSQL
> package/kodi/Config.in: select BR2_PACKAGE_MYSQL
> package/poco/Config.in: select BR2_PACKAGE_MYSQL
> package/qt/Config.sql.in: select BR2_PACKAGE_MYSQL
> package/qt5/qt5base/Config.in: select BR2_PACKAGE_MYSQL
> package/sconeserver/Config.in: select BR2_PACKAGE_MYSQL
Hmm, using depends on probably isn't really nice either. I don't think
the actual dependency is really such a big deal though, as libaio
supports quite a lot of architectures, and the ones it doesn't are
unlikely to use mysql.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-02-16
2017-02-20 12:41 ` Thomas Petazzoni
` (2 preceding siblings ...)
2017-02-20 22:40 ` Peter Korsgaard
@ 2017-02-21 8:05 ` Arnout Vandecappelle
2017-02-21 8:27 ` Thomas Petazzoni
3 siblings, 1 reply; 19+ messages in thread
From: Arnout Vandecappelle @ 2017-02-21 8:05 UTC (permalink / raw)
To: buildroot
On 20-02-17 13:41, Thomas Petazzoni wrote:
> Hello,
>
> Thanks a lot for doing this analysis. A few comments below.
>
> On Fri, 17 Feb 2017 22:12:42 +0100, Yann E. MORIN wrote:
>
>> On 2017-02-17 08:28 +0100, Thomas Petazzoni spake thusly:
[snip]
>>> microblazeel | make[4]: *** [all-recursive... | TIM | http://autobuild.buildroot.net/results/92c165a970b9d8912c5ca50ed3567478cd2a2b3d
>>
>> Timeout, but weird: the ffmpeg build started at 3850 seconds (a bit more
>> than one hour) and the timeout is supposed to be 8h, so the ffmpeg build
>> did not finish after about 7h...
>
> Perhaps an infinite loop in the compiler. Happens sometimes on complex
> code such as ffmpeg, and not very widely used architectures such as
> microblaze.
Perhaps for the timeout, it would make sense to do a setrlimit(RLIMIT_CPU) in
addition to the monitor. That way you avoid that a single compile stays stuck
for 7 hours. Though admittedly at the moment it happens sufficiently rarely to
not be too much of a waste.
>>> sh4a | opencv-2.4.13 | NOK | http://autobuild.buildroot.net/results/2944568f9623f1377e987a1dadde5ea8cc428c5f
>>
>> error: 'SIZE_MAX' was not declared in this scope
>>
>> Missing header? Samuel?
>
> This is the same issue as the one fixed for libraw in
> d246cf5fd01bb0d20a0e64194ffed514ea8dd0aa. It's annoying that the issue
> is in the jasper package, but we have to fix it in all packages using
> jasper. Not sure what can be done about it though.
Actually, only the packages that use C++. AFAICS that's just kodi, libraw,
opencv and opencv3.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 19+ messages in thread* [Buildroot] [autobuild.buildroot.net] Build results for 2017-02-16
2017-02-21 8:05 ` Arnout Vandecappelle
@ 2017-02-21 8:27 ` Thomas Petazzoni
2017-02-21 8:46 ` Arnout Vandecappelle
0 siblings, 1 reply; 19+ messages in thread
From: Thomas Petazzoni @ 2017-02-21 8:27 UTC (permalink / raw)
To: buildroot
Hello,
On Tue, 21 Feb 2017 09:05:01 +0100, Arnout Vandecappelle wrote:
> Perhaps for the timeout, it would make sense to do a setrlimit(RLIMIT_CPU) in
> addition to the monitor. That way you avoid that a single compile stays stuck
> for 7 hours. Though admittedly at the moment it happens sufficiently rarely to
> not be too much of a waste.
So doing "ulimit -t 60" will for example prevent a single process from
getting more than 60 seconds of CPU time ?
But I agree, it doesn't happen that often, so probably not worth the
effort.
> >>> sh4a | opencv-2.4.13 | NOK | http://autobuild.buildroot.net/results/2944568f9623f1377e987a1dadde5ea8cc428c5f
> >>
> >> error: 'SIZE_MAX' was not declared in this scope
> >>
> >> Missing header? Samuel?
> >
> > This is the same issue as the one fixed for libraw in
> > d246cf5fd01bb0d20a0e64194ffed514ea8dd0aa. It's annoying that the issue
> > is in the jasper package, but we have to fix it in all packages using
> > jasper. Not sure what can be done about it though.
>
> Actually, only the packages that use C++. AFAICS that's just kodi, libraw,
> opencv and opencv3.
Correct. But still, that's a bit annoying to have to change all the
consumers of a package.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-02-16
2017-02-21 8:27 ` Thomas Petazzoni
@ 2017-02-21 8:46 ` Arnout Vandecappelle
2017-02-21 8:55 ` Thomas Petazzoni
0 siblings, 1 reply; 19+ messages in thread
From: Arnout Vandecappelle @ 2017-02-21 8:46 UTC (permalink / raw)
To: buildroot
On 21-02-17 09:27, Thomas Petazzoni wrote:
> Hello,
>
> On Tue, 21 Feb 2017 09:05:01 +0100, Arnout Vandecappelle wrote:
>
>> Perhaps for the timeout, it would make sense to do a setrlimit(RLIMIT_CPU) in
>> addition to the monitor. That way you avoid that a single compile stays stuck
>> for 7 hours. Though admittedly at the moment it happens sufficiently rarely to
>> not be too much of a waste.
>
> So doing "ulimit -t 60" will for example prevent a single process from
> getting more than 60 seconds of CPU time ?
Indeed. At least, I think so :-) According to the setrlimit man page, the
limits are inherited by child processes. And as far as I can see, the limit only
applies to the process's own CPU time, not the cumulative time including children.
> But I agree, it doesn't happen that often, so probably not worth the
> effort.
>
>>>>> sh4a | opencv-2.4.13 | NOK | http://autobuild.buildroot.net/results/2944568f9623f1377e987a1dadde5ea8cc428c5f
>>>>
>>>> error: 'SIZE_MAX' was not declared in this scope
>>>>
>>>> Missing header? Samuel?
>>>
>>> This is the same issue as the one fixed for libraw in
>>> d246cf5fd01bb0d20a0e64194ffed514ea8dd0aa. It's annoying that the issue
>>> is in the jasper package, but we have to fix it in all packages using
>>> jasper. Not sure what can be done about it though.
>>
>> Actually, only the packages that use C++. AFAICS that's just kodi, libraw,
>> opencv and opencv3.
>
> Correct. But still, that's a bit annoying to have to change all the
> consumers of a package.
An alternative would be to patch jasper itself to define __STDC_LIMIT_MACROS in
its headers. Far-reaching, but probably harmless. Not sure if such a patch would
be upstreamable though.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-02-16
2017-02-21 8:46 ` Arnout Vandecappelle
@ 2017-02-21 8:55 ` Thomas Petazzoni
0 siblings, 0 replies; 19+ messages in thread
From: Thomas Petazzoni @ 2017-02-21 8:55 UTC (permalink / raw)
To: buildroot
Hello,
On Tue, 21 Feb 2017 09:46:03 +0100, Arnout Vandecappelle wrote:
> An alternative would be to patch jasper itself to define __STDC_LIMIT_MACROS in
> its headers. Far-reaching, but probably harmless. Not sure if such a patch would
> be upstreamable though.
I tried that, but that doesn't work. If you sneak into jas_math.h a:
#define __STDC_LIMIT_MACROS
before it includes <stdint.h>
then in fact it's too late, because for example libraw has already
included <stdint.h> *before* including jas_math.h. And at the time of
this first <stdint.h> include, __STDC_LIMIT_MACROS was not defined.
A nicer option would be for jasper to provide a pkg-config file that
tells its consumers how to compile/link against it.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-02-16
2017-02-17 21:12 ` Yann E. MORIN
` (3 preceding siblings ...)
2017-02-20 12:41 ` Thomas Petazzoni
@ 2017-02-24 14:37 ` Julien Boibessot
2017-02-24 14:48 ` Thomas Petazzoni
4 siblings, 1 reply; 19+ messages in thread
From: Julien Boibessot @ 2017-02-24 14:37 UTC (permalink / raw)
To: buildroot
Hello,
Yann,
sorry for my late analysis.
On 17/02/2017 22:12, Yann E. MORIN wrote:
> <cut>....
>> arc | opentyrian-9c9f0ec3532b | NOK | http://autobuild.buildroot.net/results/89864a1cf0d8b27b3efdf3c36ccb3244e88a6746
> undefined reference to `dl_iterate_phdr'
> ld: GOT and PLT relocations cannot be fixed with a non dynamic linker
>
> Static linking issue. Julien B.?
It seems that adding "-static" to final linking command solves the
problem. It's strange that other static builds on other ARCH are working ?
Should I add a ~ "LDGLAGS += -static" in opentyrian.mk ?
Regards,
Julien
^ permalink raw reply [flat|nested] 19+ messages in thread* [Buildroot] [autobuild.buildroot.net] Build results for 2017-02-16
2017-02-24 14:37 ` Julien Boibessot
@ 2017-02-24 14:48 ` Thomas Petazzoni
2017-02-25 1:47 ` Waldemar Brodkorb
0 siblings, 1 reply; 19+ messages in thread
From: Thomas Petazzoni @ 2017-02-24 14:48 UTC (permalink / raw)
To: buildroot
Hello,
On Fri, 24 Feb 2017 15:37:00 +0100, Julien Boibessot wrote:
> > Static linking issue. Julien B.?
>
> It seems that adding "-static" to final linking command solves the
> problem. It's strange that other static builds on other ARCH are working ?
Waldemar can answer this question I believe.
> Should I add a ~ "LDGLAGS += -static" in opentyrian.mk ?
-static is already in TARGET_LDFLAGS, so the problem is that you are
not passing TARGET_LDFLAGS properly. You should do:
LDFLAGS="$(TARGET_LDFLAGS) -lm"
instead of just:
LDFLAGS="-lm"
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-02-16
2017-02-24 14:48 ` Thomas Petazzoni
@ 2017-02-25 1:47 ` Waldemar Brodkorb
0 siblings, 0 replies; 19+ messages in thread
From: Waldemar Brodkorb @ 2017-02-25 1:47 UTC (permalink / raw)
To: buildroot
Hi,
Thomas Petazzoni wrote,
> Hello,
>
> On Fri, 24 Feb 2017 15:37:00 +0100, Julien Boibessot wrote:
>
> > > Static linking issue. Julien B.?
> >
> > It seems that adding "-static" to final linking command solves the
> > problem. It's strange that other static builds on other ARCH are working ?
>
> Waldemar can answer this question I believe.
It might be an ARC specific issue. I have found some strange issues
when using static builds with ARC. I have to report it to the
Synopsis developers. I can not even run a simple hello world
statically compiled on NSIM - ARC simulator.
But when -static is not passed to the final linking command on a
static-only build, some circular dependencies in the threading code
will not be automatically resolved by gcc. This shouldn't be a
architecture specific problem, but is uClibc-ng specific.
best regards
Waldemar
^ permalink raw reply [flat|nested] 19+ messages in thread