I just ran into this on a new wheezy install. It's a shame it won't be fixed in wheezy, although I've looked into it deeply enough that I can easily fix it locally for myself.
On Sun, Jan 27, 2013 at 7:43 AM, intrigeri <intrig...@boum.org> wrote: > > 2. Any comment on Adam's reasoning about how the fix is sub-optimal, > > and about his suggestions to improve it? (Related question: what's > > the upstream status of this patch, by the way?) > > > I'm still curious about this, even if it's now probably unrelated to > the matter at hand. > > I'd like to second Adam's comments from < http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691115#10>, which were that "code outside of the C library should never define __USE_GNU" and that _GNU_SOURCE should be defined before the first include. The manual for the GNU C library < http://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html#Feature-Test-Macros> states that "these directives **must** come before any #include of a system header file." (emphasis by them, not me) The directives they are talking about are the ones with the single underscores, such as _GNU_SOURCE. Documentation on __USE_GNU can be found in /usr/include/features.h. It says "These are defined by this file and are used by the header files to decide what to declare or define." __USE_GNU is defined by features.h iff _GNU_SOURCE has been defined by the user before the first glibc header file has been included. As Adam says, it's an internal implementation detail. As for the status of the patch upstream, do you mean the status of the patch Debian has added to get libdvdread to build on HURD (and which is the cause of this bug)? Or the patch to fix this bug? I googled around and couldn't find any trace of the original patch being submitted upstream. It doesn't seem to have been applied in their SVN. So they won't need the fix for this bug. It does concern me that similar broken "fixes" for building on HURD may have been applied to other packages throughout Debian. :(
