Thought I would just drop in a note on this...
There have been changes with glibc 2.8. Now struct ucred is ifdef'd under _GNU_SOURCE
Maybe configure should detect if it's needed?
Luca Scamoni wrote:
Thought I would just drop in a note on this...
There have been changes with glibc 2.8. Now struct ucred is ifdef'd under _GNU_SOURCE
Maybe configure should detect if it's needed?
I suggest filing a bug with the glibc folks. struct ucred is not a GNU-specific extension, it's a standard structure in Unix. I don't see how it qualifies for hiding with _GNU_SOURCE.
Howard Chu wrote:
Luca Scamoni wrote:
Thought I would just drop in a note on this...
There have been changes with glibc 2.8. Now struct ucred is ifdef'd under _GNU_SOURCE
Maybe configure should detect if it's needed?
I suggest filing a bug with the glibc folks. struct ucred is not a GNU-specific extension, it's a standard structure in Unix. I don't see how it qualifies for hiding with _GNU_SOURCE.
Done. Bug libc/6545
I'll keep you up to date.
Luca Scamoni ha scritto:
Howard Chu wrote:
Luca Scamoni wrote:
Thought I would just drop in a note on this...
There have been changes with glibc 2.8. Now struct ucred is ifdef'd under _GNU_SOURCE
Maybe configure should detect if it's needed?
I suggest filing a bug with the glibc folks. struct ucred is not a GNU-specific extension, it's a standard structure in Unix. I don't see how it qualifies for hiding with _GNU_SOURCE.
Done. Bug libc/6545
I'll keep you up to date
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" My knowledge is not deep enough on this subject to discuss with him (supposing that: i) there is something to discuss; ii) it's worth to discuss with someone that simply denies to offer any explanation of any kind) Anyone wants to step in?
Ing. Luca Scamoni Responsabile Ricerca e Sviluppo
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Mobile: +39 347 1014425 Email: luca.scamoni@sys-net.it -----------------------------------
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 B Furuseth h.b.furuseth@usit.uio.no writes:
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.
Pure System V does this a different way, so I doubt _SVID_SOURCE should. Not sure about _BSD_SOURCE; that would be the most likely one. Note that _GNU_SOURCE isn't only used for GNU extensions; it's basically used for anything that doesn't fall into a clear standard.
So protecting with _GNU_SOURCE doesn't mean that glibc maintainers think it's a uniquely GNU extension, just that they don't think it falls into one of the other standard feature-test macros.
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.
These days, I basically always use the AC_GNU_SOURCE Autoconf macro to define _GNU_SOURCE, since I almost always run into something that glibc hides unless you define _GNU_SOURCE. Unless you're trying to maintain tight control over what enters your namespace, fighting with the standardized feature-test macros is often more trouble than it's worth.
On Mittwoch, 21. Mai 2008, Luca Scamoni wrote:
Thought I would just drop in a note on this...
There have been changes with glibc 2.8. Now struct ucred is ifdef'd under _GNU_SOURCE
Btw, I submitted this as ITS#5464 some weeks ago.
Maybe configure should detect if it's needed?
Ralf Haferkamp wrote:
On Mittwoch, 21. Mai 2008, Luca Scamoni wrote:
Thought I would just drop in a note on this...
There have been changes with glibc 2.8. Now struct ucred is ifdef'd under _GNU_SOURCE
Btw, I submitted this as ITS#5464 some weeks ago.
Maybe configure should detect if it's needed?
Sorry. I missed it. :-o
-
Hallvard B Furuseth -
Howard Chu -
Luca Scamoni -
Luca Scamoni -
Ralf Haferkamp -
Russ Allbery