Version in question: glibc-2.19.90-1.fc21

This is expected. The warning is correct. The _BSD_SOURCE and _SVID_SOURCE feature test macros are deprecated as of glibc 2.19.90 (2.20 devel).

What defines _BSD_SOURCE or _SVID_SOURCE for you?

Created attachment 865604 [details]
Plan 9 from User Space include/u.h - shipped as part of golang

u.h that's part of the golang source distribution (attached)

You have several options.

The first question is: Do you really need those feature macros defined?

I would start by removing them and building.

Those definitions may just have been copied blindly from other source configurations without thinking about the interfaces they enable.

If you do need the interfaces enabled by _BSD_SOURCE and or _SVID_SOURCE, then you can do the following:

#if defined __linux__ || defined __GNU__ || defined __GLIBC__
#define _DEFAULT_SOURCE 1
#else
#define _BSD_SOURCE 1
#define _SVID_SOURCE 1
#endif

So you have two options to try.

Build without those macros and see if it works, this tests to see if you actually ever needed them.

Modify the headers to define _DEFAULT_SOURCE instead which is the new all-encompassing feature test macro.

Notice that the old feature test macros are not deprecated yet, but we are issuing a warning. In your case with -Werror the warning is treated as if it were an error.

It appears that the macro is needed, I've patched using what you provided and it worked. I'll close this as NOTABUG, thank you for your help and apologies for the line noise.

(In reply to Adam Miller from comment #6)
> It appears that the macro is needed, I've patched using what you provided
> and it worked. I'll close this as NOTABUG, thank you for your help and
> apologies for the line noise.

No need to apologize, I'm a glibc expert and I'm here to help. It was perfectly valid to reach out for assistance on this issue. I'm glad things are working again.

Carlos, what is the official rune to make -Werror code build with both old
and new glibc, which had some reason for _BSD_SOURCE?

NOTABUG seems like an unfortunate way of brushing off build breakage due
to this glibc change.

(In reply to Frank Ch. Eigler from comment #8)
> Carlos, what is the official rune to make -Werror code build with both old
> and new glibc, which had some reason for _BSD_SOURCE?
> 
> NOTABUG seems like an unfortunate way of brushing off build breakage due
> to this glibc change.

I'm facing the same problem with my package. Carlos, please shed light on this.

(In reply to Petr Spacek from comment #9)
> (In reply to Frank Ch. Eigler from comment #8)
> > Carlos, what is the official rune to make -Werror code build with both old
> > and new glibc, which had some reason for _BSD_SOURCE?
> > 
> > NOTABUG seems like an unfortunate way of brushing off build breakage due
> > to this glibc change.
> 
> I'm facing the same problem with my package. Carlos, please shed light on
> this.

The way this is going to work is like this:

https://sourceware.org/glibc/wiki/Release/2.20#Packaging_Changes

This isn't the way it works yet in Fedora Rawhide, but it will in about 24 hours.

See: https://sourceware.org/bugzilla/show_bug.cgi?id=16632

*** Bug 1074180 has been marked as a duplicate of this bug. ***

This also affects ghc on some secondary archs BTW:
I will try patching to _DEFAULT_SOURCE.

https://github.com/ghc/ghc/blob/master/includes/Stg.h#L49 currently has:

:
#ifndef IN_STG_CODE
# define IN_STG_CODE 1

// Turn on C99 for .hc code.  This gives us the INFINITY and NAN
// constants from math.h, which we occasionally need to use in .hc (#1861)
# define _ISOC99_SOURCE

// We need _BSD_SOURCE so that math.h defines things like gamma
// on Linux
# define _BSD_SOURCE
#endif
:

Any suggestions for now to update that to prefer _DEFAULT_SOURCE
upstream in a portable manner?

Jens, you could just add

   #define _DEFAULT_SOURCE

to what's already there.