| View previous topic :: View next topic |
| Author |
Message |
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
 Posted: Sun Apr 17, 2016 11:04 pm Post subject: |
 |
|
| Ottre wrote: | | I think it's a major selling point of Gentoo that we have developers who care about POSIX. |
Hmm, if they "cared about POSIX", it seems to me they'd have listened when I asked them to put ed in @system, for the sake of POSIX.2 compliance OoTB, along with someone else's request for bc (used by kernel-compile.)
Instead we got the usual questioning-around-the-no-brainer followed by "let's not change anything, because thinner stage for embedded" at the time "let's do glib-based stages" was first being mooted. Whereas we can all have huge dependencies imposed on us, because we can use the underlying tools to hack a way out, people doing embedded builds with Gentoo are apparently less capable and cannot even manage emerge -Cq, nor to tar up a stage4, something users have been doing for at least a decade, which is pretty much essential if you're doing reproducible cross-installs. (here's tonne loads of python and perl installed: just not the basics.)
Never mind the existing stages put out for embedded architectures, by their respective arch-teams (who are perfectly capable of deciding what goes in them.)
Forgive me for not being so enthused about Gentoo's commitment to POSIX.[1]
If you think the above doesn't matter (because we have to emerge whatever anyway), that's cool.
I understand the point of view.
To my mind, it means we lose the selling-point of standard scripting capability OoTB.
I certainly found it irritating when working on an installer, that I could not just use ed pre-install (and all my lib functions that use it), without first having the rest setup enough to emerge (ie: from within the chroot, which is quite late in installer-process terms.)
Yes I know about sed -i. For a #bash regular, that's just gack.[2]
Illustrating that it's not as attractive as it could so easily be.
As does the inability to compile a kernel, again without first chrooting and emerging the necessary tool. It's a straightforward loss of flexibility.
Looking at the revert patch above, a better patch to add to glibc would be to namespace the inclusion, as discussed before (which I'd thought they already did, before the removal.)
A BSD coder should not be expecting to use one of the functional macro names, without being aware that they already exist; whilst it could be restricted to _GNU_SOURCE, given that there's no <sys/makedev.h> that would just make porting harder for no reason.[3]
Though again, you'd smoke-test in a tinderbox, not on end-users' machines, and keep any needed patches to other packages locally, at distro level, until upstreams have taken them, and you have the tarballs to prove it.
--
[1] In this case it feels like reaching for pretext, because there doesn't appear to be an understanding of (how glibc avoids) namespace violations.
[2] If that doesn't make any sense, I highly recommend you spend at least 6 months lurking in #bash
Remember that every ebuild and eclass uses bash as the implementation language.
And yeah, I was forced to sed -i some things. (shudder;) That it can be worked around, less robustly, is not a justification; it rather proves the point.
[3] No, not everyone wants to use autoconf; that macro is no excuse for not thinking through the glibc codebase implications, nor for not stepping carefully wrt. other people's systems. |
|
| Back to top |
|
 |
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Apr 17, 2016 11:06 pm Post subject: |
|
|
| Ant P. wrote: | | And to balance out my complaining a bit: there's a dev that's earned my respect. |
++
Patrick is like the BOFH of Gentoo.. *clickety-click* "You were saying?" |
|
| Back to top |
|
|
Xywa
Veteran
Joined: 23 Jul 2005
Posts: 1631
Location: /mnt/Gentoo/Europe
|
| Posted: Mon Apr 25, 2016 11:47 am Post subject: |
|
|
| Is it this fixed? Can I unmask my glibic now? |
|
| Back to top |
|
|
archenroot
Apprentice
Joined: 13 Dec 2011
Posts: 218
Location: Lake Macha, Czech republic
|
| Posted: Fri Oct 20, 2017 1:05 pm Post subject: |
|
|
Hi guys, while searching for current issue I hit this thread here as it looks like discussion about same error here, but 1 year later.
| Code: | nc.a ../../mi/.libs/libmi.a ../../os/.libs/libos.a -lcrypto -ldl ../../Xext/.libs/libXvidmode.a -lpciaccess -ldrm -lpixman-1 -lXfont2 -lXau -lxshmfence -lXdmcp -lm -lbsd -pthread
common/.libs/libcommon.a(udev.o): In function `device_removed':
udev.c:(.text+0x10c): undefined reference to `minor'
udev.c:(.text+0x119): undefined reference to `major'
common/.libs/libcommon.a(udev.o): In function `device_added':
udev.c:(.text+0x2f4): undefined reference to `minor'
udev.c:(.text+0x300): undefined reference to `major'
udev.c:(.text+0x334): undefined reference to `minor'
udev.c:(.text+0x340): undefined reference to `major'
udev.c:(.text+0x528): undefined reference to `major'
udev.c:(.text+0x57d): undefined reference to `minor'
common/.libs/libcommon.a(udev.o): In function `config_udev_odev_probe':
udev.c:(.text+0x11af): undefined reference to `minor'
udev.c:(.text+0x11c1): undefined reference to `major'
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:805: Xorg] Error 1
make[4]: Leaving directory '/tmp/portage/x11-base/xorg-server-1.19.4/work/xorg-server-1.19.4_build/hw/xfree86'
make[3]: *** [Makefile:854: all-recursive] Error 1
make[3]: Leaving directory '/tmp/portage/x11-base/xorg-server-1.19.4/work/xorg-server-1.19.4_build/hw/xfree86'
make[2]: *** [Makefile:669: all] Error 2
make[2]: Leaving directory '/tmp/portage/x11-base/xorg-server-1.19.4/work/xorg-server-1.19.4_build/hw/xfree86'
make[1]: *** [Makefile:611: all-recursive] Error 1
make[1]: Leaving directory '/tmp/portage/x11-base/xorg-server-1.19.4/work/xorg-server-1.19.4_build/hw'
make: *** [Makefile:778: all-recursive] Error 1
* ERROR: x11-base/xorg-server-1.19.4::gentoo failed (compile phase):
* emake failed
*
* If you need support, post the output of `emerge --info '=x11-base/xorg-server-1.19.4::gentoo'`,
* the complete build log and the output of `emerge -pqv '=x11-base/xorg-server-1.19.4::gentoo'`.
* The complete build log is located at '/tmp/portage/x11-base/xorg-server-1.19.4/temp/build.log'.
* The ebuild environment file is located at '/tmp/portage/x11-base/xorg-server-1.19.4/temp/environment'.
* Working directory: '/tmp/portage/x11-base/xorg-server-1.19.4/work/xorg-server-1.19.4_build'
* S: '/tmp/portage/x11-base/xorg-server-1.19.4/work/xorg-server-1.19.4'
>>> Failed to emerge x11-base/xorg-server-1.19.4, Log file:
|
I am on following glibc version:
| Code: | (chroot) livecd ~ # ls /usr/portage/sys-libs/glibc/files/
2.10 2.17 2.18 2.19 2.20 2.25 2.6 nscd nscd.service nscd.tmpfilesd nsswitch.conf
(chroot) livecd ~ # eix -I glibc
[?] sys-libs/glibc
Available versions: (2.2) [M]2.17^s [M]2.17^s[1] [M](~)2.18-r1^s [M](~)2.18-r1^s[1] [M](~)2.19^s[1] [M]2.19-r1^s [M]2.19-r1^s[1] [M](~)2.20^s[1] [M]2.20-r2^s [M]2.21-r2^s [M]2.22-r4^s [M]2.23-r3^s 2.23-r4^s (~)2.24-r3^s (~)2.24-r4^s (~)2.25-r2^s (~)2.25-r3^s (~)2.25-r4^s **2.26^s **9999^s
{audit caps debug gd hardened multilib nscd profile +rpc selinux suid systemtap vanilla CROSSCOMPILE_OPTS="headers-only"}
Installed versions: 2.25-r7(2.2)^s(03:31:24 PM 10/11/2017)(multilib rpc -audit -caps -debug -gd -hardened -nscd -profile -selinux -suid -systemtap -vanilla CROSSCOMPILE_OPTS="-headers-only")
Homepage: https://www.gnu.org/software/libc/libc.html
Description: GNU libc6 (also called glibc2) C library
[1] "poly-c" /var/lib/layman/poly-c |
The patch you are talking about cannot be found on my system, so not sure how to resolve this issue in the moment, I searched for macros related stuff but no luck:
| Code: | (chroot) livecd ~ # locate sysmacros.h
/opt/MATLAB/R2017a/polyspace/verifier/cxx/include/include-libc/sys/sysmacros.h
/opt/MATLAB/R2017a/sys/tcc/linux32/include/sys/sysmacros.h
/usr/include/bits/sysmacros.h
/usr/include/sys/sysmacros.h
/usr/portage/net-misc/spice-gtk/files/spice-gtk-0.33-sys-sysmacros.h.patch
/usr/portage/www-client/seamonkey/files/firefox-Include-sys-sysmacros.h-for-major-minor-when-availab.patch
(chroot) livecd ~ # cat /usr/include/sys/types.h |grep macros
/* It also defines `fd_set' and the FD_* macros for `select'. */
(chroot) livecd ~ # cd /usr/portage/sys-libs/glibc/
(chroot) livecd /usr/portage/sys-libs/glibc # grep -R macros |
could it be that it has been removed even from glibc itself?
_________________
Emperor wants to control outer space Yoda wants to explore inner space that's the fundamental difference between good and bad sides of the Force
Last edited by archenroot on Fri Oct 20, 2017 1:12 pm; edited 1 time in total |
|
| Back to top |
|
|
archenroot
Apprentice
Joined: 13 Dec 2011
Posts: 218
Location: Lake Macha, Czech republic
|
| Posted: Fri Oct 20, 2017 1:06 pm Post subject: |
|
|
Ok, so staying on x11-base/xorg-server-1.19.3 version is fine, so for now, don't upgrade.
_________________
Emperor wants to control outer space Yoda wants to explore inner space that's the fundamental difference between good and bad sides of the Force |
|
| Back to top |
|
|
Josef.95
Advocate
Joined: 03 Sep 2007
Posts: 4555
Location: Germany
|
| Posted: Fri Oct 20, 2017 5:44 pm Post subject: |
|
|
@archenroot
that is probably a eudev issue.
See Bug 634590 |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
