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

Benoît Thébaudeau benoit.thebaudeau at advansee.com
Thu May 15 12:44:11 UTC 2014


Hi Baruch,

On Thursday, May 15, 2014 5:44:47 AM, Baruch Siach wrote:
> On Thu, May 15, 2014 at 12:10:06AM +0200, Benoît Thébaudeau wrote:
> > On Wed, May 14, 2014 at 11:41 PM, Baruch Siach <baruch at tkos.co.il> wrote:
> > > 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,
> > 
> > By "sometimes", do you mean that the test also fails sometimes with this
> > patch?
> 
> I haven't observed such a failure. But target headers include some
> architecture specific definitions. Mixing these with host predefined macros
> (output of 'gcc -dM -E - < /dev/null') feels like a bad idea. Things like
> endianess and types sizeof mismatches might break tests in unexpected ways.

Right.

> > > but mixing host toolchain with target
> > > headers doesn't look like a good idea.
> > 
> > With this patch, it is less mixed than before, and some of the other
> > tests performed by the configuration script still try to
> > cross-configure using the native toolchain. The test fixed here only
> > looks at the definitions from the header files, so mixing the native
> > toolchain with the cross header files should not be an issue if the
> > native and cross header files are no longer mixed thanks to --sysroot.
> > 
> > Also, 'LSOF_INCLUDE="$(STAGING_DIR)/usr/include"' is explicitly asking
> > the configuration script to mix native and cross stuff for tests.
> 
> This should be fixed then. I'll look into it.

Cool. OTOH, the worst test is probably the one for strftime() support, which
just tests native toolchain features by running code on the build machine (not
just testing #define-s). Most of the other tests do things like for GLIBC, hence
a lot of mix-up in the header files.

> > >> 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.
> > 
> > Correct.

Benoît


More information about the buildroot mailing list