Re: Bug#220399: Glibc people please comment on correct fix
On Mon, Nov 17, 2003 at 03:20:48PM +0100, guenter geiger wrote:
>
> On Sun, 16 Nov 2003, Daniel Jacobowitz wrote:
> > On Sun, Nov 16, 2003 at 09:43:35PM -0500, Nathanael Nerode wrote:
> > > I'm going to CC: this to debian-glibc in hopes that someone there can
> > > comment on whether linux/videodev.h is intended to be used from
> > > userspace (in which case it's clearly their bug), and if not what the
> > > replacement userspace header is.
> >
> > Everyone loses: it is not intended to be used from userspace, was in
> > general never intended to be, and there is no replacement. However, at
> > least for sarge, we are taking the pragmatic approach - we'll fix it to
> > work from userspace (if any of the glibc maintainers ever find time
> > again :().
> >
> > If you can provide a patch for the issue that would of course help. I
> > thought I'd already fixed <linux/videodev.h>; I was able to build
> > mplayer using it...
>
> Hmm, I see, although I don't understand, as I thought it was well accepted
> that the /usr/include/linux headers are used in userspace ...
> why would someone have gone through the troubles of adopting them
> during all of these years, if it would have been useless :)
>
> The patch that I need is actually trivial:
> as /linux/videodev.h includes linux/videodev2.h which in turn includes
> linux/time.h, its inclusion creates a conflict with the proper time.h.
>
> (As both time.h and linux/time.h declare the struct timeval)
>
> One possibility is to change the linux/time.h into time.h in videodev2.h.
> I am not sure if this is the best way to solve it though.
>
> Another possibility would be to let time.h use linux/time.h, which would
> avoid the redundant declaration of struct timeval.
>
> .. or declaring struct timeval in videodev2.h directly without additional
> includes ..
>
> ... aso
>
> Being at it, the best thing to do would be to create a userspace header
> for the videodev.h
>
> Well, you see, several options, and I am not familiar enough with the
> situation and its future development to judge which is the best.
>
> Any guidance is appreciated,
OK, the conflict with <time.h> is already reported (see the BTS for
linux-kernel-headers); it should be fixed sometime soon.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Reply to: