Hi Mike,

man makedev/major/minor does not mention anything about this header, although it does mention (the missing) #define _BSD_SOURCE. Does that get thinks working again?

Can you please send a patch (git send-email ideally) to the list. Also please quote the build error and any related information on the topic that you can find.

If you can do the same for mesa that'll be greatly appreciated.

Thank you

The issue is sys/sysmacros.h has been dropped from sys/types.h in glibc 2.23

Do you know if this can be safely added in for everything or will it need some ifdeffery?

If it's straight forward I'll get the patches out later today (there's one for xorg-server too)

Are you sure about the removal of "include sys/sysmacros.h" ? Afaics include/sys/types.h includes the posix/sys/types.h with the latter still having the include.

Bth I'm not sure if things can explode with the unconditional include, imho it's better to keep things as documented.

I.e. if the _BSD_SOURCE define does not help, then either glibc needs to be fixed or the manuals should be updated (the glibc fold might have some suggestions) ?

(In reply to Emil Velikov from comment #3)
> I.e. if the _BSD_SOURCE define does not help, then either glibc needs to be
> fixed or the manuals should be updated (the glibc fold might have some
> suggestions) ?

_BSD_SOURCE gets defined if you call AC_USE_SYSTEM_EXTENSIONS from configure.ac, which gives you the maximal set of defines. It's not safe to just define the _*_SOURCE macros, since whilst glibc etc treat them as additive, BSD libcs treat them as restrictive (e.g. defining _BSD_SOURCE gives you a pure BSD environment without some of the features enabled by, e.g., _XOPEN_SOURCE).

(In reply to Daniel Stone from comment #4)
> _BSD_SOURCE gets defined if you call AC_USE_SYSTEM_EXTENSIONS

Are you sure about this ? Looking at my autoconf 2.69 (/usr/share/autoconf/autoconf/specific.m4) and it sets the following

__EXTENSIONS__
_ALL_SOURCE
_GNU_SOURCE
_POSIX_PTHREAD_SEMANTICS
_TANDEM_SOURCE

Had no idea about the different interpretation of the defines between GNU vs BSD libc(s). Thanks for that.

We can at check if the explicit define fixes things on Linux and ping the BSD people for more robust solution ?

Here's the Gentoo bug for this issue - there's a few packages affected

https://bugs.gentoo.org/show_bug.cgi?id=575232

Hmm... Gentoo devs decided to patch glibc in order to remove the include.

At the same time they lean that applications (25+ based on the incomplete list) should be fixed to use sys/sysmacros.h. There's no justification and the manual does not support this :-(

To make it even more strange the patch isn't alongside the glibc-2.23.ebuild in the repo. Am I looking at the wrong repo ? Can anyone share a link with discussion behind this decision ?

The patches are bundled up into a tar file: glibc-2.23-patches-1.tar.bz2 which is on the gentoo mirrors

Created attachment 121891 [details]
Glibc patches

Here's the patch tarball for your convenience

And the relevant details:

Subject: [PATCH] sys/types.h: drop sys/sysmacros.h include

We want to break apart this include path due to namespace pollution.
https://sourceware.org/ml/libc-alpha/2015-11/msg00253.html

Thanks for the links Mike.

Not sure about others, but I'm not a happy bunny.

So there's a issue/bug in stdlib.h (or was it g++), that leads to the inclusion of sys/types.h. To 'fix' this lets break the documented behaviour (for those of us that read the manpages). Hmm ... wait what ?

Sorry but this sounds backwards. If we cannot squash the issue, it should be documented properly with list of workarounds (as pointed in the redhat bugzilla).
Yes it sucks, big time. Yet we shouldn't break one thing, in order to workaround another issue, should we ?

If this workaround is needed/applicable with other libc providers like musl (on Linux at least), then there should be a documentation update alongside the deprecation. Followed by a lengthy period _before_ removing things ?

it's really not that difficult to test for & include the sys/sysmacros.h header directly when you're using the non-standard functions they provide.  this is the API under BSD systems, and where Linux C libs have already moved/are moving towards.  *this* is the deprecation period.

upstream glibc will take a more measured approach including updating their docs, but realistically, no one is going to read those until they see breakage.  the Gentoo changes are only in an opt-in dev-only build, so it too isn't hitting people randomly.

as the upstream thread shows, if you used the (long time documented) AC_HEADER_MAJOR macro in autoconf, then this wouldn't have impacted drm.

Your suggestion is not unreasonable my any means. Yes, it's not hard to test (and include) the header, but it's unnecessary according to the documentation.

I'll repeat my request - please update documentation, provide warnings and deprecation _period_. Do not just remove the include and then point fingers at projects because "they're not doing X" when there is no official information that say they should :-)

TL DR; as soon as the manual is updated I'll be more than happy to get this in.

I'll get the patches created for libdrm, mesa & xorg-server, Mike F please can you provide the location of where the updated docs are and I'll include it in the commit message

Emil is there anything else you'd like? I'm going to mention the I provided above too

Mike L adding a reference to the updated docs or a mention "since man-pages version X" plus a bugzilla link (if applicable) would be amazing. Thanks !

(In reply to Emil Velikov from comment #13)

that is happening in upstream glibc.  i'm not going to bother in Gentoo.

no one is "pointing fingers".  we detected an error in libdrm in Gentoo, hence you guys got a patch.  i don't know why you're upset about this.

Well I never meant that Gentoo people should update anything bth. As the deprecation is a joint effort (hopefully musl and others are involved) someone 
from the team involved should ping/update the man-pages.

As is, it's a case of the cart going before the horse - fix the code first, then document the new requirement :-\

The "pointing fingers" quote is metaphorical, no offence meant towards anyone.

I guess you can think of this as the deprecation period.


Documentation has been updated:

https://github.com/mkerrisk/man-pages/commit/3350a86413d770198e11fe8df9a3cd5710240dc3

That was fast, only a few hours ago the commit landed.

No objections about having this in, although let's use AC_CHECK_HEADERS.

I'm wondering if we shouldn't give it a day or two before landing though. Obviously waiting for a man-pages release would be a serious overkill (afaict it will be within ~4 months).

(In reply to Emil Velikov from comment #19)
> That was fast, only a few hours ago the commit landed.
> 
> No objections about having this in, although let's use AC_CHECK_HEADERS.
> 
> I'm wondering if we shouldn't give it a day or two before landing though.
> Obviously waiting for a man-pages release would be a serious overkill
> (afaict it will be within ~4 months).

Do you want to commit it... or do you want me to send it to the list?

Should have mentioned it earlier - I thought the more portable thing was to use AC_HEADER_MAJOR. Can we do that one as opposed to unconditionally including the header ?

Created attachment 124642 [details] [review]
using AC_CHECK_HEADERS()

Created attachment 124643 [details] [review]
using AC_CHECK_HEADERS

Thanks for updating the man pages as well as the patch(es) Mike. Hope you and/or others will get to resolving libstdc++ + _GNU_SOURCE issue that inspired this.

I've pushed the AC_HEADER_MAJOR patch to master.