| Summary: | media-plugins/gst-plugins-v4l fails with linux-headers-2.6.38+ | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Christoph Brill (egore) (RESIGNED) <egore> |
| Component: | Current packages | Assignee: | GStreamer package maintainers <gstreamer> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 359595 | ||
|
Description
Christoph Brill (egore) (RESIGNED)
2011-03-20 19:01:27 UTC
Add blocker Actually the real fix is to remove that header - that's how it got fixed in gst-plugins-good 0.10.28. But perhaps this is a good point to consider switching to libv4l - like i.e. vlc. configure option: '--with-libv4l2' Since the fix is in 0.10.28, what's the problem? I guess unsynced tree, as the version where this is fixed was committed to tree 8.5 hours before this report? Though I wonder if gst-plugins-v4l (note the lack of 2 in the end of that package name) compiles and works anymore. Oh, and libv4l2 is discussed in bug 250079 compiles: definitely not - sys/v4l/gstv4lelement.h includes linux/videodev.h works: haven't checked, but chances are neither - as I said elsewhere: header was removed, cause it's removed in kernel I'd say best part of the mentioned bug is final Samuli's comment. But if a solution is already present in that bug, why wasn't it implemented ? The problem you've reported is in gst-plugins-v4l not gst-plugins-v4l2 Same problem with libv4l-0.8.1: log.c:22:28: fatal error: linux/videodev.h: No such file or directory compilation terminated. I've just hit the very problem with libv4l-0.8.1 this morning. I did not find a bug for it--do I need to file a fresh bug report for libv4l? Actually, this is a non-bug.. With 2.6.38, v4l1 has been removed from 2.6.38 and all drivers have been ported to v4ol2, so you should just use gst-plugins-v4l2 When 2.6.38 goes stable, we'll just p.mask gst-plugins-v4l But wait--there's still a problem. There may be an upgrade path for gst-plugins, but there doesn't seem to be one for what I was talking about: libv4l. This library, which supports both V4L and V4L2, is a dependency for xine-libs, kopete, and vlc, plus ten other packages. (I have the first three installed.) If linux 2.6.38 breaks libv4l, there will be problems. In the meantime, while 2.6.36-r8 is the latest stable version (and V4L is still in the kernel), I might just try the trick that someone suggested in the forums: ln -s videodev2.h videodev.h So, am I back to needing to file a separate bug? (In reply to comment #11) > But wait--there's still a problem. There may be an upgrade path for > gst-plugins, but there doesn't seem to be one for what I was talking about: > libv4l. This library, which supports both V4L and V4L2, is a dependency for > xine-libs, kopete, and vlc, plus ten other packages. (I have the first three > installed.) Do these apps actually use actually require V4L (and not V4L2) APIs? I suspect not in most cases. > If linux 2.6.38 breaks libv4l, there will be problems. In the meantime, while > 2.6.36-r8 is the latest stable version (and V4L is still in the kernel), I > might just try the trick that someone suggested in the forums: > ln -s videodev2.h videodev.h That's not a very good idea. libv4l ships a copy of the deleted videodev.h, so you need to patch apps if they're actually using videodev.h to use this replacement header (but really, they should just be ported to v4l2 - the v4l interface will go away completely in a while). I don't know for sure what will happen with libv4l. This is clearly an issue for the respective upstream providers to resolve--they have to be aware that 2.6.38 is putting the hammer down on V4L. libv4l comes from the main upstream of all the video-driver magic, linuxtv.org. Surely they know what is going on with the kernel! The question lies with the packagers who depend on libv4l. If they're using the library to get at V4L2, they're probably OK, but if they're working with the old API, they're the ones that will have to adjust. And by the way, that symlink trick with the header files didn't work for me. I think it was supposed to work with gst-plugins, but the emerge for libv4l failed when I tried it there. I downgraded linux-headers to 2.6.36.1 and got things to compile. So I have my answer: this is an upstream problem, and not the subject for a Gentoo bug. Removed from tree. Use gst-plugins-v4l2. |
