From mboxrd@z Thu Jan 1 00:00:00 1970 From: Baruch Siach Date: Thu, 15 May 2014 00:41:41 +0300 Subject: [Buildroot] [autobuild.buildroot.net] Build results for 2014-05-11 In-Reply-To: References: <20140512063008.74E21100DB2@stock.ovh.net> <20140513094426.335d2361@free-electrons.com> <20140513075247.GZ4096@tarshish> <20140513100102.14163e6c@free-electrons.com> <20140514205653.GL4096@tarshish> Message-ID: <20140514214141.GM4096@tarshish> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net 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 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 -