Bug 86188

I'm having the exact same problem (under Slackware 10.0, and with KDE 3.3 final)...  I'm going to try installing the binary package and removing kdemultimedia from the konstruct compile package list, but it would be nice if this was fixed as well.

kdemultimedia v 3.2.3 compiled fine on my system with its kernel 2.4.23 headers, but v 3.3.0 fails. This patch restores the former happy state (by restoring mpeglib/lib/input/cdromAccess_Linux.cpp to its v 3.2.3 state):

--- kdemultimedia-3.3.0/mpeglib/lib/input/cdromAccess_Linux.cpp 2004-05-22 20:56:58.000000000 +0000
+++ kdemultimedia-3.2.3/mpeglib/lib/input/cdromAccess_Linux.cpp 2003-10-26 10:55:50.000000000 +0000
@@ -13,6 +13,10 @@

 #include "cdromToc.h"
 #include "cdromRawAccess.h"
+#ifndef __GNUC__
+#define __GNUC__ 1
+#endif
+#undef __STRICT_ANSI__
 #include <asm/types.h>
 #include <linux/cdrom.h>
 #include <sys/ioctl.h>

A bit more investigation shows that this code from mpeglib/lib/input/cdromAccess.cpp seems to be trying to overcome the problem:

#ifdef OS_Linux
  #include <linux/version.h>
  #include <sys/types.h>
  #ifndef __u64
  #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,70)
  typedef unsigned long long __u64;
  #endif
  #endif
  #include "cdromAccess_Linux.cpp"
#endif

I'm happy to be corrected, but I think that, on i386, "#ifndef __u64" will always be true because __u64 is a typedef (rather than a #define) to unsigned long long in asm/types.h. But then the "local" typedef is guarded and only "executes" if the kernel is 2.5.70 or later. As I said in the previous post, my headers are from 2.4.23. I guess 2.5 changes must have been backported.
It looks to me as if the only real way to overcome this is through an entry in config.h (HAVE___U64?), but setting up the gnu build system is a complete mystery to me, so I can't help there, sorry

Created attachment 7230 [details]
Makes mpeglib compile on slackware 10.

I posted this a while ago to kde-devel and kde-multimedia, not knowing there
was a bugreport. I've lifted the code from k3b, where it appears to work pretty
well...

Well, If I can do I commit this changes and I close this bug. Can I commit it?

Removing of "-ansi" option also helps.

Created attachment 7426 [details]
Patch to correct "undefined __u64"

If __u64 can be redefined as unsigned long long.
This patch does this.

With this it compiles? Can I commit it or is not good? If it's not good can someone explain me why? I don't think under Slackware I have to use workaround to compile. I'd like to have a kdemultimedia package that compile on his own.

Sorry it's not a question. I tryed and it compiles.

Can someone please commit one of the two provided patches? This is *so* annoying.

Created attachment 7486 [details]
cdromAccess_Linux.cpp changed and my old patch wouldn't apply anymore.

Created attachment 7487 [details]
This time the patch actually *works*

I'm an idiot. Didn't actually test the previous patch. This one works.

Well, some people of kdemultimedia told me on IRC these patches cannot be committed because on others platforms can cause the same problem I have on Linux Slackware. I think this bug will stay open for a lot of time. Maybe it will never be closed.

So, would those people care to explain that again in this bugreport? I find it odd, because k3b uses the same trick (#undef __STRICT_ANSI__, that is),

Does anybody know what slack did to the kernel headers to break this? Is it something that should be reported to slackware.org?

As an aside, IMHO bugs should not just be discussed on IRC. As a minimum post the IRC logs here for the benefit of the people that didn't happen to lurk on IRC at that time.

Its a kernel header problem not Slackware problem.

CVS commit by coolo: 

work around buggy kernel headers
BUG:86188


  M +7 -0      cdromAccess_Linux.cpp   1.9


--- kdemultimedia/mpeglib/lib/input/cdromAccess_Linux.cpp  #1.8:1.9
@@ -11,6 +11,13 @@
  */
 
+#ifdef __STRICT_ANSI__
+#undef __STRICT_ANSI__
+#define _ANSI_WAS_HERE_
+#endif
 #include <linux/types.h>
 #include <linux/cdrom.h>
+#ifdef _ANSI_WAS_HERE_
+#define __STRICT_ANSI__ 
+#endif
 #include <sys/ioctl.h>
 

So this is basically the patch I suggested, somewhat bombproofed. What changed, besides coolo's karma, that this is all of a sudden acceptable?

Yes, this works now.  It will build without the: "--disable-warnings" paramater for the 'configure' script.

Please backport to 3.3 branch by moving the CVS tag: "KDE_3_3_BRANCH" from 1.7 to 1.9.

--
JRT

Please apply this Patch to 3.3.3 and later, because 3.3.2 is still missing it :o(