* [Buildroot] Analysis of build results for 2015-08-05
2015-08-06 9:30 ` [Buildroot] Analysis of build " Thomas Petazzoni
@ 2015-08-06 9:30 ` Vicente Olivert Riera
2015-08-17 10:02 ` Vicente Olivert Riera
2015-08-06 9:36 ` Vicente Olivert Riera
` (6 subsequent siblings)
7 siblings, 1 reply; 20+ messages in thread
From: Vicente Olivert Riera @ 2015-08-06 9:30 UTC (permalink / raw)
To: buildroot
Hello Thomas,
On 06/08/15 11:30, Thomas Petazzoni wrote:
>> mips | ltrace-c22d359433b333937ee3... | NOK | http://autobuild.buildroot.net/results/79b51941ed57b0564c68112489b03cac39a04e9a/
>
> output.c: In function 'output_right':
> output.c:784:3: error: size of unnamed array is negative
> (void)sizeof(char[1 - 2*(sizeof(unw_word_t)
> ^
>
> Vicente, J?r?me, can you have a look?
ltrace with libunwind support is broken for MIPS, but I'm working with
upstream to get it fixed. I hope to finish with it soon.
Regards,
Vincent.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Buildroot] Analysis of build results for 2015-08-05
2015-08-06 9:30 ` [Buildroot] Analysis of build " Thomas Petazzoni
2015-08-06 9:30 ` Vicente Olivert Riera
@ 2015-08-06 9:36 ` Vicente Olivert Riera
2015-08-17 10:00 ` Vicente Olivert Riera
2015-08-06 10:08 ` Julien CORJON
` (5 subsequent siblings)
7 siblings, 1 reply; 20+ messages in thread
From: Vicente Olivert Riera @ 2015-08-06 9:36 UTC (permalink / raw)
To: buildroot
Hello Thomas,
On 06/08/15 11:30, Thomas Petazzoni wrote:
>> mips | qt5base-5.5.0 | NOK | http://autobuild.buildroot.net/results/1f4eee3423650651ac37f55dafed269c6d9baa98/
>
> MIPS problem:
>
> fatal error: gnu/lib-names-o32_soft.h: No such file or directory
>
> Vicente, can you comment?
we are in conversations with Mentor to check the support for soft-float
in their toolchains.
Regards,
Vincent.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Buildroot] Analysis of build results for 2015-08-05
2015-08-06 9:30 ` [Buildroot] Analysis of build " Thomas Petazzoni
2015-08-06 9:30 ` Vicente Olivert Riera
2015-08-06 9:36 ` Vicente Olivert Riera
@ 2015-08-06 10:08 ` Julien CORJON
2015-08-06 11:57 ` Brendan Heading
` (4 subsequent siblings)
7 siblings, 0 replies; 20+ messages in thread
From: Julien CORJON @ 2015-08-06 10:08 UTC (permalink / raw)
To: buildroot
Hello Thomas,
I'm currently on holiday until beginning of September.
Le 06/08/2015 11:30, Thomas Petazzoni a ?crit :
>> arm | qt5base-5.5.0 | NOK | http://autobuild.buildroot.net/results/4edecf424246204aa68c9670b4950bafcf8fe973/
>
> Glib auto-detection... ()
> [...]
> cannot find -ldl
>
> Julien?
>
> Note that the build-end.log is very very large, for some reason. I
> recommend you to download it with wget, and look at it with less/cat,
> instead of your web browser.
>
I'm not sure I will have the time to work on that one until then...
>> aarch64 | qt5multimedia-5.5.0 | NOK | http://autobuild.buildroot.net/results/0ee0f879e8563954c64b3940cdec39d2e6de937a/
>
> Julien, any idea?
>
> cp -dpf /home/test/autobuild/instance-2/output/host/usr/aarch64-buildroot-linux-gnu/sysroot/usr/lib/libqgsttools*.so.* /home/test/autobuild/instance-2/output/target/usr/lib
> cp: cannot stat `/home/test/autobuild/instance-2/output/host/usr/aarch64-buildroot-linux-gnu/sysroot/usr/lib/libqgsttools*.so.*': No such file or directory
>
The copy of libqgsttools is hard coded in the qt5multimedia.mk file but
the compilation of this plugin is based on an autodection in qt5base. I
have just submitted a patch to force gstreamer detection[1] and allow
gst1.0 support[2] but I didn't check all the cases. We may let autobuild
do that work for me if you want a quick fix of this issue.
[1] https://patchwork.ozlabs.org/patch/504627/
[2] https://patchwork.ozlabs.org/patch/504628/
^ permalink raw reply [flat|nested] 20+ messages in thread* [Buildroot] Analysis of build results for 2015-08-05
2015-08-06 9:30 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (2 preceding siblings ...)
2015-08-06 10:08 ` Julien CORJON
@ 2015-08-06 11:57 ` Brendan Heading
2015-08-06 16:31 ` Bernd Kuhls
` (3 subsequent siblings)
7 siblings, 0 replies; 20+ messages in thread
From: Brendan Heading @ 2015-08-06 11:57 UTC (permalink / raw)
To: buildroot
> So we really need to make more progress on fixing the musl issues, and
> find a solution for the SPARC atomic problem.
I'm doing a separate investigation into SPARC to identify all of the
packages that have the atomic issue, maybe we can track it with
bugzilla and come up with a structured approach to tackling it.
Some can be fixed relatively trivially, others need a bit more surgery
to add conditional compilation/detection/conditional linking of
libatomic.
It is worth highlighting that fixing these problems benefits other
architectures, as there are a number of the less mainstream ones that
lack full atomic support.
>> sparc | boost-1.58.0 | NOK | http://autobuild.buildroot.net/results/14591f0ce708f68f925c9223471b3c4f0ddb9eef/
>
> error: #error "platform not supported"
>
> Pff, why do we care about SPARC ?
I keep asking that question .. :)
>> x86_64 | clapack-3.2.1 | NOK | http://autobuild.buildroot.net/results/66fa17376cbb05351988e7ef0dc0c232bbd19f2d/
>
> musl build problem:
This one is non-trivial to fix. The part that includes fpu_control.h
can be conditionally compiled out, but there are lots of other
glibc-isms (missing header files).
According to the maintainer site, the code is generated by some kind
of Fortran-to-C converter, so upstream patches may be an issue.
>> arm | linux-pam-1.1.8 | NOK | http://autobuild.buildroot.net/results/c865d16a7f878f2ecc52c30f285c43e5cf45bdcc/
>> x86_64 | linux-pam-1.1.8 | NOK | http://autobuild.buildroot.net/results/4dfd26c01fb8d64b2793402b7ebdc2992ee5a54d/
>
> musl build problem:
>
> error: '_PATH_LASTLOG' undeclared (first use in this function)
I am preparing a patch series for this. It's also non-trivial - the
macros can be fixed but then you run into a problem with musl lacking
an implementation of logwtmp(). The musl maintainers say they won't
implement this for security reasons, unless someone can provide a
justification that they will accept, so my patch steals an
implementation of it from OpenBSD's libc and supplies it as a
conditionally compiled static function.
>> sparc | moarvm-2015.05 | NOK | http://autobuild.buildroot.net/results/063b8e47a39eef601fe6d7d9578a64216c8eccb6/
>
> /tmp/ccrWqi6b.s: Assembler messages:
> /tmp/ccrWqi6b.s:187: Error: Architecture mismatch on "membar".
> /tmp/ccrWqi6b.s:187: (Requires v9|v9a|v9b; requested architecture is v8.)
> /tmp/ccrWqi6b.s:188: Error: Architecture mismatch on "cas".
> /tmp/ccrWqi6b.s:188: (Requires leon|v9|v9a|v9b; requested architecture is v8.)
> /tmp/ccrWqi6b.s:189: Error: Architecture mismatch on "membar".
> /tmp/ccrWqi6b.s:189: (Requires v9|v9a|v9b; requested architecture is v8.)
> make[1]: *** [src/core/threads.o] Error 1
>
> Pff, why do we care about SPARC, again? If nobody sends a patch for
> this, I'll just mark moarvm as not available on SPARC.
This error is very similar to the problem with libpthsem on SPARC that
I was debating with Yann earlier this week. On libpthsem, the
configure script is implemented in such a way that it doesn't support
cross-compilers. If it's the same issue it can probably be fixed by
adding forced defaults in the configure section (although I haven't
checked).
Brendan
^ permalink raw reply [flat|nested] 20+ messages in thread* [Buildroot] Analysis of build results for 2015-08-05
2015-08-06 9:30 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (3 preceding siblings ...)
2015-08-06 11:57 ` Brendan Heading
@ 2015-08-06 16:31 ` Bernd Kuhls
2015-08-07 4:07 ` Waldemar Brodkorb
` (2 subsequent siblings)
7 siblings, 0 replies; 20+ messages in thread
From: Bernd Kuhls @ 2015-08-06 16:31 UTC (permalink / raw)
To: buildroot
Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote
in news:20150806113014.163c6592 at free-electrons.com:
> Hello all,
>> i686 | mesa3d-10.6.3 | NOK |
>> http://autobuild.buildroot.net/results/08305f397ef523ee864827e1e
>> 267475a9f6f397f/
> checking for LIBUDEV... no
> configure: error: gbm requires --enable-dri
> make: ***
> [/home/test/autobuild/instance-1/output/build/mesa3d-10.6.3/.stamp_config
> ured] Error 1 make: Leaving directory
> `/home/test/autobuild/instance-1/buildroot' Bernd, is this fixed by one
> of the pending patches on mesa3d ?
Hi Thomas,
yes, this patch fixes the build error:
http://patchwork.ozlabs.org/patch/502988/
Regards, Bernd
^ permalink raw reply [flat|nested] 20+ messages in thread* [Buildroot] Analysis of build results for 2015-08-05
2015-08-06 9:30 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (4 preceding siblings ...)
2015-08-06 16:31 ` Bernd Kuhls
@ 2015-08-07 4:07 ` Waldemar Brodkorb
2015-08-07 8:58 ` Thomas Petazzoni
2015-08-07 12:11 ` Max Filippov
2015-08-10 11:26 ` Alexey Brodkin
7 siblings, 1 reply; 20+ messages in thread
From: Waldemar Brodkorb @ 2015-08-07 4:07 UTC (permalink / raw)
To: buildroot
Hi Thomas,
Thomas Petazzoni wrote,
> Hello all,
>
> Brendan, Alexey, Vicente, J?r?me, Bernd, Max, Julien, Clayton, Gustavo, Yann, please have a look below.
>
> > arm | audit-2.4.3 | NOK | http://autobuild.buildroot.net/results/549492270f3f43747a96a8326aef1d7ae1d3b213/
>
> Not sure what's going on:
>
> cannot find Scrt1.o: No such file or directory
>
> Waldemar, it seems to be a uClibc issue. Do you have some idea?
The reason for the failure is an unsupported combination of
PIE and static.
I found a thread about it here:
https://sourceware.org/ml/binutils/2012-02/msg00260.html
With Linux it seems you need dynamic linking of a PIE executable.
PIE is hardcoded in audit Makefile.am, so we would either need to
make it conditional for static builds or disable the package for
static builds.
best regards
Waldemar
^ permalink raw reply [flat|nested] 20+ messages in thread* [Buildroot] Analysis of build results for 2015-08-05
2015-08-07 4:07 ` Waldemar Brodkorb
@ 2015-08-07 8:58 ` Thomas Petazzoni
0 siblings, 0 replies; 20+ messages in thread
From: Thomas Petazzoni @ 2015-08-07 8:58 UTC (permalink / raw)
To: buildroot
Waldemar,
On Fri, 7 Aug 2015 06:07:27 +0200, Waldemar Brodkorb wrote:
> > Waldemar, it seems to be a uClibc issue. Do you have some idea?
>
> The reason for the failure is an unsupported combination of
> PIE and static.
>
> I found a thread about it here:
> https://sourceware.org/ml/binutils/2012-02/msg00260.html
>
> With Linux it seems you need dynamic linking of a PIE executable.
>
> PIE is hardcoded in audit Makefile.am, so we would either need to
> make it conditional for static builds or disable the package for
> static builds.
Thanks. I've marked the package as not available for static builds. See:
http://git.buildroot.net/buildroot/commit/?id=e43875916a6810b4ff8c65e27840f9da15b86c7a
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Buildroot] Analysis of build results for 2015-08-05
2015-08-06 9:30 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (5 preceding siblings ...)
2015-08-07 4:07 ` Waldemar Brodkorb
@ 2015-08-07 12:11 ` Max Filippov
2015-08-07 12:13 ` Thomas Petazzoni
2015-08-10 11:26 ` Alexey Brodkin
7 siblings, 1 reply; 20+ messages in thread
From: Max Filippov @ 2015-08-07 12:11 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Thu, Aug 6, 2015 at 12:30 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>> xtensa | opencv-3.0.0 | NOK | http://autobuild.buildroot.net/results/15ba0b520043b884fc7dafbb84da171072d7d3ee/
>
> Xtensa toolchain issue:
>
> Error: operand 2 of 'l32r' has out of range value '4294705124'
>
> Max? This is affecting only OpenCV, maybe we should simply exclude it
> from the Xtensa build?
it turned out to be rather big change, in both binutils and gcc.
I'm still testing it. I hope to send it to binutils and gcc early next week,
and if all goes well to the buildroot later next week. If not, I'll send a
patch to disable OpenCV on Xtensa.
--
Thanks.
-- Max
^ permalink raw reply [flat|nested] 20+ messages in thread* [Buildroot] Analysis of build results for 2015-08-05
2015-08-07 12:11 ` Max Filippov
@ 2015-08-07 12:13 ` Thomas Petazzoni
0 siblings, 0 replies; 20+ messages in thread
From: Thomas Petazzoni @ 2015-08-07 12:13 UTC (permalink / raw)
To: buildroot
Max,
On Fri, 7 Aug 2015 15:11:51 +0300, Max Filippov wrote:
> Hi Thomas,
>
> On Thu, Aug 6, 2015 at 12:30 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> >> xtensa | opencv-3.0.0 | NOK | http://autobuild.buildroot.net/results/15ba0b520043b884fc7dafbb84da171072d7d3ee/
> >
> > Xtensa toolchain issue:
> >
> > Error: operand 2 of 'l32r' has out of range value '4294705124'
> >
> > Max? This is affecting only OpenCV, maybe we should simply exclude it
> > from the Xtensa build?
>
> it turned out to be rather big change, in both binutils and gcc.
> I'm still testing it. I hope to send it to binutils and gcc early next week,
> and if all goes well to the buildroot later next week. If not, I'll send a
> patch to disable OpenCV on Xtensa.
Great, thanks for your feedback! Let's wait until next week then to
take a decision on this issue.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Buildroot] Analysis of build results for 2015-08-05
2015-08-06 9:30 ` [Buildroot] Analysis of build " Thomas Petazzoni
` (6 preceding siblings ...)
2015-08-07 12:11 ` Max Filippov
@ 2015-08-10 11:26 ` Alexey Brodkin
2015-08-10 11:36 ` Thomas Petazzoni
7 siblings, 1 reply; 20+ messages in thread
From: Alexey Brodkin @ 2015-08-10 11:26 UTC (permalink / raw)
To: buildroot
Hi Thomas,
A bit late - was on FTO in the end of last week.
On Thu, 2015-08-06 at 11:30 +0200, Thomas Petazzoni wrote:
> Hello all,
> arc | gnuradio-3.7.5 | NOK |
> > http://autobuild.buildroot.net/results/d44aec8c82ed6a315322726dd698e6b48990ba76/
>
> ARC toolchain problem:
>
> error: '__NR_eventfd' was not declared in this scope
>
> Alexey, I don't remember, do you have a fix for this one?
I already commented on that one.
Basically gnuradio includes source from boost and in boost itself they
use syscall directly if (__GLIBC__ == 2 && __GLIBC_MINOR__ < 8) which
is the case for uClibc, see http://git.uclibc.org/uClibc/tree/include/features.h#n395
-------------->8--------------
#define __GLIBC__ 2
#define __GLIBC_MINOR__ 2
-------------->8--------------
From Boost standpoint this looks like some sort of backward compatibility for older
glibc that didn;'t have eventfd() defined.
So probably the best option here is to bump __GLIBC__/__GLIBC_MINOR__ in uClibc.
Maybe Waldemar may comment on that?
> > arc | libselinux-2.1.13 | NOK |
> > http://autobuild.buildroot.net/results/2fdea2bbcdff4a70ffaac1eecbc8faa81a44e90c/
>
> ARC toolchain problem:
>
> Error: internal error: fixup not contained within frag
>
> Alexey?
On my to investigate list.
arc | zeromq-4.1.2 | NOK |
> > http://autobuild.buildroot.net/results/be46b621ce5443788b0a1bc9fab614c4ca5d0859/
>
> libsodium.so: undefined reference to `explicit_bzero'
>
> Not sure. Alexey?
Libsodium attempts to build as PIE.
Should be fixed by http://patchwork.ozlabs.org/patch/505568/
-Alexey
^ permalink raw reply [flat|nested] 20+ messages in thread* [Buildroot] Analysis of build results for 2015-08-05
2015-08-10 11:26 ` Alexey Brodkin
@ 2015-08-10 11:36 ` Thomas Petazzoni
2015-08-10 11:54 ` Alexey Brodkin
0 siblings, 1 reply; 20+ messages in thread
From: Thomas Petazzoni @ 2015-08-10 11:36 UTC (permalink / raw)
To: buildroot
Dear Alexey Brodkin,
On Mon, 10 Aug 2015 11:26:29 +0000, Alexey Brodkin wrote:
> On Thu, 2015-08-06 at 11:30 +0200, Thomas Petazzoni wrote:
> > Hello all,
> > arc | gnuradio-3.7.5 | NOK |
> > > http://autobuild.buildroot.net/results/d44aec8c82ed6a315322726dd698e6b48990ba76/
> >
> > ARC toolchain problem:
> >
> > error: '__NR_eventfd' was not declared in this scope
> >
> > Alexey, I don't remember, do you have a fix for this one?
>
> I already commented on that one.
> Basically gnuradio includes source from boost and in boost itself they
> use syscall directly if (__GLIBC__ == 2 && __GLIBC_MINOR__ < 8) which
> is the case for uClibc, see http://git.uclibc.org/uClibc/tree/include/features.h#n395
> -------------->8--------------
> #define __GLIBC__ 2
> #define __GLIBC_MINOR__ 2
> -------------->8--------------
>
> From Boost standpoint this looks like some sort of backward compatibility for older
> glibc that didn;'t have eventfd() defined.
>
> So probably the best option here is to bump __GLIBC__/__GLIBC_MINOR__ in uClibc.
> Maybe Waldemar may comment on that?
Can't we instead patch boost to use a || defined(__UCLIBC__) or
something like that?
> > > arc | libselinux-2.1.13 | NOK |
> > > http://autobuild.buildroot.net/results/2fdea2bbcdff4a70ffaac1eecbc8faa81a44e90c/
> >
> > ARC toolchain problem:
> >
> > Error: internal error: fixup not contained within frag
> >
> > Alexey?
>
> On my to investigate list.
Thanks!
> Libsodium attempts to build as PIE.
> Should be fixed by http://patchwork.ozlabs.org/patch/505568/
Seen the patch, thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Buildroot] Analysis of build results for 2015-08-05
2015-08-10 11:36 ` Thomas Petazzoni
@ 2015-08-10 11:54 ` Alexey Brodkin
2015-08-10 18:08 ` Waldemar Brodkorb
0 siblings, 1 reply; 20+ messages in thread
From: Alexey Brodkin @ 2015-08-10 11:54 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Mon, 2015-08-10 at 13:36 +0200, Thomas Petazzoni wrote:
> Dear Alexey Brodkin,
>
> On Mon, 10 Aug 2015 11:26:29 +0000, Alexey Brodkin wrote:
>
> > On Thu, 2015-08-06 at 11:30 +0200, Thomas Petazzoni wrote:
> > > Hello all,
> > > arc | gnuradio-3.7.5 | NOK |
> > > > http://autobuild.buildroot.net/results/d44aec8c82ed6a315322726dd698e6b48990ba76/
> > >
> > > ARC toolchain problem:
> > >
> > > error: '__NR_eventfd' was not declared in this scope
> > >
> > > Alexey, I don't remember, do you have a fix for this one?
> >
> > I already commented on that one.
> > Basically gnuradio includes source from boost and in boost itself they
> > use syscall directly if (__GLIBC__ == 2 && __GLIBC_MINOR__ < 8) which
> > is the case for uClibc, see http://git.uclibc.org/uClibc/tree/include/features.h#n395
> > -------------->8--------------
> > #define __GLIBC__ 2
> > #define __GLIBC_MINOR__ 2
> > -------------->8--------------
> >
> > From Boost standpoint this looks like some sort of backward compatibility for older
> > glibc that didn;'t have eventfd() defined.
> >
> > So probably the best option here is to bump __GLIBC__/__GLIBC_MINOR__ in uClibc.
> > Maybe Waldemar may comment on that?
>
> Can't we instead patch boost to use a || defined(__UCLIBC__) or
> something like that?
Well we may try but grep for __GLIBC_MINOR__ returns at least 10 files with matches.
That's why I'd prefer to just reuse existing code with __GLIBC__/__GLIBC_MINOR__.
If we may just say that we're on par with say __GLIBC__=2 __GLIBC_MINOR__=10 that
will cure a problem with Boost.
Let's get Waldemar's opinion on that and if he says __UCLIBC__ is the way to go we'll
figure out who's going to create that patch :)
See I sent 2 emails to Boost mailing list:
http://lists.boost.org/Archives/boost/2015/07/224257.php
http://lists.boost.org/Archives/boost/2015/07/224404.php
and haven't heard back.
So it might take a while until these guys accept our patch if at all.
-Alexey
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Buildroot] Analysis of build results for 2015-08-05
2015-08-10 11:54 ` Alexey Brodkin
@ 2015-08-10 18:08 ` Waldemar Brodkorb
2015-08-10 18:49 ` Alexey Brodkin
0 siblings, 1 reply; 20+ messages in thread
From: Waldemar Brodkorb @ 2015-08-10 18:08 UTC (permalink / raw)
To: buildroot
Hi Alexey, Hi Thomas,
Alexey Brodkin wrote,
> Hi Thomas,
>
> On Mon, 2015-08-10 at 13:36 +0200, Thomas Petazzoni wrote:
> > Dear Alexey Brodkin,
> >
> > On Mon, 10 Aug 2015 11:26:29 +0000, Alexey Brodkin wrote:
> >
> > > On Thu, 2015-08-06 at 11:30 +0200, Thomas Petazzoni wrote:
> > > > Hello all,
> > > > arc | gnuradio-3.7.5 | NOK |
> > > > > http://autobuild.buildroot.net/results/d44aec8c82ed6a315322726dd698e6b48990ba76/
> > > >
> > > > ARC toolchain problem:
> > > >
> > > > error: '__NR_eventfd' was not declared in this scope
> > > >
> > > > Alexey, I don't remember, do you have a fix for this one?
> > >
> > > I already commented on that one.
> > > Basically gnuradio includes source from boost and in boost itself they
> > > use syscall directly if (__GLIBC__ == 2 && __GLIBC_MINOR__ < 8) which
> > > is the case for uClibc, see http://git.uclibc.org/uClibc/tree/include/features.h#n395
> > > -------------->8--------------
> > > #define __GLIBC__ 2
> > > #define __GLIBC_MINOR__ 2
> > > -------------->8--------------
> > >
> > > From Boost standpoint this looks like some sort of backward compatibility for older
> > > glibc that didn;'t have eventfd() defined.
> > >
> > > So probably the best option here is to bump __GLIBC__/__GLIBC_MINOR__ in uClibc.
> > > Maybe Waldemar may comment on that?
> >
> > Can't we instead patch boost to use a || defined(__UCLIBC__) or
> > something like that?
>
> Well we may try but grep for __GLIBC_MINOR__ returns at least 10 files with matches.
> That's why I'd prefer to just reuse existing code with __GLIBC__/__GLIBC_MINOR__.
>
> If we may just say that we're on par with say __GLIBC__=2 __GLIBC_MINOR__=10 that
> will cure a problem with Boost.
>
> Let's get Waldemar's opinion on that and if he says __UCLIBC__ is the way to go we'll
> figure out who's going to create that patch :)
>
> See I sent 2 emails to Boost mailing list:
> http://lists.boost.org/Archives/boost/2015/07/224257.php
> http://lists.boost.org/Archives/boost/2015/07/224404.php
> and haven't heard back.
>
> So it might take a while until these guys accept our patch if at all.
May be we should do both. I can add __GLIBC_MINOR__=10 to uClibc-ng
and Alexey tries to get the || defined(__UCLIBC__) included into
boost.
Alexey, do you think we will get any regression by incrementing the
minor number for other architectures? I will try some boost compiles
later.
But do not forget, buildroot uses ARC specific uClibc fork, so it
will not fix the problem, until we switch to uClibc-ng for ARC.
best regards
Waldemar
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Buildroot] Analysis of build results for 2015-08-05
2015-08-10 18:08 ` Waldemar Brodkorb
@ 2015-08-10 18:49 ` Alexey Brodkin
2015-08-13 16:32 ` Alexey Brodkin
0 siblings, 1 reply; 20+ messages in thread
From: Alexey Brodkin @ 2015-08-10 18:49 UTC (permalink / raw)
To: buildroot
Hi Waldemar,
On Mon, 2015-08-10 at 20:08 +0200, Waldemar Brodkorb wrote:
> Hi Alexey, Hi Thomas,
> Alexey Brodkin wrote,
>
> > Hi Thomas,
> >
> > On Mon, 2015-08-10 at 13:36 +0200, Thomas Petazzoni wrote:
> > > Dear Alexey Brodkin,
> > >
> > > On Mon, 10 Aug 2015 11:26:29 +0000, Alexey Brodkin wrote:
> > >
> > > > On Thu, 2015-08-06 at 11:30 +0200, Thomas Petazzoni wrote:
> > > > > Hello all,
> > > > > arc | gnuradio-3.7.5 | NOK |
> > > > > > http://autobuild.buildroot.net/results/d44aec8c82ed6a315322726dd698e6b48990ba76/
> > > > >
> > > > > ARC toolchain problem:
> > > > >
> > > > > error: '__NR_eventfd' was not declared in this scope
> > > > >
> > > > > Alexey, I don't remember, do you have a fix for this one?
> > > >
> > > > I already commented on that one.
> > > > Basically gnuradio includes source from boost and in boost itself they
> > > > use syscall directly if (__GLIBC__ == 2 && __GLIBC_MINOR__ < 8) which
> > > > is the case for uClibc, see http://git.uclibc.org/uClibc/tree/include/features.h#n395
> > > > -------------->8--------------
> > > > #define __GLIBC__ 2
> > > > #define __GLIBC_MINOR__ 2
> > > > -------------->8--------------
> > > >
> > > > From Boost standpoint this looks like some sort of backward compatibility for older
> > > > glibc that didn;'t have eventfd() defined.
> > > >
> > > > So probably the best option here is to bump __GLIBC__/__GLIBC_MINOR__ in uClibc.
> > > > Maybe Waldemar may comment on that?
> > >
> > > Can't we instead patch boost to use a || defined(__UCLIBC__) or
> > > something like that?
> >
> > Well we may try but grep for __GLIBC_MINOR__ returns at least 10 files with matches.
> > That's why I'd prefer to just reuse existing code with __GLIBC__/__GLIBC_MINOR__.
> >
> > If we may just say that we're on par with say __GLIBC__=2 __GLIBC_MINOR__=10 that
> > will cure a problem with Boost.
> >
> > Let's get Waldemar's opinion on that and if he says __UCLIBC__ is the way to go we'll
> > figure out who's going to create that patch :)
> >
> > See I sent 2 emails to Boost mailing list:
> > http://lists.boost.org/Archives/boost/2015/07/224257.php
> > http://lists.boost.org/Archives/boost/2015/07/224404.php
> > and haven't heard back.
> >
> > So it might take a while until these guys accept our patch if at all.
>
> May be we should do both. I can add __GLIBC_MINOR__=10 to uClibc-ng
> and Alexey tries to get the || defined(__UCLIBC__) included into
> boost.
>
> Alexey, do you think we will get any regression by incrementing the
> minor number for other architectures? I will try some boost compiles
> later.
If I knew this for sure I wouldn't ask you :)
That's why I'm not sure which is a good MINOR number to bump to.
I'm not sure if 2.2 was intentionally used in the first place in uClibc,
did that mean that all [important?] features of glibc 2.2 were supported
in uClibc back in the day?
This is a commit that bumped from 2.1 to 2.2:
http://git.uclibc.org/uClibc/commit/?id=e83a36ce9f97ac0f59117b3a62fd2dd8461b1fd5
Frankly I may barely see a rationale for that last bump.
So there're IMHO 3 options for uClibc:
[1] Leave __GLIBC__ versions as they are today (2.2)
[2] Bump those versions to something that is supposed to fix existing issue
with Boost and see if it breaks more than fixes
[3] Do good analysis of glibc features, compare to what we have in uClibc and
with that knowledge set __GLIBC__ versions in uClibc
> But do not forget, buildroot uses ARC specific uClibc fork, so it
> will not fix the problem, until we switch to uClibc-ng for ARC.
Well our intention is to drop ARC-specific git repo in favor to upstream
distributions of uClibc. Even today uClibc in ARC's GitHub is just a mirror
of master @ git.uclibc.org. But the problem with goode olde uClibc is there're
no releases so it is useless for us as a method of distribution.
That said for Buildroot I'm about to discontinue uClibc from ARC git and use
your uClibc-ng instead. So one Buildroot v2015.08 is cut I'll send a patch with
removal of BR2_UCLIBC_VERSION_ARC_GIT.
-Alexey
^ permalink raw reply [flat|nested] 20+ messages in thread* [Buildroot] Analysis of build results for 2015-08-05
2015-08-10 18:49 ` Alexey Brodkin
@ 2015-08-13 16:32 ` Alexey Brodkin
2015-08-14 21:48 ` Waldemar Brodkorb
0 siblings, 1 reply; 20+ messages in thread
From: Alexey Brodkin @ 2015-08-13 16:32 UTC (permalink / raw)
To: buildroot
Hi Waldemar, Thomas,
On Mon, 2015-08-10 at 21:49 +0300, Alexey Brodkin wrote:
> Hi Waldemar,
>
> On Mon, 2015-08-10 at 20:08 +0200, Waldemar Brodkorb wrote:
> > Hi Alexey, Hi Thomas,
> > Alexey Brodkin wrote,
> >
> > > Hi Thomas,
> > >
> > > On Mon, 2015-08-10 at 13:36 +0200, Thomas Petazzoni wrote:
> > > > Dear Alexey Brodkin,
> > > >
> > > > On Mon, 10 Aug 2015 11:26:29 +0000, Alexey Brodkin wrote:
> > > >
> > > > > On Thu, 2015-08-06 at 11:30 +0200, Thomas Petazzoni wrote:
> > > > > > Hello all,
> > > > > > arc | gnuradio-3.7.5 | NOK |
> > > > > > > http://autobuild.buildroot.net/results/d44aec8c82ed6a315322726dd698e6b48990ba76/
> > > > > >
> > > > > > ARC toolchain problem:
> > > > > >
> > > > > > error: '__NR_eventfd' was not declared in this scope
> > > > > >
> > > > > > Alexey, I don't remember, do you have a fix for this one?
> > > > >
> > > > > I already commented on that one.
> > > > > Basically gnuradio includes source from boost and in boost itself they
> > > > > use syscall directly if (__GLIBC__ == 2 && __GLIBC_MINOR__ < 8) which
> > > > > is the case for uClibc, see http://git.uclibc.org/uClibc/tree/include/features.h#n395
> > > > > -------------->8--------------
> > > > > #define __GLIBC__ 2
> > > > > #define __GLIBC_MINOR__ 2
> > > > > -------------->8--------------
> > > > >
> > > > > From Boost standpoint this looks like some sort of backward compatibility for older
> > > > > glibc that didn;'t have eventfd() defined.
> > > > >
> > > > > So probably the best option here is to bump __GLIBC__/__GLIBC_MINOR__ in uClibc.
> > > > > Maybe Waldemar may comment on that?
> > > >
> > > > Can't we instead patch boost to use a || defined(__UCLIBC__) or
> > > > something like that?
> > >
> > > Well we may try but grep for __GLIBC_MINOR__ returns at least 10 files with matches.
> > > That's why I'd prefer to just reuse existing code with __GLIBC__/__GLIBC_MINOR__.
> > >
> > > If we may just say that we're on par with say __GLIBC__=2 __GLIBC_MINOR__=10 that
> > > will cure a problem with Boost.
> > >
> > > Let's get Waldemar's opinion on that and if he says __UCLIBC__ is the way to go we'll
> > > figure out who's going to create that patch :)
> > >
> > > See I sent 2 emails to Boost mailing list:
> > > http://lists.boost.org/Archives/boost/2015/07/224257.php
> > > http://lists.boost.org/Archives/boost/2015/07/224404.php
> > > and haven't heard back.
> > >
> > > So it might take a while until these guys accept our patch if at all.
> >
> > May be we should do both. I can add __GLIBC_MINOR__=10 to uClibc-ng
> > and Alexey tries to get the || defined(__UCLIBC__) included into
> > boost.
> >
> > Alexey, do you think we will get any regression by incrementing the
> > minor number for other architectures? I will try some boost compiles
> > later.
>
> If I knew this for sure I wouldn't ask you :)
> That's why I'm not sure which is a good MINOR number to bump to.
> I'm not sure if 2.2 was intentionally used in the first place in uClibc,
> did that mean that all [important?] features of glibc 2.2 were supported
> in uClibc back in the day?
>
> This is a commit that bumped from 2.1 to 2.2:
> http://git.uclibc.org/uClibc/commit/?id=e83a36ce9f97ac0f59117b3a62fd2dd8461b1fd5
>
> Frankly I may barely see a rationale for that last bump.
> So there're IMHO 3 options for uClibc:
>
> [1] Leave __GLIBC__ versions as they are today (2.2)
> [2] Bump those versions to something that is supposed to fix existing issue
> with Boost and see if it breaks more than fixes
> [3] Do good analysis of glibc features, compare to what we have in uClibc and
> with that knowledge set __GLIBC__ versions in uClibc
>
> > But do not forget, buildroot uses ARC specific uClibc fork, so it
> > will not fix the problem, until we switch to uClibc-ng for ARC.
>
> Well our intention is to drop ARC-specific git repo in favor to upstream
> distributions of uClibc. Even today uClibc in ARC's GitHub is just a mirror
> of master @ git.uclibc.org. But the problem with goode olde uClibc is there're
> no releases so it is useless for us as a method of distribution.
>
> That said for Buildroot I'm about to discontinue uClibc from ARC git and use
> your uClibc-ng instead. So one Buildroot v2015.08 is cut I'll send a patch with
> removal of BR2_UCLIBC_VERSION_ARC_GIT.
I may confirm that http://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/?id=4ff3a6c8eb91db71d6dc3d2932b66e848bd20ac3
fixes boost building for ARC.
Waldemar, are you going to send that patch in uClibc mailing-list?
-Alexey
^ permalink raw reply [flat|nested] 20+ messages in thread