Thread: [Kaffeine-user] Moving kaffeine to KDE extragear brings back old bugs
Brought to you by:
hftom,
lasselindqvist
From: Markku K. <ma...@tu...> - 2005-09-27 15:29:15
|
I saw the notice on kaffeine homepage that the source code repository has changed to KDE extragear subversion. Checking out the code and compliling shows that the compiler flags bugs that were fixed over a month ago in CVS are back in SVN. Doesn't the code in SVN match the latest CVS version? if /bin/sh ../../../libtool --silent --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../kaffeine/player-parts/ -I/usr/include/kde -I/usr/lib/qt-3.3/include -I/usr/X11R6/include -DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -g -O2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -MT dvbevents.lo -MD -MP -MF ".deps/dvbevents.Tpo" -c -o dvbevents.lo dvbevents.cpp; \ then mv -f ".deps/dvbevents.Tpo" ".deps/dvbevents.Plo"; else rm -f ".deps/dvbevents.Tpo"; exit 1; fi /usr/include/linux/dvb/dmx.h:165: error: '__u64' does not name a type make[4]: *** [dvbevents.lo] Error 1 make[4]: Leaving directory `/home/mk/src/multimedia/kaffeine/src/dvb' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/mk/src/multimedia/kaffeine/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/mk/src/multimedia/kaffeine' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/mk/src/multimedia' make: *** [all] Error 2 This is caused by the "-ansi" flag that disables the non-standard __u64 type. Already discussed and solved in: http://sourceforge.net/mailarchive/message.php?msg_id=12645458 -- Markku Kolkka mar...@ik... |
From: <kaf...@gm...> - 2005-09-27 21:10:11
|
Hi, >I saw the notice on kaffeine homepage that the source code >repository has changed to KDE extragear subversion. Checking out >the code and compliling shows that the compiler flags bugs that >were fixed over a month ago in CVS are back in SVN. Doesn't the >code in SVN match the latest CVS version? > > The code is (nearly) the same but in extragear we use the common KDE admin stuff of course. If someone knows a way to override the default flags... Jürgen |
From: Hendrik S. <ub...@st...> - 2005-09-27 22:22:18
|
Am Dienstag, 27. September 2005 23:10 schrieb J=C3=BCrgen Kofler: > Hi, > > >I saw the notice on kaffeine homepage that the source code > >repository has changed to KDE extragear subversion. Checking out > >the code and compliling shows that the compiler flags bugs that > >were fixed over a month ago in CVS are back in SVN. Doesn't the > >code in SVN match the latest CVS version? > > The code is (nearly) the same but in extragear we use the common KDE > admin stuff of course. If someone knows a way to override the default > flags... How about using the standard C99 uint64_t instead? You can find it in=20 inttypes.h and define __u64 with it if undefined (can be tested in configur= e)=20 before including the problematic header file. Additionally, this seems to be limited to some linux-kernel-headers version= s,=20 the package in Debian testing (2.6.13+0rc3-1.1) does not have this problem. Having -ansi for something like KDE is the proper way if you ever want to=20 support non-gcc compiles. HS |
From: Markku K. <ma...@tu...> - 2005-09-28 08:43:15
|
Hendrik Sattler kirjoitti viestiss=C3=A4=C3=A4n (l=C3=A4hetysaika keskivi= ikko,=20 28. syyskuuta 2005 01:21): > How about using the standard C99 uint64_t instead? Won't work: "-ansi" is the same as "-std=3Dc89", so none of the C99=20 extensions are available with that flag. If you can override the=20 KDE compiler flags, then you don't need to redefine the __u64=20 type anyway. =20 > You can=20 > find it in inttypes.h and define __u64 with it if undefined > (can be tested in configure) before including the problematic > header file. The "problematic header file" is part of the definition of the=20 kernel DVB driver interface, not an internal header of the=20 Kaffeine program. The __u64 type is defined=20 in /usr/include/asm/types.h, which is generated from=20 include/asm-<arch>/types.h in the kernel source tree. > Having -ansi for something like KDE is the proper way if you > ever want to support non-gcc compiles. You mean that the Linux kernel must be changed to work with KDE=20 instead of the other way round? If -ansi breaks the Linux device=20 interface, then it shouldn't be used to compile on Linux. --=20 Markku Kolkka mar...@ik... |
From: Hendrik S. <ub...@st...> - 2005-09-28 16:34:45
|
Am Mittwoch, 28. September 2005 10:43 schrieb Markku Kolkka: > Hendrik Sattler kirjoitti viestiss=C3=A4=C3=A4n (l=C3=A4hetysaika keskivi= ikko, > > 28. syyskuuta 2005 01:21): > > How about using the standard C99 uint64_t instead? > > Won't work: "-ansi" is the same as "-std=3Dc89", so none of the C99 > extensions are available with that flag. If you can override the > KDE compiler flags, then you don't need to redefine the __u64 > type anyway. Hmm, no, from the gcc manpage: -ansi In C mode, support all ISO C90 programs. In C++ mode, remove GNU extensions that conflict with ISO C++. And later in the same place: -std=3D Determine the language standard. [...] The -std options specifying some version of ISO C have the same effects as -ansi, except that features that were not in ISO C90 but are in the specified version (for example, // comments and the "inline" keyword in ISO C99) are not disabled. So why not ask to KDE guys to go with the future and stick to standards fro= m=20 1998/1999? Earlier systems cannot run KDE anyway. > > You can > > find it in inttypes.h and define __u64 with it if undefined > > (can be tested in configure) before including the problematic > > header file. > > The "problematic header file" is part of the definition of the > kernel DVB driver interface, not an internal header of the > Kaffeine program. The __u64 type is defined > in /usr/include/asm/types.h, which is generated from > include/asm-<arch>/types.h in the kernel source tree. Ok, you have an older system with broken kernel headers, then. Current linu= x=20 kernel headers (the ones in the system should be what your libc is compiled= =20 against) do not have any problem with the -ansi option, even without=20 specifying -std=3Dc99 > > Having -ansi for something like KDE is the proper way if you > > ever want to support non-gcc compiles. > > You mean that the Linux kernel must be changed to work with KDE > instead of the other way round? If -ansi breaks the Linux device > interface, then it shouldn't be used to compile on Linux. No, but kernel headers used to break compilations like that a long time. By= =20 now, they fixed that. Maybe both needs updating, the linux-kernel-headers on your system and the = KDE=20 build defaults. HS |
From: Markku K. <ma...@tu...> - 2005-09-29 11:33:17
|
Hendrik Sattler kirjoitti viestiss=C3=A4=C3=A4n (l=C3=A4hetysaika keskivi= ikko,=20 28. syyskuuta 2005 19:34): > So why not ask to KDE guys to go with the future and stick to > standards from 1998/1999? Earlier systems cannot run KDE > anyway. Because you compatibility with the target platform is more=20 important. > Ok, you have an older system with broken kernel headers, then. Fedora Core 4 with all current updates. The asm/types.h from=20 glibc-kernheaders matches include/asm-386/types.h in Linux=20 2.6.13.2. If that's broken then the latest vanilla Linux kernel=20 release is broken. > Current linux kernel headers (the ones in the system should be > what your libc is compiled against) do not have any problem > with the -ansi option, even without specifying -std=3Dc99 Show the definition of __u64 from your asm/types.h. If it uses=20 the C99 types, that's a distro-specific patch. --=20 Markku Kolkka mar...@ik... |
From: Dexter F. <Dex...@gm...> - 2005-10-04 10:03:32
|
On Thu, 29 Sep 2005 14:33:08 +0300 Markku Kolkka <ma...@tu...> wrote: > Hendrik Sattler kirjoitti viestiss=E4=E4n (l=E4hetysaika keskiviikko,=20 > 28. syyskuuta 2005 19:34): > > So why not ask to KDE guys to go with the future and stick to > > standards from 1998/1999? Earlier systems cannot run KDE > > anyway. >=20 > Because you compatibility with the target platform is more=20 > important. >=20 > > Ok, you have an older system with broken kernel headers, then. Well. Kernel headers are a particular burden here. I'm running Slackware 10.2, which out of the box has kernel 2.4.31. Yes, still 2.4 by default. There are 2.6 kernels and headers in testing, but following the chief maintainer's advice you're best off to use the headers that glibc was compiled with rather than switching or recompile glibc when installing different headers. Now with Slackware 10.2 there's a second glibc for the 2.6 kernel headers which are ok to install but: it breaks KDE build= s. KDE will _run_, but it won't _compile_. So I'm really not to keen on this since 3rd party KDE apps might be affected as well and stick with the 2.4 headers. If anyone has good advice (where "switching distros" violates the "good" criterion) - lemme know. Dex |