Bugzilla Bug 179775

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.