Summary: | media-libs/svgalib-1.9.25 helper fails to build with 2.6.23 sources. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dan Coats <admin> |
Component: | New packages | Assignee: | SpanKY <vapier> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alonbl, andriy155, apoliak, bugs, dark.knight.ita, dcecchin, dhp_gentoo, dkarasik, ed, fcoiffie, gengor, matthew.m.mccormick, mauriziopucci, mirimiri66, p.gentoo, pdenapo, psalters, rene.rheaume, rjm40, sgtphou, tacvbo, teidakankan, tm, transacid, xsak |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 195298 | ||
Attachments: |
patch for the kernel API change
My modified ebuild for svgalib-1.9,.25 for applying this patch /var/log/portage/media-libs:svgalib-1.9.25:20071014-174543.log patch for the kernel API change (diff -u version) |
Description
Dan Coats
2007-10-12 16:28:59 UTC
I can confirm the bug, I'm having the same trouble. The problem is related to the following lines in kernel/svgalib_helper/kernel26compat.h if (!defined _LINUX_DEVFS_FS_KERNEL_H) || (defined KERNEL_2_6) static inline int devfs_register_chrdev (unsigned int major, const char *name, struct file_operations *fops) { return register_chrdev (major, name, fops); } static inline int devfs_unregister_chrdev (unsigned int major,const char *name) { return unregister_chrdev (major, name); } #endif This is a hack for compatibility wirh devfs (when actually there is no devfs in kernel 2.6.23) The problem is caused by a change in the kernel API. In 2.6.22 the declaration of the function unregister_chrdev (in include/linux/fs.h) was: extern int unregister_chrdev(unsigned int, const char *); whereas in 2.6.23 we have extern void unregister_chrdev(unsigned int, const char *); (the returned type changed from int to void) (Acording to the code in int unregister_chrdev(unsigned int major, const char *name) { struct char_device_struct *cd; cd = __unregister_chrdev_region(major, 0, 256); if (cd && cd->cdev) cdev_del(cd->cdev); kfree(cd); return 0; } that function in 2.6.22 always returned 0 I'll submit a patch Created attachment 133276 [details, diff]
patch for the kernel API change
I've chequed that this pacth to svgalib-1.9.25 works both for kernel-2.6.23 and kernel 2.6.22.9 (vanilla sources from kernel.org)
Created attachment 133278 [details]
My modified ebuild for svgalib-1.9,.25 for applying this patch
Created attachment 133463 [details]
/var/log/portage/media-libs:svgalib-1.9.25:20071014-174543.log
Same bug here:
/var/tmp/portage/media-libs/svgalib-1.9.25/work/svgalib-1.9.25/kernel/svgalib_helper/kernel26compat.h:76: error: implicit declaration of function 'register_chrdev'
/var/tmp/portage/media-libs/svgalib-1.9.25/work/svgalib-1.9.25/kernel/svgalib_helper/kernel26compat.h: In function 'devfs_unregister_chrdev':
/var/tmp/portage/media-libs/svgalib-1.9.25/work/svgalib-1.9.25/kernel/svgalib_helper/kernel26compat.h:80: error: implicit declaration of function 'unregister_chrdev'
make[2]: *** [/var/tmp/portage/media-libs/svgalib-1.9.25/work/svgalib-1.9.25/kernel/svgalib_helper/interrupt.o] Error 1
make[1]: *** [_module_/var/tmp/portage/media-libs/svgalib-1.9.25/work/svgalib-1.9.25/kernel/svgalib_helper] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.23-gentoo'
make: *** [default] Error 2
*
* ERROR: media-libs/svgalib-1.9.25 failed.
* Call stack:
* ebuild.sh, line 1695: Called dyn_compile
* ebuild.sh, line 1033: Called qa_call 'src_compile'
* ebuild.sh, line 44: Called src_compile
* svgalib-1.9.25.ebuild, line 78: Called linux-mod_src_compile
* linux-mod.eclass, line 518: Called die
* The specific snippet of code:
* emake HOSTCC="$(tc-getBUILD_CC)" CC="$(get-KERNEL_CC)" LDFLAGS="$(get_abi_LDFLAGS)" \
* ${BUILD_FIXES} ${BUILD_PARAMS} ${BUILD_TARGETS} \
* || die "Unable to make ${BUILD_FIXES} ${BUILD_PARAMS} ${BUILD_TARGETS}."
* The die message:
* Unable to make KDIR=/usr/src/linux default.
*
* If you need support, post the topmost build error, and the call stack if relevant.
* A complete build log is located at '/var/log/portage/media-libs:svgalib-1.9.25:20071014-174543.log'.
*
--------------------------- ACCESS VIOLATION SUMMARY ---------------------------
LOG FILE = "/var/log/sandbox/sandbox-media-libs_-_svgalib-1.9.25-27801.log"
open_wr: /usr/src/linux-2.6.23-gentoo/null.gcda
open_wr: /usr/src/linux-2.6.23-gentoo/null.gcda
open_wr: /usr/src/linux-2.6.23-gentoo/null.gcda
open_wr: /usr/src/linux-2.6.23-gentoo/null.gcda
--------------------------------------------------------------------------------
root@moon_gen_2:~#
CC me have you tried my pathc? The line #include <linux/fs.h> in my patch is needed for avoiding the error: implicit declaration of function 'register_chrdev' have you tried my pathc? The line #include <linux/fs.h> in my patch is needed for avoiding the error: implicit declaration of function 'register_chrdev' Unified diffs preferred, thanks. Created attachment 133540 [details, diff]
patch for the kernel API change (diff -u version)
Ok, here is my patch in diff -u format
(In reply to comment #9) > Created an attachment (id=133540) [edit] > patch for the kernel API change (diff -u version) > > Ok, here is my patch in diff -u format > Compiled here okay. Thanks. *** Bug 196347 has been marked as a duplicate of this bug. *** patch looks ok Vapier, can you test patch and merge it to mirors please ? I had the same issue, i set the no-helper USE flag and all was well. Not sure what that does, but I just wanted the thing to build. Is the patch/fix mentioned in this bug going to make it into portage anytime soon? The bug is almost a month old.h Just ran into this when 2.6.23-gentoo-r3 went stable recently on x86. Any chance to have the patch included quite quickly because it is not a feature one is expecting from a stable kernel ;) I will try the patch in my local overlay for the meantime. I am getting the same/similar error with ALL driver modules that I tried to build into 2.6.23-gentoo-r3. As a result I wouldn't flag this kernel as stable yet, but I guess it must 'work for some'? -- Regards, Mick The patch attached to this bug works fine for me, svgalib compiles fine and no regression observed so far. I gave it a whirl too, works nice. Hope it makes it into portage :) (sprinkles magic dust on SpanKY) I can also confirm that the patch allows it to compile. patch & modified ebuild work for me as well It's now 2 months everybody says the patch works, and it is not merged. I suggest we ask for a reassign. The fix is now trivial (move a file to portage); we need any maint to do this. Dan coats, do you agree ? how do we ask for re-assign ? SpanKY ususally does great work, but on this bug, we did not see him much. On a different note, why do people here actually use svgalib? Are other common apps unconditionally depending on it? It's just that svgalib seems rather useless and I would be surprised if a lot of people have a genuine use for it. Of course, I may be wrong :) Right, I have bo clue. It's a dep, and after compiling any kernel, we have to run update-modules and it fails due to svgalib, and it bores me. dhp@moon_gen_2:~$ equery depends media-libs/svgalib [ Searching for packages depending on media-libs/svgalib... ] media-libs/libggi-2.2.2 (svga? >=media-libs/svgalib-1.4.2) media-libs/libsdl-1.2.12 (svga? >=media-libs/svgalib-1.4.2) media-libs/netpbm-10.40.0 (svga? media-libs/svgalib) media-video/mplayer-1.0_rc2_p24929 (svga? media-libs/svgalib) media-video/vlc-0.9.0_alpha20071022 (svga? media-libs/svgalib) sci-visualization/gnuplot-4.2.2-r1 (svga? media-libs/svgalib) dhp@moon_gen_2:~$ obviously, it's a conditional dep; I put the flag for flexibility; imagine, the day I change my video card (that is going to happen next week in fact), for a few days, the driver of my old card wont work (try driver Nv on Matrox card ...) so, by the mean time, I can tell X to use vga compatible mode ... and during these few days, I can keep watching movie because I have taken care last year to put this feature: even when changing hardware, and breaking conf, I wont have service disruption. This is also usefull for SDL in DirectFB, and headless X servers (like Xmove). Last point: I use xinerama, so, mplayer tends to heavily fail because of disabled DRI. Only one mplayer can open my main graphic diver, when I want to run a second mplayer in video mode, it falls back on svga driver; this allows me to halt a movie, and preview an other one for a few seconds, on a different screen. this also allows me to show movies on cards that do not support HW acceleration at all (in my Xinerama, I mix several cards of different manifacturers). It gives very low performance, but, in many cases, it adds flexibility, and continuity of service in cases where otherwise, things would not work at all. Allows to run netpbm and gnuplot in dumb X servers (for heavy scripting, when you want heavy generation of graphics, without actually requirering a real "visible" X). I don't recall why I added svga to my USE flags but I think that there was a program I was using depending on it unconditionally so I enabled it on the whole system as it was installed anyways. I just checked and all programs depending on svgalib are using svga USE flag. For me it would be just fine to removed svga from USE flag and don't worry about it any more. Do I understand you right that you consider svgalib useless in general? In that case would be punting svga USE flag and removing svgalib from tree an option if noone is willing to maintain it? Comments? Dustin: no way. Take an old PC with old video card, no HW accel at all: no way to use X without svgalib (thats my case since my Xinerama mixes old and new cards). (In reply to comment #25) > Dustin: no way. > > Take an old PC with old video card, no HW accel at all: no way to use X without > svgalib (thats my case since my Xinerama mixes old and new cards). > It is the conclusion I draw considering Daniel's statement in comment #22. If you disagree - and I understand the reasons given in comment #23 -, svgalib needs to stay and be maintained. I'm not suggesting that svgalib should be removed or that this bug can be closed without resolution. But I do feel that it is probably useless for most of the people on this bug, maybe with one or two exceptions. Given that svgalib is dead upstream, not very well maintained downstream, and probably not actually used by most of the people on this bug, you can probably save yourselves some hassle and just remove it from your systems. I removed svga from my USE flags and will see whether I can live without it. I strongly disagree with comment #27. I'm really using svgalib, I love to use zgv, mplayer in svgalib mode, etc. Linux is freesoftware, so we can run the software that we want, not the software that others decide that we should run. I'm rather dissappointed with Gentoo, since I've sumitted my patch two months ago, it worked for everywone but it is not yet on portage. What are you waiting for? I am just asking for a patch said to work, to be merged to portage ! Cant any maint do this for us ? *** As said below, also works for me :) It's because I am tired of that trivial 2 month bug I made comment 21 this morning. Your coment is roughly redundant with my comments 21 and 23 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** This should fix it for me for a long time: (I grab here all commands for example purpose; I cant garanty it will work for _you_ ) (I assume you also have your own overlay like /opt/doublehp/usr/portage/ for me) mkdir -p /opt/doublehp/usr/portage/media-libs/ cp -a /usr/portage/media-libs/svgalib /opt/doublehp/usr/portage/media-libs/ cd /opt/doublehp/usr/portage/media-libs/svgalib/files wget http://bugs.gentoo.org/attachment.cgi?id=133540 mv attachment.cgi\?id\=133540 svgalib-1.9.25-unregister_chrdev.patch cd .. # edit the ebuild svgalib-1.9.25.ebuild and at the end of src_unpack() add # epatch "${FILESDIR}"/${PN}-1.9.25-unregister_chrdev.patch ebuild svgalib-1.9.25.ebuild digest cd emerge -va1 svgalib check it uses your overlay, and it should work. Now, until there is a release, this will provide a fix that will resist to esync. OK, apologies for my "svgalib is useless" comments, as maybe there are still a few more than 1 or 2 happy users :) For everyone else, unless you know you are using svgalib for something useful, I'd still suggest trying to get rid of it from your systems. The combination of a dead upstream against a fast-moving unstable internal kernel API means that we'll continue to be plagued with problems for the entire lifetime of this package. This bug needs an existing maintainer to review and commit the fix, or for another developer to ask for permission to do so. I'll ask mike about his interests here and maybe see if someone else would be interested in taking over this package. (I have no interest myself, maintaining external kernel modules inside portage is a headache that never goes away) If you do remove USE flag svga on your stable x86 system, note that dosemu will no longer compile: http://bugs.gentoo.org/show_bug.cgi?id=169638 if you have the time to complain, you have the time to maintain ... otherwise you can wait until someone cares enough to commit in the tree We do not all have knowledge to write fixes. Amongst bugs that I created those last yeas, some concern C, Awk, Pascal, ebuilds, Java, Bash, Python, and many other langages I may have forget (only mentioning those that I would have need to fix bugs I created here). Few users know programming; none can be expected to masterate ALL langages. So, we create bugs and hope people who have the knowledge find a fix. It's weeks I am working on the genkernel bug, and weeks I really do not understand awk scripting. Further: very few of us have the rights to commit ebuilds in portage; if we had, version bumps, or new ebuilds would not wait for YEARS before getting in the tree. We all meet bugs; we take time to report (that is already an effort), we may have knowledge to fix, but, no end-user have the power to boost commit-in-the-tree . then stop being an end user and step up to maintain the package To be fair it was users who submitted the bug report, tracked down the problem, created a patch, submitted it, tested it and confirmed that it works. All that it needs is a commit to the tree and that takes an official dev. it takes a dev who cares about svgalib and actually uses it ... neither of which exists (In reply to comment #27) > ... Here is an other example of why some people need svgalib, in my elogs: Package: mplayer-1.0_rc2_p25993 * Enabling vidix non-root mode. * (You need a proper svgalib_helper.o module for your kernel * to actually use this) (I know the bug is fixed). |