<br><br>On Monday, September 16, 2013, Phil Blundell <<a href="mailto:pb@pbcl.net">pb@pbcl.net</a>> wrote:<br>> On Mon, 2013-09-16 at 09:24 -0700, Khem Raj wrote:<br>>> On Sat, Sep 14, 2013 at 12:19 AM, Phil Blundell <<a href="mailto:pb@pbcl.net">pb@pbcl.net</a>> wrote:<br>
>> > On Fri, 2013-09-13 at 21:24 -0700, Khem Raj wrote:<br>>> >> There are cases where we have bsps with 2.6.3x kernels and libc<br>>> >> compiled against 3.10 assumes syscalls<br>>> ><br>
>> > That is a bug in glibc. It should not be doing that unless configured<br>>> > --enable-kernel=3.10.x (and this is the whole point of the<br>>> > --enable-kernel option). If it's assuming 3.10.x syscalls under<br>
>> > --enable-kernel=2.6.x then it is broken and should be fixed.<br>>> ><br>>><br>>> we have OLDEST_KERNEL = "2.6.16" and thats not a problem. However one<br>>> case where it showed up was when building udev > 164 with kernels<br>
>> where accept4 call was not wired for arm e.g. since udev looked up<br>>> definition of SOCK_CLOEXEC which it found but that 2.6.32 kernel<br>>> really did not support it.<br>><br>> That sounds slightly different to the problem you were originally<br>
> describing ("libc compiled against 3.10") but I think the answer is<br>> basically still the same: it is a bug in udev, and udev ought to be<br>> fixed.<br>><br><br>if you check for kernel version yes but its not wrong by testing a given kernel API which it is doing<br>
<br>anyway i think the notice that rp added is good in general and may be will help folks to upgrade and unify kernels in long run<br>> p.<br>><br>><br>>