Both versions of the SiS X11 driver in Portage fail to compile with the -dri USE flag. However, both versions compile with the dri USE flag enabled. Please note that I have also tried compiling this driver on a pure x86 system (with the exception of X.Org 7.0, of course) using a stable version of GCC with the same result. I am using a chipset that does not support DRI, so I am using software rendering. Portage 2.1_pre9-r3 (default-linux/x86/2006.0, gcc-4.1.0, glibc-2.4-r1, 2.6.17-rc2 i686) ================================================================= System uname: 2.6.17-rc2 i686 AMD Athlon(tm) Processor Gentoo Base System version 1.12.0_pre18 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [enabled] dev-lang/python: 2.3.5-r2, 2.4.2-r3 sys-apps/sandbox: 1.2.17 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-r2 sys-devel/binutils: 2.16.1-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -Os -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -Os -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.chem.wisc.edu/gentoo/" LANG="en_US" LC_ALL="en_US" LDFLAGS="-Wl,-O1" LINGUAS="en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowext X a52 aalib acpi aim alsa apache2 ares asf audacious avi bash-completion bitmap-fonts bzip2 cairo cddb cli crypt cups custom-cflags djbfft dri dvd emboss encode fbcon ffmpeg firefox flac fontconfig foomaticdb fortran gif glitz glut gnutls gpm gtk gtk2 icq imlib isdnlog ithreads jabber jpeg libcaca libg++ libvisual libwww lirc mad mikmod mmap mmx mmxext mng mp3 mpeg msn ncurses nls nodrm nptl nptlonly ogg opengl pam pango pcre pdflib perl picnls png pppd python readline reflection sdl session spell spl sse ssl startup-notification tcpd truetype truetype-fonts type1-fonts udev unicode usb v4l v4l2 vcd vda vorbis win32codecs xchat xml xorg xv xvid yahoo zlib elibc_glibc input_devices_keyboard input_devices_mouse input_devices_evdev kernel_linux linguas_en userland_GNU video_cards_vesa video_cards_v4l" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK
Created attachment 85237 [details] Emerge log
According to this post: http://bugs.gentoo.org/show_bug.cgi?id=127387#c6 DRI isn't optional, it's required? Or am I reading this wrong?
(In reply to comment #2) > According to this post: > > http://bugs.gentoo.org/show_bug.cgi?id=127387#c6 > > DRI isn't optional, it's required? Or am I reading this wrong? Yes. The dri part of that post is parenthetical. exa is non-optional. Your problem is simply this: /usr/include/xorg/xf86drm.h:39:17: error: drm.h: No such file or directory Interestingly, in configure I see this: checking whether to include DRI support... no Yet apparently it's trying to build dri support anyway.
Yeah, I noticed that. I wasn't sure if that was the only problem. I tried compiling the driver outside of Portage, but I got the same result.
(In reply to comment #3) > Your problem is simply this: > /usr/include/xorg/xf86drm.h:39:17: error: drm.h: No such file or directory > > Interestingly, in configure I see this: > checking whether to include DRI support... no > > Yet apparently it's trying to build dri support anyway. > This could be a result of xorg-server being +dri. If xorg-server was build -dri, then this should probably be moved upstream.
(In reply to comment #5) > This could be a result of xorg-server being +dri. If xorg-server was build > -dri, then this should probably be moved upstream. That was indeed the problem. Thank you.
That still sounds like a bug, if the autodetection is overriding an explicitly passed --disable-dri.
(In reply to comment #7) > That still sounds like a bug, if the autodetection is overriding an explicitly > passed --disable-dri. > I believe it's actually just a bug in one of the headers. Nothing is explicitly being included by the driver, but somewhere in xorg-server's headers (or related) having DRI enabled drags in DRI stuff anyway.
Maybe we can get the real bug figured out here, if there is one, so we can push it upstream.
This bug isn't sis specific it's a widespread issue with the other drivers too. The --disable-dri option removes an include path where normally it would have picked up the drm.h header file, and that's why the build barfs. XF86DRI is defined in xorg-server.h and config.h includes that, then doesn't #undef it as it gets commented out later in that file. We could either fix it so it does undef XF86DRI, but to be honest, I'm more inclined to remove the --disable-dri option from the configure script these days.
(In reply to comment #10) > We could either fix it so it does undef XF86DRI, but to be honest, I'm more > inclined to remove the --disable-dri option from the configure script these > days. Won't that kill any archs without DRI?
No. I'm proposing removing the --disable-dri option as it's currently broken as it stands, as xorg-server.h continues to define XF86DRI regardless of the drivers choice. If an arch doesn't support DRI, then XF86DRI should not be set in xorg-server.h. Still, if --disable-dri is desired, then all we need to do is make configure.ac set #undef XF86DRI in config.h for the driver.
Problem with that from a Gentoo perspective is that it makes things too autodetected -- the build state is no longer determined purely by USE flags. Rebuilding xorg-server with a change in USE=dri should somehow indicate that drivers need to be rebuilt with a change in USE as well, but build-time autodetection doesn't allow that.
Problem with that from a Gentoo perspective is that it makes things too autodetected -- the build state is no longer determined purely by USE flags. Rebuilding xorg-server with a change in USE=dri should somehow indicate that drivers need to be rebuilt with a change in USE as well, but build-time autodetection doesn't allow that.(In reply to comment #13) > Problem with that from a Gentoo perspective is that it makes things too > autodetected -- the build state is no longer determined purely by USE flags. > Rebuilding xorg-server with a change in USE=dri should somehow indicate that > drivers need to be rebuilt with a change in USE as well, but build-time > autodetection doesn't allow that. But it would be reasonable to add checks that prevent -dri driver builds against a +dri server.
Can't you leave the USE="dri" flag available to drivers, but not actually do anything with it ??? That could still signify a driver needs to be rebuilt with --newuse if the xserver changed. If not, then let's make configure.ac #undef XF86DRI.
We've got this in e.g. the xf86-video-ati ebuild already: pkg_setup() { if use dri && ! built_with_use x11-base/xorg-server dri; then die "Build x11-base/xorg-server with USE=dri." fi } We could just add the opposing case of -dri/-dri. Seems like that would be easier than the other approaches, because I don't see the mixture as a realistic use case for upstream.
yep, sounds good.
Woops, sorry for the extra comment -- firefox extensions gone wild
Hi. It also doesn't compile with dri USE enabled on amd64. Gives errors on src/sis_dri.c, conflicting types for DRICloseScreen Should i open a new bug report for this one?
Eapi2ed for correct deps. Thus this bug is fixed.
