git 9c501935a3cd broke the strace build.

git 9c501935a3cd broke the strace build.

[Rob Landley]

>    net: Support inclusion of <linux/socket.h> before <sys/socket.h>
>   
>    The following user-space program fails to compile:
>    
>        #include <linux/socket.h>
>        #include <sys/socket.h>

Did it ever?  Isn't #including both sys/thingy and a linux/thingy in the same 
program considered bad form?

>        int main() { return 0; }
>    
>    The reason is that <linux/socket.h> tests __GLIBC__ to decide whether it
>    should define various structures and macros that are now defined for
>    user-space by <sys/socket.h>, but __GLIBC__ is not defined if no libc
>    headers have yet been included.

Specifically, one of the tests was !__GLIBC__, I.E. checking that we _haven't_ 
included any of glibc's headers yet, which is presumably how you broke the 
strace 4.5.18 ./configure test checking for the existence of the 
linux/netlink.h file.  (That test #includes stddef.h, linux/socket.h, and 
linux/netlink.h and nothing else.  Since stddef.h is a gcc header and not a 
glibc header, __GLIBC__ isn't defined for the test code and thus that used to 
work under 2.5.31.  Now under 2.6.32 it dies with:

  linux/netlink.h:35: error: expected specifier-qualifier-list before
  'sa_family_t'

And later on the strace build breaks because it doesn't #include 
linux/netlink.h when it needs to.  (Why yes, autoconf _is_ brittle and near-
useless, thanks for noticing.)

*shrug*  I can patch the strace ./configure to include bits/socket.h instead of 
linux/socket.h, but what I can't understand is why _you_ couldn't.  (What use 
case did this patch actually fix?  Would reversing the order of those two 
headers have helped?)

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds

Re: git 9c501935a3cd broke the strace build.

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1621 bytes --]

On Thu, 2010-01-14 at 04:57 -0600, Rob Landley wrote:
> >    net: Support inclusion of <linux/socket.h> before <sys/socket.h>
> >   
> >    The following user-space program fails to compile:
> >    
> >        #include <linux/socket.h>
> >        #include <sys/socket.h>
> 
> Did it ever?  Isn't #including both sys/thingy and a linux/thingy in the same 
> program considered bad form?

I don't see why.

Even if a source file doesn't include both of them directly, they may
both be included indirectly.

[...]
> Now under 2.6.32 it dies with:
> 
>   linux/netlink.h:35: error: expected specifier-qualifier-list before
>   'sa_family_t'

I did actually ask for this to be reverted when I saw that it causes
breakage elsewhere, but David Miller insisted that my change was
correct.

> And later on the strace build breaks because it doesn't #include 
> linux/netlink.h when it needs to.  (Why yes, autoconf _is_ brittle and near-
> useless, thanks for noticing.)
> 
> *shrug*  I can patch the strace ./configure to include bits/socket.h instead of 
> linux/socket.h,

Including libc headers under 'bits' is a bad idea.

> but what I can't understand is why _you_ couldn't.  (What use 
> case did this patch actually fix?  Would reversing the order of those two 
> headers have helped?)

I think that reversing the order of the two headers should work for
kernel headers before and after this change.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
                                                            - Robert Coveyou

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]