Summary: | ati-drivers 8.18.6 cannot be compiled under 2.6.14 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alex Giouzenis <agios> |
Component: | New packages | Assignee: | X11 External Driver Maintainers <x11-drivers> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | amd64, christopher.eineke, fly-a-lot, mtippett, romanomarco |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Patch that fixes original driver distribution |
Description
Alex Giouzenis
2005-10-16 11:16:26 UTC
Created attachment 70803 [details, diff]
Patch that fixes original driver distribution
I'll add a sed line to fix the problem soon sed line added, please test It seems to work great here, thanks! Nice, it works correctly also with the .13 undefines symbols register_ioctl32_conversion and unregister_ioctl32_conversion using 2.6.14 final ... will provide emerge info later luca you know how to find me. seems to be related to x86_64 only as that is only ifdefine I can find that even call for the ioctl32. I can confirm the same issues on amd64 with register_ioctl32_conversion and unregister_ioctl32_conversion. These errors are thrown when inserting fglrx into the kernel, and insertion then fails. Those are the only two errors I saw in dmesg though. This was using ati-drivers-8.18.8 and gentoo-sources-2.6.14. Portage 2.0.53_rc6 (default-linux/amd64/2005.1, gcc-4.0.2, glibc-2.3.5.20050722-r0, 2.6.14-gentoo x86_64) ================================================================= System uname: 2.6.14-gentoo x86_64 AMD Turion(tm) 64 Mobile Technology ML-37 Gentoo Base System version 1.12.0_pre9 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [disabled] dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.13 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-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-march=k8 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig buildpkg digest distlocks sandbox sfperms" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LINGUAS="en_GB" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/sci" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X aac aalib aim alsa ati audiofile avi bash-completion berkdb bitmap-fonts bootsplash bzlib cdparanoia cdr crypt cscope cups curl dbus directfb doc dri dvd dvdr dvdread eds emboss encode esd ethereal fam fbcon fftw foomaticdb fortran gd gdbm gif gimpprint gmp gphoto2 gpm gstreamer hal icq ieee1394 imagemagick imap imlib ipv6 jabber java jikes jpeg jpeg2k kde kdeenablefinal kerberos lcms libwww lm_sensors lzw lzw-tiff mad madwifi motif mp3 mpeg ncurses netcdf nls nptl nptlonly odbc offensive ogg oggvorbis openexr opengl pam pcre pdflib perl plotutils png povray python qt quicktime readline rtc samba sasl scanner sdl speedo spell sqlite ssl subversion svg tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts udev unicode usb userlocales videos vorbis wmf xine xinerama xml2 xpm xv xvid zeroconf zlib linguas_en_GB userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS had ment to change OS to amd64 early as x86 is not effected by this current issue! Can include this patch into the ebuild? the access_ok issue is more or less solved (I should check in the ati solution since looks a bit more cleaner) the register/unregister_ioctl32 on the other hand... I may try to noop those calls. They could be removed since now the ioctl compatibility layer is explicitly exported using compat_ioctl. The problem is that I'm not sure what I should pass to it. *** Bug 111200 has been marked as a duplicate of this bug. *** *** Bug 111246 has been marked as a duplicate of this bug. *** *** Bug 113565 has been marked as a duplicate of this bug. *** |