I know svgalib didn't work on amd64, but I've expected it will work in 32bit chroot enviroment under amd64 kernel. But there is no ebuild to compile svgalib_helper for this case. Also, when I do it by hand, I find svgalib programs froze or reboots computer, while before-module svgalib programs work fine. Reproducible: Always Steps to Reproduce: 1. emerge -s svgalib_helper Actual Results: No ebuild will be found Expected Results: WORKING svgalib_helper module should be installed. BTW, I also think stand-alone svgalib_helper will be more comfortable for switching kernels that reemerging whole svgalib. Gentoo Base System version 1.4.16 Portage 2.0.51-r14 (default-linux/amd64/2004.3, gcc-3.4.3, glibc-2.3.4.20040808-r1, 2.6.10-gentoo-r6 x86_64) ================================================================= System uname: 2.6.10-gentoo-r6 x86_64 AMD Athlon(tm) 64 Processor 3000+ Python: dev-lang/python-2.3.4 [2.3.4 (#1, Mar 2 2005, 02:39:41)] dev-lang/python: 2.3.4 sys-devel/autoconf: 2.59-r5 sys-devel/automake: 1.8.5-r1 sys-devel/binutils: 2.15.90.0.1.1-r3 sys-devel/libtool: 1.5.2-r7 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CFLAGS="-O2 -pipe -mtune=athlon64" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /usr/share /texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/c onfig/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -pipe -mtune=athlon64" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache digest distlocks sandbox" GENTOO_MIRRORS="ftp://ftp.tu-clausthal.de/pub/linux/gentoo http://ftp.sh.cvut.cz/MIRRORS/gentoo/gentoo/ http://www.mirro r.ac.uk/sites/www.ibiblio.org/gentoo/ http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gento o" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="amd64 X Xaw3d aalib acpi alsa apache2 apm audiofile avi berkdb bitmap-fonts bzlib caps cdr crypt curl dbase dbm dbx dga directfb divx4linux doc dvd dvdr emul-linux-x86 encode esd ethereal exif f77 fbcon flac flash font-server fortran g d gdbm ggi gif gpm gtk iconv imagemagick imlib innodb ipv6 java jp2 jpeg lcms lesstif libcaca libwww lirc lzw lzw-tiff m ad mailwrapper mbox mcal memlimit mhash mikmod mime ming mmap mng motif mozilla mpeg multilib mysql ncurses nls offensiv e oggvorbis openal opengl oss pam pcntl pcre pdflib perl php plotutils png posix python qt quicktime readline samba sdl shared sharedmem slang sndfile snmp sockets spell sqlite ssl sysvipc tcpd tetex theora tiff truetype truetype-fonts type 1-fonts unicode usb userlocales v4l v4l2 vhosts videos wmf xml xml2 xosd xpm xrandr xv xvid zlib" Unset: ASFLAGS, CBUILD, CTARGET, LDFLAGS
svgalib is a kernel module which means it has to support 64bit and a 32bit userspace doesnt matter
First: 32bit userspace doesn't matter AS LONG AS INTERFACE DOESN'T CONTAIN INTS. Several other modules needs special interfaces called ioctl32, which are really simple stubs around real ioctls for converting structures containing 32bit ints (and 32 bit pointers, if any) to structures containing 64bit ints (and pointers). Don't know if svgalib is this case. Second: I didn't suppose svgalib can be compiled 64bit. I see debian somehow managed that so maybee I can rather ask for that, but fact is 32bit version will not only suffice for me, but will be prefered. But of course, kernel module must be build 64bit. I tried it by hand and it won't work. Third: I didn't see why what you saying invalidate any part of my bugreport, much less both (no ebuild for svgalib_helper only, svgalib_helper don't work on amd64 with 32bit svgalib). Also, I suppose reports like "svgalib_helper don't work on amd64 with 64bit svgalib" (I don't report that, because I didn't test it) will belong to this bug too ... or should I try to somehow compile svgalib 64bit and file different bugreport ?
you're mistaking userspace 32bit for kernelspace 64bit svgalib isnt 64bit safe thus it wont work in a 64bit kernel
Damn. I thought that was what I'm reporting as bug ! Once again: I'm assuming that "resolved invalid" mean reported bug in fact doesn't exists, which is NOT this case. Did you at least contact some svgalib developers and tell them there is demand for this ? Or should I ?
no, ive never contacted upstream about this because i never cared if you care to, feel free to take it up and get back to us this bug was INVALID because what you were trying to do is INVALID ... run a 32bit kernel module in a 64bit kernel
That's not true. There are checks in load_module (kernel/module.c) against that. What I did (when I'm talking about "by hand" part) was taking C source code, compiling it 64bit, insmod it and try to use it. The step which failed was last one - use it. That means there are some part of code which don't work when compiled 64bit or in 64bit kernel (amd64 kernel can have different memory mapping or so). I try to contact developers about that. Second part of bug: could you make new ebuild svgalib_helper, which will use svgalib sources and install only module ?
no, i wont be forking the ebuild
From maintainer response: svgalib-1.9.21 has a no module mode (this is selected at compile time by editting Makefile.cfg, uncommenting the line NO_HELPER=y). Svgalib module does work on alpha, so there is no problem with 64 bits. It's just that every architecture needs support added specifically. Also, Alpha does not have 32bit userspace on 64bit kernel issues.
maybe that's because Alpha never had a 32bit userspace ... it was a 64bit chip from day 1
That's pretty obvious ... So, can you make use flag for compilling svgalib-1.9.21 with NO_HELPER = y ?
i dont see the point svgalib apps are pretty pointless without the driver arent they ?
It doesn't mean svgalib will be without driver, it only mean driver will be entire in userspace as it was in 1.4.3 and before. Note, card-dependend part of driver is in userspace everytime. (Also, svgalib apps will need setuid-root in that case.)
i was not aware of this feature, a local USE flag def seems appropriate then as you've suggested
svgalib-1.9.21 now supports USE=no-helper that should cover everything, yeah ?
Yes and no. It should solve my problem (I didn't test it yet - it will need reboot), because I'm running svga programs as root anyway ... but that is security risk. Make svgalib programs set-uid root is even bigger security risk. That's the reason svgalib_helper was introduced in first place. On the other hand, it's much simpler that debugging original problem or adding full amd64 support. BTW, you should change bug summary again. This solution isn't 64bit support, it's 32bit chroot on amd64 support. Don't remove yourself from this bug, I'll return to it if/when better solution will be available.
I don't know how exactly is portage synchronized, maybee I have old version, but I tried that flag and it have not enough efect. First, ebuild is still searching for kernel sources. Second, Makefile.cfg is not modified. I tried modify Makefile.cfg by hand with suspended (ctrl-Z) emerge and emerge worked without error. Now I'll go to test if svgalib work.
It's working. So all what's needed is some (conditional) patch or sed expression. Do you know how to do it or should I add it as attachment to this bug ? (It's about uncommenting the line NO_HELPER=y)
added this to the ebuild: use no-helper && sed -i '/^# NO_HELPER/s:# ::' Makefile.cfg
