[Buildroot] [autobuild.buildroot.net] Build results for 2014-05-11

Baruch Siach baruch at tkos.co.il
Wed May 14 21:41:41 UTC 2014


Hi Benoît,

Please keep the list on Cc.

On Wed, May 14, 2014 at 11:22:34PM +0200, Benoît Thébaudeau wrote:
> On Wed, May 14, 2014 at 10:56 PM, Baruch Siach <baruch at tkos.co.il> wrote:
> > On Tue, May 13, 2014 at 10:01:02AM +0200, Thomas Petazzoni wrote:
> >> On Tue, 13 May 2014 10:52:47 +0300, Baruch Siach wrote:
> >>
> >> > On Tue, May 13, 2014 at 09:44:26AM +0200, Thomas Petazzoni wrote:
> >> > > >        arm |                      lsof-4.85 | NOK | http://autobuild.buildroot.net/results/a1f0572dbf968c21f70b35cefff7ef7a1d9a348a/
> >> > >
> >> > > Missing TCP_* definitions. Weird because the toolchain has recent
> >> > > kernel headers (3.12) and uses glibc. Investigation needed.
> >> >
> >> > http://patchwork.ozlabs.org/patch/345018/ seems applicable (but I didn't test).
> >>
> >> Indeed, but I'm not really convinced by the fix, seems strange that
> >> --sysroot needs to be passed. More investigation is needed to validate
> >> the proposed fix, I believe.
> >
> > Right. It just papers over the real problem which is building a target config
> > test using the host toolchain, and then running it. The patch at
> > http://patchwork.ozlabs.org/patch/348765/ is better, I believe.
> 
> The issue in my case was that the native toolchain used for the
> configure test implicitly #included a header file, which triggered a
> conflict of direct inclusion between the native and cross toolchains
> header files. Passing --sysroot forces the native toolchain to only
> use the header files from the cross toolchain, fixing this conflict.
> This directly addresses the issue without any assumption regarding the
> cross libc.

This make the test succeed sometimes, but mixing host toolchain with target 
headers doesn't look like a good idea.

> http://patchwork.ozlabs.org/patch/348765/ works too, but it removes a
> configure test and it relies on the "all libc variants we support have
> the netinet/tcp.h header" assumption, which might become wrong in the
> future, which is why I didn't choose this solution.

The alternative header, linux/tcp.h, is broken anyway, because this header 
does not export the TCP_* symbols, as you can see from the build failure error 
message. So getting this test "right" won't help us much.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -


More information about the buildroot mailing list