Compilation issues with recent DVB header files vs libc6

  Hi!

Recent DVB driver releases (now in Kernel 2.6.29) cause trouble compiling
VDR (see snippet A below).

The common solution to this seems to be to add a "-D__KERNEL_STRICT_NAMES".

It felt wrong somehow and I didn't liked this, so I tried another
solution, which is to have any libc6 <sys/*> includes appear before the
linux DVB header includes <linux/*>. Doing this only in dvbdevice.c seems
to do the trick for VDR (see snippet B). I works for VDR 1.6.0 as well as
VDR 1.7.4.

I think the root of this problem is caused by the Kernel headers / DVB
drivers changing from asm/types.h to linux/types.h:

-#include <asm/types.h>
+#include <linux/types.h>

How should this problem ideally be fixed? Is my solution (snippet B)
better than using -D__KERNEL_STRICT_NAMES or should the kernel / DVB
driver developers be blamed for this?

Tobias

--- snippet A ---

In file included from /usr/include/netinet/in.h:24,
                 from /usr/include/arpa/inet.h:23,
                 from config.h:13,
                 from channels.h:13,
                 from device.h:13,
                 from dvbdevice.h:15,
                 from dvbdevice.c:10:
/usr/include/stdint.h:41: error: conflicting declaration 'typedef long int
int64_t'
/usr/include/linux/types.h:98: error: 'int64_t' has a previous declaration
as 'typedef __s64 int64_t'
/usr/include/stdint.h:56: error: conflicting declaration 'typedef long
unsigned int uint64_t'
/usr/include/linux/types.h:96: error: 'uint64_t' has a previous
declaration as 'typedef __u64 uint64_t'


--- snippet B ---
  

On Wed, 08 Apr 2009 01:21:27 +0200
Tobi <listaccount@e-tobi.net> wrote:

> Recent DVB driver releases (now in Kernel 2.6.29) cause trouble compiling
> VDR (see snippet A below).
> 
> The common solution to this seems to be to add a "-D__KERNEL_STRICT_NAMES".
> 
> It felt wrong somehow and I didn't liked this, so I tried another
> solution, which is to have any libc6 <sys/*> includes appear before the
> linux DVB header includes <linux/*>. Doing this only in dvbdevice.c seems
> to do the trick for VDR (see snippet B). I works for VDR 1.6.0 as well as
> VDR 1.7.4.

I used -D__KERNEL_STRICT_NAMES but compilation then failed on the use of
__u8 in <linux/frontend.h>. ISTR reading that might only be a problem
for 64-bit. I resorted to changing it to unsigned char.

You'd think after some 10 years everyone would have settled on stdint by
now. :-/
  

Tony Houghton wrote:

> I used -D__KERNEL_STRICT_NAMES but compilation then failed on the use of
> __u8 in <linux/frontend.h>. ISTR reading that might only be a problem
> for 64-bit.

I didn't had this problem. VDR 1.6.0 and 1.7.4 compile fine with 2.6.29
and GCC 4.3 on x86_64. It works also with the latest drivers from Igors
repository.

Tobias
  

On 04/08/09 01:21, Tobi wrote:
> Hi!
> 
> Recent DVB driver releases (now in Kernel 2.6.29) cause trouble compiling
> VDR (see snippet A below).
> 
> The common solution to this seems to be to add a "-D__KERNEL_STRICT_NAMES".
> 
> It felt wrong somehow and I didn't liked this, so I tried another
> solution, which is to have any libc6 <sys/*> includes appear before the
> linux DVB header includes <linux/*>. Doing this only in dvbdevice.c seems
> to do the trick for VDR (see snippet B). I works for VDR 1.6.0 as well as
> VDR 1.7.4.
> 
> I think the root of this problem is caused by the Kernel headers / DVB
> drivers changing from asm/types.h to linux/types.h:
> 
> -#include <asm/types.h>
> +#include <linux/types.h>
> 
> How should this problem ideally be fixed? Is my solution (snippet B)
> better than using -D__KERNEL_STRICT_NAMES or should the kernel / DVB
> driver developers be blamed for this?

My 2ct:

- An application should not need to use -D__KERNEL_STRICT_NAMES.
- Any header file that requires other header files to be included
  should do so by itself.
- The sequence in which header files are included should not matter.
  I normally list them alphabetically, to easily find a particular one.

I currently solve the broken DVB driver header files by replacing them
with the ones from an earlier driver version, where they still worked.

I had posted this problem on the linux-dvb ML a while ago, but apparently
nobody cared...

Klaus
  

Hi,

is the linux-dvb ML still "alive"?
maybe http://vger.kernel.org/vger-lists.html#linux-media is read more frequently

Regards,
Matthias

2009/4/8 Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>:
> On 04/08/09 01:21, Tobi wrote:
>> Hi!
>>
>> Recent DVB driver releases (now in Kernel 2.6.29) cause trouble compiling
>> VDR (see snippet A below).
>>
>> The common solution to this seems to be to add a "-D__KERNEL_STRICT_NAMES".
>>
>> It felt wrong somehow and I didn't liked this, so I tried another
>> solution, which is to have any libc6 <sys/*> includes appear before the
>> linux DVB header includes <linux/*>. Doing this only in dvbdevice.c seems
>> to do the trick for VDR (see snippet B). I works for VDR 1.6.0 as well as
>> VDR 1.7.4.
>>
>> I think the root of this problem is caused by the Kernel headers / DVB
>> drivers changing from asm/types.h to linux/types.h:
>>
>> -#include <asm/types.h>
>> +#include <linux/types.h>
>>
>> How should this problem ideally be fixed? Is my solution (snippet B)
>> better than using -D__KERNEL_STRICT_NAMES or should the kernel / DVB
>> driver developers be blamed for this?
>
> My 2ct:
>
> - An application should not need to use -D__KERNEL_STRICT_NAMES.
> - Any header file that requires other header files to be included
>  should do so by itself.
> - The sequence in which header files are included should not matter.
>  I normally list them alphabetically, to easily find a particular one.
>
> I currently solve the broken DVB driver header files by replacing them
> with the ones from an earlier driver version, where they still worked.
>
> I had posted this problem on the linux-dvb ML a while ago, but apparently
> nobody cared...
>
> Klaus
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
  

On 04/08/09 15:00, Matthias Becker wrote:
> Hi,
> 
> is the linux-dvb ML still "alive"?
> maybe http://vger.kernel.org/vger-lists.html#linux-media is read more frequently

That one has way too much non DVB related traffic for me.

Klaus

> 2009/4/8 Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>:
>> On 04/08/09 01:21, Tobi wrote:
>>> Hi!
>>>
>>> Recent DVB driver releases (now in Kernel 2.6.29) cause trouble compiling
>>> VDR (see snippet A below).
>>>
>>> The common solution to this seems to be to add a "-D__KERNEL_STRICT_NAMES".
>>>
>>> It felt wrong somehow and I didn't liked this, so I tried another
>>> solution, which is to have any libc6 <sys/*> includes appear before the
>>> linux DVB header includes <linux/*>. Doing this only in dvbdevice.c seems
>>> to do the trick for VDR (see snippet B). I works for VDR 1.6.0 as well as
>>> VDR 1.7.4.
>>>
>>> I think the root of this problem is caused by the Kernel headers / DVB
>>> drivers changing from asm/types.h to linux/types.h:
>>>
>>> -#include <asm/types.h>
>>> +#include <linux/types.h>
>>>
>>> How should this problem ideally be fixed? Is my solution (snippet B)
>>> better than using -D__KERNEL_STRICT_NAMES or should the kernel / DVB
>>> driver developers be blamed for this?
>> My 2ct:
>>
>> - An application should not need to use -D__KERNEL_STRICT_NAMES.
>> - Any header file that requires other header files to be included
>>  should do so by itself.
>> - The sequence in which header files are included should not matter.
>>  I normally list them alphabetically, to easily find a particular one.
>>
>> I currently solve the broken DVB driver header files by replacing them
>> with the ones from an earlier driver version, where they still worked.
>>
>> I had posted this problem on the linux-dvb ML a while ago, but apparently
>> nobody cared...
>>
>> Klaus
  

On Wednesday 08 April 2009 14:04:39 Klaus Schmidinger wrote:
> On 04/08/09 15:00, Matthias Becker wrote:
> > Hi,
> >
> > is the linux-dvb ML still "alive"?
> > maybe http://vger.kernel.org/vger-lists.html#linux-media is read more
> > frequently
>
> That one has way too much non DVB related traffic for me.

Agreed - and since I subbed/unsubbed I've been getting a lot more spam to my 
dvb address. Can't be sure it's connected, but...

Andy
  

Tobi wrote:
> Hi!
> 
> Recent DVB driver releases (now in Kernel 2.6.29) cause trouble compiling
> VDR (see snippet A below).
> 
> The common solution to this seems to be to add a "-D__KERNEL_STRICT_NAMES".
> 
> It felt wrong somehow and I didn't liked this, so I tried another
> solution, which is to have any libc6 <sys/*> includes appear before the
> linux DVB header includes <linux/*>. Doing this only in dvbdevice.c seems
> to do the trick for VDR (see snippet B). I works for VDR 1.6.0 as well as
> VDR 1.7.4.
> 
> I think the root of this problem is caused by the Kernel headers / DVB
> drivers changing from asm/types.h to linux/types.h:
> 
> -#include <asm/types.h>
> +#include <linux/types.h>
> 
> How should this problem ideally be fixed? Is my solution (snippet B)
> better than using -D__KERNEL_STRICT_NAMES or should the kernel / DVB
> driver developers be blamed for this?

The kernel headers should be fixed to use strict types (patches
available). See my earlier reply on the issue:
http://linuxtv.org/pipermail/vdr/2009-March/019783.html
  

Anssi Hannula wrote:

> The kernel headers should be fixed to use strict types (patches
> available). See my earlier reply on the issue:
> http://linuxtv.org/pipermail/vdr/2009-March/019783.html

You're right. Thanks for the pointer! I've seen this weeks ago and thought
 it would have already made it into 2.6.29.

I've applied the patch from Arnd Bergmann's core/header-fixes branch to
2.6.29.1 which seems to work fine.

Let's hope this gets fixed in 2.6.29.x or 2.6.30.

Tobias
  

Tobi wrote:
> Anssi Hannula wrote:
> 
>> The kernel headers should be fixed to use strict types (patches
>> available). See my earlier reply on the issue:
>> http://linuxtv.org/pipermail/vdr/2009-March/019783.html
> 
> You're right. Thanks for the pointer! I've seen this weeks ago and thought
>  it would have already made it into 2.6.29.
> 
> I've applied the patch from Arnd Bergmann's core/header-fixes branch to
> 2.6.29.1 which seems to work fine.
> 
> Let's hope this gets fixed in 2.6.29.x or 2.6.30.

The patches have been applied for 2.6.30.