On Tue, Aug 26, 2003 at 04:22:45PM +0200, Maik Zumstrull wrote: > Okay, here's what I did. I freshly untarred vdr-1.2.4.tar.bz2, created > the Make.config as attached (/usr/src/linux is an unpatched > linux-2.6.0-test4), and called: > > make > ~/make.log 2>&1 > > The resulting make.log is attached. > > Afterwards, I deleted the vdr tree and untarred freshly again. I copied > the same Make.config in, and then, in the Makefile, changed the line: > > INCLUDES = -I$(DVBDIR)/include > > to be: > > INCLUDES = -idirafter $(DVBDIR)/include > > Then I ran: > make > ~/make2.log 2>&1 > > The resulting logilfe is attached. Ok, according to your logs, you are just hiding the problem instead of solving it. What you are doing here, is mixing 2.6 kernel headers with 2.2 or 2.4 kernel headers (depending on which kernel your glibc was built). For your luck this just worked, but it will no longer work from that date on when your distribution starts building their glibc on a 2.6 kernel. Note that the problem is not vdr, but the fact that the kernel uses "new" as a parameter name in linux/ioport.h:91. This is valid in C, but not allowed in C++ because "new" is a keyword in C++ and such cannot be used as an identifier. Because of that linux/ioport.h must never be included in a C++ program. As linux/device.h includes this one, linux/device.h is also a no-no for C++-Applications. The same applies to linux/videodev.h because it includes linux/device.h. So either the kernel developers change the parameter name from "new" to a different name, they change inclusion structure for user space applications in one of the headers mentioned above, or the linux/videodev.h header must _not_ be used in C++ applications. Robert -- Robert Schiele Tel.: +49-621-181-2517 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de
Attachment:
pgp00005.pgp
Description: PGP signature