glibc 2.23 and undefined reference to `minor' or `major'

[Tyler_Durden]

i had problems emerging gnome-base/gvfs:

Code: Select all

gnome-base/gvfs-1.26.3::gentoo  USE="bluray cdda gnome-online-accounts google gphoto2 gtk http ios mtp nfs samba systemd udev udisks zeroconf -afp -archive -fuse -gnome-keyring {-test}"

./.libs/libmetadata.a(metatree.o): In function `meta_lookup_cache_lookup_path':
metatree.c:(.text+0x55f0): undefined reference to `minor'
metatree.c:(.text+0x55fd): undefined reference to `major'
collect2: error: ld returned 1 exit status

and media-libs/mesa:

Code: Select all

media-libs/mesa-11.1.2-r1::gentoo  USE="classic dri3 egl gallium gbm gles2 llvm nptl opencl udev vdpau wayland xvmc -bindist -d3d9 -debug -gles1 -openmax -osmesa -pax_kernel -pic (-selinux) -vaapi -xa" ABI_X86="32 (64) (-x32)" VIDEO_CARDS="(-freedreno) -i915 -i965 -ilo -intel -nouveau -r100 -r200 -r300 -r600 -radeon -radeonsi -vmware"


/var/tmp/portage/media-libs/mesa-11.1.2-r1/work/mesa-11.1.2/src/gbm/main/gbm.c: In function ‘_gbm_mesa_get_device’:
/var/tmp/portage/media-libs/mesa-11.1.2-r1/work/mesa-11.1.2/src/gbm/main/gbm.c:120:11: error: implicit declaration of function ‘major’ [-Werror=implicit-function-declaration]
       if (major(dev) == major(buf.st_rdev) &&
           ^
/var/tmp/portage/media-libs/mesa-11.1.2-r1/work/mesa-11.1.2/src/gbm/main/gbm.c:121:11: error: implicit declaration of function ‘minor’ [-Werror=implicit-function-declaration]
           minor(dev) == minor(buf.st_rdev)) {
           ^
cc1: some warnings being treated as errors
Makefile:857: recipe for target 'main/gbm.lo' failed

After some searching i found that must have something to do with "/usr/include/sys/sysmacros.h" which belongs to sys-libs/glibc. So i downgraded the recently merged v2.23 to 2.22 and these problems were gone

Other packages might be affected.

[zwede]

Thank you SO MUCH for this post!!!!

I had glibc in my package.keywords for some historic reason and got 2.23. Then I started getting these faults halfway through a plasma update and was stuck with no desktop. Couldn't go back to plasma-5.5.4 either as packages that had built previously now didn't build.

Downgrading glibc let me finish the plasma upgrade and my desktop is back.

[miyuki]

I found the patch "00_all_0009-sys-types.h-drop-sys-sysmacros.h-include.patch" in sys-libs/glibc causes this issue.
This patch drops "#include <sys/sysmacros.h>" from /usr/include/sys/types.h

But of course, this patch was added for some reasons
https://sourceware.org/ml/libc-alpha/20 ... 00253.html

This issue should be solved. I recommends not to install glibc-2.23 before it is keyworded(supported).

[ThGravo]

See Gentoo's Bugzilla: [bug=579990]media-libs/mesa-11.2.0 fails to build against sys-libs/glibc-2.23-r1[/bug]

[Ant P.]

xorg-server 1.18.3 too.

[steveL]

I found the patch "00_all_0009-sys-types.h-drop-sys-sysmacros.h-include.patch" in sys-libs/glibc causes this issue.
This patch drops "#include <sys/sysmacros.h>" from /usr/include/sys/types.h

But of course, this patch was added for some reasons
https://sourceware.org/ml/libc-alpha/20 ... 00253.html

This issue should be solved. I recommends not to install glibc-2.23 before it is keyworded(supported).

Hmm the guy who originally proposed dropping the include, and doing distro builds to test breakage, ended up concluding it was not a good idea.

Curious that it should have been applied.

wrt other software, if this isn't reverted upstream, it will have to be patched to #include <sys/sysmacros.h>, a non-standard header.
If upstream want to continue with the patch, IMO it should be locally reverted by Gentoo for that process to complete. (or ~arch users are going to end up in troubles, and likely hard-mask it.)

edit: not <sys/types.h>

[Xywa]

xorg-server 1.18.3 too.

That day I could not compile ANY of xorg-server back 1.16.xxx. Downgrading glibc solved my problems.

[steveL]

My mistake; from reading the bug, it appears an inclusion of <sys/sysmacros.h> would be required

Glibc should just stay as-is, imo; ie: Gentoo should revert the patch.

Not going to happen, but there we go.

[Ant P.]

Hmm the guy who originally proposed dropping the include, and doing distro builds to test breakage, ended up concluding it was not a good idea.

Curious that it should have been applied.

We're considered lab rats by this idiot, so no surprise it came without a news item or anything.

[Buffoon]

I have mongodb build failure.Glad I found this thread.

[Perfect Gentleman]

unpatch the ducking patch

Code: Select all

From 1053a4902ebff0ba30098fdcad614d963de87c3d Mon Sep 17 00:00:00 2001
From: Mike Frysinger <vapier@gentoo.org>
Date: Tue, 29 Dec 2015 17:54:31 -0500
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
---
 posix/sys/types.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/posix/sys/types.h b/posix/sys/types.h
index a728567..b3007db 100644
--- a/posix/sys/types.h
+++ b/posix/sys/types.h
@@ -217,6 +217,9 @@ typedef int register_t __attribute__ ((__mode__ (__word__)));
 
 /* It also defines `fd_set' and the FD_* macros for `select'.  */
 # include <sys/select.h>
+
+/* BSD defines these symbols, so we follow.  */
+# include <sys/sysmacros.h>
 #endif /* Use misc.  */
 
 
-- 
2.6.2

[geki]

phew, was about to post in tracker bug,especially because someone posted not to post there.
we have some brave hearts in the gentoo developers community.

xf86-video-intel and wine failed so far. fun.

[hydrapolic]

Just for reference, here you can find some information:
https://bugs.gentoo.org/show_bug.cgi?id=575232

https://gitweb.gentoo.org/repo/gentoo.g ... f9fc9238eb

Code: Select all

The minor/major/makedev macros are not entirely standard.  glibc has had
the definitions in sys/sysmacros.h since the start, and wants to move away
from always defining them implicitly via sys/types.h (as this pollutes the
namespace in violation of POSIX).  Other C libraries have already dropped
them.  Since the configure script already checks for this header, use that
to pull in the header in files that use these macros.

[Ottre]

we have some brave hearts in the gentoo developers community.

vapier does things for a good reason.

Like the dumb-echo patch for app-shells/dash, to make it a truly POSIX-compliant shell, that caused a lot of build failures.

Pretty much all of them got fixed upstream; they were happy for the increased portability of their shell scripts.

[steveL]

vapier does things for a good reason.

He may have reasons, but his methods suck, big-time.

In this instance he should have hard-masked the version with his unilateral patch, for testing. (This is hardly unfamiliar to him.)

Then he could very easily have smoke-tested the change on a distro-wide level, by the use of a tinderbox (hardly rocket-science, given that users have been doing that for about a decade, to my knowledge), and patched the relevant software (thus making it work on both types of setup on a Linux install.)
If he felt unable to submit a patch, he could just have submitted bugs, pointing out that major/makedev aren't standardised.

Only he prefers to do this via a very convoluted process that wastes everyone's time, most especially that of users.

Because he's worth it^W^W^W he can.
Or perhaps because he's chasing brownie-points with the wrong people (anyone other than Gentoo users.)

AFAIC, it's totally lame. When glibc developers look after you better than "core" distro developers, something's really borked.

[steveL]

Code: Select all

The minor/major/makedev macros are not entirely standard.  glibc has had
the definitions in sys/sysmacros.h since the start, and wants to move away
from always defining them implicitly via sys/types.h (as this pollutes the
namespace in violation of POSIX).  Other C libraries have already dropped
them.  Since the configure script already checks for this header, use that
to pull in the header in files that use these macros.

Oh puhleez, "violation of POSIX" what rot. Namespace violations only occur if you don't test __USE_BSD (or w/e they're calling it this year) which is set under _GNU_SOURCE or _BSD_SOURCE.

"glibc following the fashion of other libc's" has got to be the funniest part, though.

[SlashBeast]

Hmm the guy who originally proposed dropping the include, and doing distro builds to test breakage, ended up concluding it was not a good idea.

Curious that it should have been applied.

We're considered lab rats by this idiot, so no surprise it came without a news item or anything.

Classic Vapier.

[Perfect Gentleman]

sys-libs/glibc-2.23-r2: Skipping 00_all_0009-sys-types.h-drop-sys-sysmacros.h-include.patch due to EPATCH_EXCLUDE

[SlashBeast]

https://gitweb.gentoo.org/repo/gentoo.g ... 4cd1d19381

[Ant P.]

And to balance out my complaining a bit: there's a dev that's earned my respect.

[GuntherDW]

With regards to breakage of the patch, for completionist sake, sys-fs/lvm2-2.02.145-r2 also breaks with the patch applied.
It was a pain trying to find out what exactly caused it to break because I couldn't find something on google.

Only when a mesa recompile broke could I find this thread...

But in all honesty, just using us a mere "testbed" is kind of the wrong attitude I'd expect from a Gentoo developer.
Even if we're running ~arch just blindly applying a patch and letting us report the bugs for you instead of doing research on your own is kind of abhorrent.
I'd expect stuff like this from an experimental overlay, not the main portage tree.

[Ottre]

He may have reasons, but his methods suck, big-time.

Yeah, this mess could have been avoided with a news item.

"...Either stay on glibc 2.22 or set the EPATCH_EXCLUDE variable in your glibc bashrc file like so..."

I don't like masking except under extreme circumstances, like an x86 binary package masked on arm, it's a form of procrastination.

[Ottre]

I'd expect stuff like this from an experimental overlay, not the main portage tree.

I think it's a major selling point of Gentoo that we have developers who care about POSIX.

[GuntherDW]

It's true that caring about POSIX can be a good thing, but his methodology behind just dropping the patch was wrong.
Besides, there's loads of things in the Linux sphere that aren't really POSIX minded.

Most notably things like systemd, but I'd rather not open that can of worms here .

[Ant P.]

I'd expect stuff like this from an experimental overlay, not the main portage tree.

I think it's a major selling point of Gentoo that we have developers who care about POSIX.

There's "caring about POSIX" and then there's "standards wankery". This change firmly belongs in the same group as the pointless memcpy change which broke Flash for everyone.