[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: problems compiling with glibc-2.8
Luca Scamoni writes:
> Sadly the bug has been reported to the same "friendly" guy at redhat
> that we learned to know thanks to Ralf and his bug on getaddrinfo.
> So the answer has been more or less on the same line: "this is not a
> bug. go and fix your app"
Quoting him at <http://sourceware.org/bugzilla/show_bug.cgi?id=6545>:
> "This is a POSIX header and ucred is not in the POSIX namespace."
Should _BSD_SOURCE or _SVID_SOURCE provide struct ucred? If so the
problem this time is hopefully only that he didn't know the struct is
not a Gnu invention.
See glibc-20080519/include/features.h about the feature test macros:
The `-ansi' switch to the GNU C compiler defines __STRICT_ANSI__.
If none of these are defined, the default is to have _SVID_SOURCE,
_BSD_SOURCE, and _POSIX_SOURCE set to one and _POSIX_C_SOURCE set to
200112L. If more than one of these are defined, they accumulate.
For example __STRICT_ANSI__, _POSIX_SOURCE and _POSIX_C_SOURCE
together give you ISO C, 1003.1, and 1003.2, but nothing else.
Further from the glibc response:
> "Fix you app to pass the correct flags."
Well, headers in several OSes broke at least some years ago when one
#defined feature test macros like _POSIX_SOURCE. IIRC including some
glibc headers. Still, they've all had decades to clean up now.
My impression is that C implementations have been getting stricter about
enforcing conformance to the various standards they support over the
years. However like gcc and glibc they have more than just pure ISO C
as default, to avoid too many broken apps and annoyed users/customers.
So I expect we'll have to follow his advice someday, the question is
when. In any case, plenty of other packages will be in the same
situation, so we could push the matter to the autoconf list.
--
Hallvard