if __GLIBC__ is defined x11-base/xorg-server thinking that it is building on glibc includes execinfo.h, the problem is that uClibc defines __GLIBC__ but does not provide execinfo functionality. Yuri. Reproducible: Always Steps to Reproduce: # emerge info Portage 2.0.51.22-r2 (uclibc/x86/2005.1/2.4, gcc-3.4.4, uclibc-0.9.28-r0, 2.6.10-gentoo-r4 i686) ================================================================= System uname: 2.6.10-gentoo-r4 i686 Transmeta Efficeon(tm) Processor TM8000 Gentoo Base System version 1.12.0_pre8 dev-lang/python: 2.3.4-r1, 2.4.1-r1 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.4.22-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-gentoo-linux-uclibc" CFLAGS="-Os -pipe" CHOST="i686-gentoo-linux-uclibc" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-Os -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks noinfo sandbox sfperms strict" GENTOO_MIRRORS="http://mirrors.tds.net/gentoo http://gentoo.osuosl.org/" LDFLAGS="-Wl,-O1" MAKEOPTS="-j2" PKGDIR="/usr/local/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X bash-completion dri minimal ncurses opengl perl python readline ssl truetype type1 uclibc unicode zlib userland_GNU kernel_linux elibc_uclibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LINGUAS
Created attachment 67689 [details, diff] xorg-server/xorg-server-0.99.1-r7-execinfo.patch
Would appreciate some advice on this.
looks safe, but I wonder why uclibc is defining glibc
uclibc defines glibc because a lot of stuff checks for __GLIBC__ instead of using real configure checks ... for the most part, uclibc is source compat with glibc in this case, xf86Events.c should be cleaned up to check for the backtrace function and the execinfo.h header file file configure.ac and then the source should use the resulting defines to figure out what code paths to take
So you're saying Yuri's patch is just a workaround for something upstream should fix more completely?
(In reply to comment #5) > So you're saying Yuri's patch is just a workaround for something upstream should > fix more completely? That statement is completely true.
Thank you for clarifying. Yuri, could you post this bug upstream and drop the URL here please? Reference this bug upstream so they can see what has been discussed. I've mentioned this in other bugs: they're very busy upstream so don't expect a quick response. Anyone who'd be willing to provide a patch that does most/all of the required work would be much appreciated.
Filled bug upstream: https://bugs.freedesktop.org/show_bug.cgi?id=4393
Much thanks. Donnie, I've added you to CC upstream.
The bug is still present in gentoo. Why close this when there is a patch provided here and Xorg used to work? We know it's going to be a long time before upstream anything makes it's way back into gentoo. Please add the patch.
- It's an upstream bug, and we will benefit from the review of upstream. - No, it won't be a long time before anything upstream makes it back. We've been regularly adding CVS snapshots. So when a fix for this problem gets committed, we can get it back in Gentoo quickly. - Each patch we add creates more work for us. It's easier to use upstream code. It also ensures that we're using the same X as other distributions and OS's and reduces potential distribution-specific bugs.
This should be fixed in modular versions. If it's important to anyone to get this into our 6.8.2 ebuilds please let me know soon.
Marking fixed.
