I saw that this package had been in portage since 2006-12-02 and no updates. The only bugs reported is people doing funny things with USE-flags, so maybe time to stabilize?
Is this error fixed: sis_dri.c: 753: error: conflicting types for 'SISDRICloseScreen' sis_dri.c: 427: error: previous implicit declaration of 'SISDRICloseScreen' was here This error I got when building this module on x86 platform with the latest stable packet xf86-video-sis.... Thank you.
(In reply to comment #1) > Is this error fixed: > sis_dri.c: 753: error: conflicting types for 'SISDRICloseScreen' > sis_dri.c: 427: error: previous implicit declaration of 'SISDRICloseScreen' was > here > This error I got when building this module on x86 platform with the latest > stable packet xf86-video-sis.... > Thank you. This is the reference to the issue: http://bugs.gentoo.org/show_bug.cgi?id=167256
(In reply to comment #2) > (In reply to comment #1) > > Is this error fixed: > > sis_dri.c: 753: error: conflicting types for 'SISDRICloseScreen' > > sis_dri.c: 427: error: previous implicit declaration of 'SISDRICloseScreen' was > > here > > This error I got when building this module on x86 platform with the latest > > stable packet xf86-video-sis.... > > Thank you. > > This is the reference to the issue: > > http://bugs.gentoo.org/show_bug.cgi?id=167256 > It probably hasn't been fixed, since it doesn't appear anyone has bothered to file the issue upstream.
Ok, I have VIDEO_CARDS set so that is probably why I have not encountered that bug. I can assure sis-0.9.1-r1 and 0.9.3 works like a charm. And I can't see what fglrx (ati-drivers?) has to do with it. I did an 'emerge ati-drivers xf86-video-sis' both with eselect opengl set nvidia (my card on my little faster playbox) and eselect opengl set ati (for trying it out) and both works fine. I am going to unset VIDEO_CARDS to see if I can recreate the fail before filing upstream. Feel free to file before me if you like.:-)
(In reply to comment #4) > Ok, I have VIDEO_CARDS set so that is probably why I have not encountered that > bug. I can assure sis-0.9.1-r1 and 0.9.3 works like a charm. I have a VIDEO_CARDS set to 'sis'. And I used previous version of the driver. However, during the upgrade of the X from 7.0 to 7.1 (or 7.2) it tried to install 0.9.1-r1 but fail with the error above. > And I can't see what fglrx (ati-drivers?) has to do with it. I did an 'emerge > ati-drivers xf86-video-sis' both with eselect opengl set nvidia (my card on my > little faster playbox) and eselect opengl set ati (for trying it out) and both > works fine. I just tried 'emerge xf86-video-sis'... > I am going to unset VIDEO_CARDS to see if I can recreate the fail before filing > upstream. Feel free to file before me if you like.:-)
Strange, i can replicate at all. hit me with your emerge --info and I will tell you mine as soon as I can fetch it.
# emerge --info Portage 2.1.2-r9 (default-linux/x86/2006.1/desktop, gcc-3.4.6, glibc-2.4-r3, 2.6.17-gentoo-r8 i686) ================================================================= System uname: 2.6.17-gentoo-r8 i686 Intel(R) Pentium(R) M processor 1.86GHz Gentoo Base System release 1.12.9 Timestamp of tree: Thu, 15 Feb 2007 21:20:01 +0000 dev-lang/python: 2.3.6, 2.4.4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.20 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O2 -march=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.tu-clausthal.de/pub/linux/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="X acpi alsa arts berkdb bitmap-fonts cairo cdr cli cracklib crypt cups dbus dlloader dri dvd dvdr eds emboss encode esd fam firefox fortran gdbm gif gpm gstreamer hal iconv ipv6 isdnlog jpeg kde ldap libg++ mad midi mikmod mp3 mpeg ncurses nls nptl nptlonly ogg opengl oss pam pcre perl png ppds pppd python qt qt3 qt4 quicktime readline reflection sdl session spell spl ssl tcltk tcpd tk truetype truetype-fonts type1-fonts unicode vorbis win32codecs x86 xml xorg xv zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="apm ark ati chips cirrus cyrix dummy fbdev glint i128 i740 i810 imstt mga neomagic nsc nv rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa vga via vmware voodoo" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
two mayor things that differs between your system and mine: glibc-2.5 and gcc-4.1.2 I could try to set up a chroot and try that. or you could upgrade your gcc to latest stable and try that (do not forget gcc-config).
Error confirmed in chroot: emerge with gcc-3 and it fails, emerge with gcc-4 and it works.
So what is left for this package to become stable? Currently it seems like the only ones having problem compiling this is the ones using a old gcc or have USE-flag problems. What is the blocker?
Well, this is stable on amd64/x86 now for bug #191615 but if it needs to go on other arches, they'll need to be added to CC.
Since sis hardware pretty much only shows up on x86 stuff, closing as fixed.
