kdemultimedia-3.1.4-r1 fails to emerge with gcc-3.3.2-r1, and no doubt will also do so with gcc-3.3.2-r2. This may be to do with strict ansi issue in gcc-3.3.2 in /usr/include/asm/types.h "__u64 and __s64" are undefined because of __STRICT_ANSI__. BTW I noticed a commented patch line in the kdemultimedia ebuild "#$FILESDIR/${P}-gcc33.diff", could that solve the problem? The following should be self explanatory: /bin/sh ../../libtool --silent --mode=compile --tag=CXX g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/kde/3.1/include -I/usr/qt/3/include -I/usr/X11R6/include -DQT_THREAD_SUPPORT -D_REENTRANT -Wnon-virtual-dtor -Wno-long-long -Wundef -W all -pedantic -W -Wpointer-arith -Wwrite-strings -ansi -D_XOPEN_SOURCE=500 -D_BS D_SOURCE -Wcast-align -Wconversion -DNDEBUG -DNO_DEBUG -O2 -march=pentium4 -mcpu =pentium4 -mno-sse2 -O2 -fomit-frame-pointer -fno-exceptions -fno-check-new -DQT _CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -c -o audiocd.lo `test -f 'audiocd.cpp' || echo './'`audiocd.cpp rm: cannot remove `': Invalid argument In file included from /usr/include/linux/cdrom.h:14, from audiocd.cpp:57: /usr/include/asm/byteorder.h:38: error: syntax error before `(' token /usr/include/asm/byteorder.h:42: error: '__u64' is used as a type, but is not defined as a type. /usr/include/asm/byteorder.h:43: error: parse error before `}' token /usr/include/asm/byteorder.h:44: error: syntax error before `.' token /usr/include/asm/byteorder.h:50: error: syntax error before `.' token /usr/include/asm/byteorder.h:51: error: syntax error before `.' token /usr/include/asm/byteorder.h:52: error: parse error before `:' token audiocd.cpp:74: error: parse error before `}' token audiocd.cpp: In member function `cdrom_drive* AudioCD::AudioCDProtocol::initRequest(const KURL&)': audiocd.cpp:629: warning: deprecated conversion from string constant to `char*' make[4]: *** [audiocd.lo] Error 1 make[4]: Leaving directory `/var/tmp/portage/kdemultimedia-3.1.4-r1/work/ kdemultimedia-3.1.4/kioslave/audiocd' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/var/tmp/portage/kdemultimedia-3.1.4-r1/work/ kdemultimedia-3.1.4/kioslave/audiocd' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/kdemultimedia-3.1.4-r1/work/ kdemultimedia-3.1.4/kioslave' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/kdemultimedia-3.1.4-r1/work/ kdemultimedia-3.1.4' make: *** [all] Error 2 !!! ERROR: kde-base/kdemultimedia-3.1.4-r1 failed. !!! Function kde_src_compile, Line 137, Exitcode 2 !!! died running emake, kde_src_compile:make Reproducible: Always Steps to Reproduce: 1. 2. 3.
I have appended " --disable-strict --disable-warnings" to myconf in the ebuild. It clean compiles. myconf="$myconf --enable-xaw --enable-ncurses --disable-strict --disable-warnings"
*** Bug 31980 has been marked as a duplicate of this bug. ***
This looks to be a problem with the 2.4.21 system kernel headers, rather than a problem with kdemultimedia per se. Judiciously choosing the simplest program to highlight this: #include <linux/cdrom.h> int main() { } This compiles ok using: # gcc -c test.c # but fails with the same error as reported above when we compile, strictly adhering to ANSI C standards: # gcc -ansi -c test.c In file included from /usr/include/linux/cdrom.h:14, from test.c:1: /usr/include/asm/byteorder.h:38: error: syntax error before "__u64" /usr/include/asm/byteorder.h:38: error: syntax error before "val" /usr/include/asm/byteorder.h: In function `___arch__swab64': /usr/include/asm/byteorder.h:42: error: syntax error before "__u64" /usr/include/asm/byteorder.h: At top level: /usr/include/asm/byteorder.h:44: error: syntax error before '.' token /usr/include/asm/byteorder.h:52: error: syntax error before string constant In file included from /usr/include/linux/byteorder/little_endian.h:11, from /usr/include/asm/byteorder.h:65, from /usr/include/linux/cdrom.h:14, from test.c:1: /usr/include/linux/byteorder/swab.h:199: error: syntax error before "__fswab64" /usr/include/linux/byteorder/swab.h:199: error: syntax error before "x" /usr/include/linux/byteorder/swab.h: In function `__fswab64': /usr/include/linux/byteorder/swab.h:206: error: `x' undeclared (first use in this function) /usr/include/linux/byteorder/swab.h:206: error: (Each undeclared identifier is reported only once /usr/include/linux/byteorder/swab.h:206: error: for each function it appears in.) /usr/include/linux/byteorder/swab.h: At top level: /usr/include/linux/byteorder/swab.h:209: error: syntax error before "__swab64p" /usr/include/linux/byteorder/swab.h:209: error: syntax error before '*' token /usr/include/linux/byteorder/swab.h: In function `__swab64p': /usr/include/linux/byteorder/swab.h:211: error: `x' undeclared (first use in this function) /usr/include/linux/byteorder/swab.h: At top level: /usr/include/linux/byteorder/swab.h:213: error: syntax error before '*' token /usr/include/linux/byteorder/swab.h: In function `__swab64s': /usr/include/linux/byteorder/swab.h:215: error: `addr' undeclared (first use in this function) asm/byteorder.h includes asm/types.h which defines __u64 only if __STRICT_ANSI__ is *not* defined: #if defined(__GNUC__) && !defined(__STRICT_ANSI__) typedef __signed__ long long __s64; typedef unsigned long long __u64; #endif Then asm/byteorder.h declares an inline function that uses __u64 regardless of whether __STRICT_ANSI__ has been defined or not: static inline __u64 ___arch__swab64(__u64 val) { ..... }
-- [06:03] <Brandy> `Kumba: bug #32246 contains the gory details [06:03] <GenBot> Brandy: Bug http://bugs.gentoo.org/show_bug.cgi?id=32246 nor, P2, x86, kde@gentoo.org, NEW, sys-devel/gcc-3.3.2-r1 breaking kde-base/kdemultimedia-3.... [06:04] <`Kumba> hmm [06:05] <`Kumba> it's in byteorder.h [06:05] <Azarah> check k3b - its a kde issue that have been fixed in 0.10.1 [06:05] [Azarah] Does this mean you're really back? [06:06] <Brandy> yep, that inline function is new with 2.4.21 and may need to go inside a 'define' block [06:07] <Azarah> `Kumba: ditto what Brandy said, its actually new linux-headers [06:07] <Azarah> you need to take out the -ansi kde adds to CFLAGS [06:07] <Azarah> one fix if same as k3b [06:10] <`Kumba> I'm trying something on a hunch....even I doubt it'll work... [06:11] <Azarah> `Kumba: the problem is actually in /usr/include/asm/types.h [06:11] <Azarah> `Kumba: the '#if defined(__GNUC__) && !defined(__STRICT_ANSI__) [06:12] <Azarah> `Kumba: cause __u64 only gets defined if not -ansi .. [06:17] <Azarah> diff -urpN k3b-0.10/src/core/device/k3bdevice.cpp k3b-0.10.1/src/core/device/k3bdevice .cpp [06:17] <Azarah> --- k3b-0.10/src/core/device/k3bdevice.cpp 2003-09-25 13:34:51.000000000 +0200 [06:17] <Azarah> +++ k3b-0.10.1/src/core/device/k3bdevice.cpp 2003-10-23 10:37:05.000000000 +0200 [06:17] <Azarah> .. [06:17] <Azarah> +#undef __STRICT_ANSI__ [06:17] <Azarah> #include <linux/cdrom.h> [06:17] <Azarah> +#define __STRICT_ANSI__ [06:17] <Azarah> .. [06:17] <Azarah> that ^^ is the k3b fix [06:17] <Azarah> as cdrom.h included byteorder.h -- That is it for k3b - might want to check what rawhide does ... might have a patch.
Martin, someone in http://bugs.gentoo.org/show_bug.cgi?id=31980 pointed to this link:- http://lwn.net/Articles/38384/ hope it will be of interest to you in resolving this issue
Right, might work. We sure that fix do not fix this (I just commented here after issues with k3b, but I do not use kdemultimedia myself ...). KDE devs ?
The patch mentioned in LWN was submitted to the upstream kernel team a while ago. There was quite a bit of heated discussion about it (http://www.ussg.iu.edu/hypermail/linux/kernel/0305.0/index.html#1096). To date the patch has not made its way into any of the 2.4/2.6 kernel headers, which makes me think there may be some issues blocking its inclusion.
*** Bug 32711 has been marked as a duplicate of this bug. ***
I don't think 32711 is a duplicate, since there it is about compiling 3.2.0-beta with gcc 3.2...
The question still stands - do we fix kdemultimedia, or linux-headers ?
*shrug* - both sides seem to think it's the other one's fault.
My question is not really about who is at fault (although if you think that they took the __BYTEORDER_HAS_U64__ and __arch__swab64() of ouf 'defined(__STRICT_ANSI__)', but not the declaration of __u64 in asm/types.h, then its an kernel issue). It is rather this: 1) Should we patch asm/byteorder.h to behave like original, and then forever do this as it do not seem the kernel guys are going to fix it. 2) Should we patch asm/types.h and hope something else do not break (in my opinion the better 'kernel side fix'). 3) Should we patch kdemultimedia, which I guess will eventually anyhow happen due to kernel side outside Gentoo not changing. 4) Should we try to fight the possibly un-winneble fight to get it fixed kernel side ? 5) Should we do both (2) and (4)? Personally I think (5) is the best one, but I am not sure if we will not break anything else with (2), so it might need testing with a temp (3) kludge. And as I did point out, (4) might never happen :/ Comments ?
I like #5 too.
It would be nice if we could fix the kernel headers, but I'm not sure whether that would taint or do Something Bad <tm> to them. I see no reason it should do that, though. Also, patching kernel headers should be easier than patching a Z-amount of applications which need this fix and when it gets intergrated by the upstream folks, I see no reason why we then [when this [if ever] gets intergrated] can't just bump linux-headers and continue... The problem with patching the app sources is that when Something Drastic <tm> happens with the kernel headers such as this getting fixed, there may be potential problems and it would be a pain to unpatch every application which uses this. <asm/types.h> should be the better remedy and I see no reason why it should cause borkage. __u64 is used a lot because people are really not willing to use 'unsigned long long' that much, so it should help things. I hope this won't break standards conformance with non-ANSI things though. The C code should be fine, as long as you do an #ifndef ANSI_C___U64 ... #define ... #define ANSI_C___U64 ... #endif just incase of redefinitions somewhere.
What have other distros done? Check Debian's source debs and RH's srpms to see what they did to get around this issue (if they encountered it), and follow their behavior might be an option.
Ideally, one should fix the linux headers. But, the problem is that it is not in our power to do so, so we ought to leave that to the kernel.org folks. Maybe a reminder to them about this problem will prompt them to do so. An interim solution, would be to disable "-ansi -pedentic" CFALGS for any of the affected ebuilds??
having read the thread: http://www.ussg.iu.edu/hypermail/linux/kernel/0305.0/index.html#1096 looks like one of those "self apointed high priests screwing things up" well the era of "high priests(is that how it's spelled?) is long gone so I wouldn't hesitate in giving them an attitude adjustment spell :-) and for better results, one has to be diplomatic. HTH
I stirred things up again, so lets wait and see.
*** Bug 32909 has been marked as a duplicate of this bug. ***
I believe this bug lies firmly within kernel headers. You can't put a conditional define on a type definition then use it without the same conditions elsewhere (asm/byteorder.h and linux/byteorder/swab.h) It's probably not strict ansi to include __u64, I'm fine with that. so lets just make all the dependent functions of __u64 bound by the same condition. I've done that and kde-base and multimedia are happy now.
Created attachment 20499 [details, diff] asm-types_h-extension.patch This should be the more correct way to do it.
Ok, David S. Miller seems to think its ok - will send it on to Marcelo. If somebody do not beat me to it, we can add it to linux-headers.
I fixed this, it's in portage in linux-headers-2.4.21-r1, and the patch will only apply for x86 systems (since it only affects asm-i386)
I saw, somebody also fixed this for linux-headers-2.4.22 (which I am using since last night; compiled glibc and afterwards my whole system new, of course), but the compilation of kdemultimedia still fails with the same error. I use gcc-3.3.2-r2. I checked, that the linux-headers-strict-ansi-fix.patch actually found its way into my /usr/include/asm/types.h: bash-2.05b# grep -A 8 GNUC /usr/include/asm/types.h #ifndef __GNUC__ # ifndef __extension__ # define __extension__ # endif #endif __extension__ typedef __signed__ long long __s64; __extension__ typedef unsigned long long __u64; So I don't understand why the compilation of kdemultimedia-3.1.4-r1 still doesn't work. The slightly different than already reported error is: /bin/sh ../../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/kde/3.1/include -I/usr/qt/3/include -I/usr/X11R6/include -DQT_THREAD_SUPPORT -D_REENTRANT -ansi -W -Wall -pedantic -Wshadow -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -DNDEBUG -O2 -march=pentium3 -O2 -pipe -c -o plat_linux.lo `test -f 'plat_linux.c' || echo './'`plat_linux.c rm: cannot remove `': Invalid argument In file included from /usr/include/linux/cdrom.h:14, from plat_linux.c:65: /usr/include/asm/byteorder.h:38: error: syntax error before "__u64" /usr/include/asm/byteorder.h: In function `___arch__swab64': /usr/include/asm/byteorder.h:52: error: syntax error before ':' token Portage 2.0.49-r15 (default-x86-1.4, gcc-3.3.2, glibc-2.3.2-r9, 2.4.21) ================================================================= System uname: 2.4.21 i686 Pentium III (Coppermine) Gentoo Base System version 1.4.3.12 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=pentium3 -O3 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=pentium3 -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="sandbox ccache autoaddcvs" GENTOO_MIRRORS="http://ftp.uni-erlangen.de/pub/mirrors/gentoo http://ftp.tu-clausthal.de/pub/linux/gentoo http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror http://mirrors.sec.informatik.tu-darmstadt.de/gentoo http://www.fhh.opensource-mirror.de/gentoo.org http://www.mirror.ac.uk/sites/www.ibiblio.org/gentoo/ http://gentoo.oregonstate.edu/ http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/overlay" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="x86 oss apm avi crypt cups encode foomaticdb gif jpeg gnome libg++ mad mikmod mpeg ncurses nls pdflib png quicktime spell truetype xml2 xmms xv zlib gdbm berkdb slang readline arts bonobo svga ggi tcltk java guile ruby X sdl gpm tcpd pam libwww ssl perl python esd imlib oggvorbis gtk qt kde motif opengl gphoto2 ldap acpi cdr dga directfb doc fbcon -gtk2 icc imap libgda maildir mozilla mysql postgres samba scanner sse tetex usb vim-3dnow video_cards_matrox" Side note #1: I'am still using kernel 2.4.21 as my 2.4.22 mysteriously hangs on detecting my SB AWE64 (will sort this out separately) Side note #2: Why is linux-headers-2.4.21-r1 preferred over linux-headers-2.4.22? They are all "SLOT 0" and nothing is marked in package.mask bash-2.05b# pkglist |grep header sys-kernel/linux-headers-2.4.22 bash-2.05b# emerge -up system|grep header _but_: bash-2.05b# emerge -eup system|grep header [ebuild N ] sys-kernel/linux-headers-2.4.21-r1 Why and where is this last line caused, despite already using headers v 2.4.22 _and_ glibc and whole system compiled with headers 2.4.22? BTW: How do I reopen this bug? Firebird doesn't allow me to uncheck the button "Leave as RESOLVED FIXED".
Siegbert, please forgive me if I am wrong, but, as far as gentoo is concerned, at the time of writing, only linux-headers-2.4.21-r1 contains the strict ansi patch. HTH
@ comment 26 bash-2.05b# grep -A 3 "ansi" linux-headers-2.4.22.ebuild # This patch fixes an issue involving the use of gcc's -ansi flag and the __u64 datatype. # It only patches asm-i386, so we only apply it if x86. Unknown if this is needed for other archs. # Closes Bug #32246 if [ -n "`use x86`" ]; then epatch ${FILESDIR}/${PN}-strict-ansi-fix.patch fi And this worked as my grep of /usr/include/asm/types.h shows.
Siegbert: I'd like to know if you ran into any problems using linux-headers-2.4.22, specifically, are you using iputils-021109, and do the utilities provided by that package appear to work correctly? If so, It may be time to research unmasking 2.4.22 finally, as the previous iputils didn't work well with 2.4.22. As for the ansi oddity, No idea about that. Azarah, any ideas?
Reopening...
This still isn't fixed. 'inline' and 'asm' in byteorder.h aren't playing nice with ANSI C compliance: static inline __u64 ___arch__swab64(__u64 val) { ..... asm("xchgl %0,%1" : "=r" (v.s.a), "=r" (v.s.b) : "0" (v.s.a), "1" (v.s.b)); ..... Both the inline swab23 and swab16 use '__inline__' and '__asm__'
Joshua: I just re-emerged iputils. Ping, arping, tracepath, clockdiff and rdisc seem to work normal at first glance. I don't have the means here to test rarpd, tftpd, ipg or any IPv6 tool. Do you have a detailed failure report, which I could retest? Except kdemultimedia I have completely recompiled my system now without any hickups. Kernel-2.4.23-rc3 is running fine without the soundcard problems I had with 2.4.22. This includes i2c and lm-sensors to control my fans. So linux-headers-2.4.22 seems to be exactly as good for me as 2.4.21-r1. Following the ansi problem, it's not kdemultimedia. I just repeated the test of comment 3 and it still failed: $ cat test.c #include <linux/cdrom.h> int main() { } $ gcc -ansi -c test.c In file included from /usr/include/linux/cdrom.h:14, from test.c:1: /usr/include/asm/byteorder.h:38: error: syntax error before "__u64" /usr/include/asm/byteorder.h: In function `___arch__swab64': /usr/include/asm/byteorder.h:52: error: syntax error before ':' token $ gcc -c test.c $ At the moment I'm compiling kdemultimedia with the configure additions "--disable-strict --disable-warnings" in myconf as suggested in this thread. I will report on this later on, but don't expect any problems.
Just to confirm, kdemultimedia built fine and works as expected with the added myconf options. Maybe we should convince the kde maintainers to add this until the linux-headers are sorted out? Would reduce the annoyance of many people running into this, I guess. This at least worked for two different people with two different linux-headers. Simply change in kdemultimedia-3.1.4-r1.ebuild -- myconf="$myconf --enable-xaw --enable-ncurses" ++ myconf="$myconf --enable-xaw --enable-ncurses --disable-strict --disable-warnings"
--disable-strict seems like a better idea. I don't know if Azarah pushed the headers patch upstream to Marcelo or not, but in either case, --disable-strict seems the easiest solution. As for linux-headers-2.4.22/iputils, the older 020927 just flat out did not build against 2.4.22+. Given the package is virtually unmaintained, I wasn't sure if it'd ever get fixed. Atleast now I have a valid report of a complete system rebuild, so I may discuss the unmasking of linux-headers-2.4.22 with other people, see what opinions are.
*** Bug 32725 has been marked as a duplicate of this bug. ***
Somebody change those 'inline's to '__inline__'s and it should be OK. I * really * do not recommend that one disables strict ANSI conformance or removes warnings. They're there for a reason: to make working, portable code which can be debugged and developed easily across a multitude of compilers and architectures. If the problem is with the kernel headers, they need fixing, not the KDE codebase. Turning on warnings [ well, keeping them turned on ] can sometimes help spot catastrophic flaws and possible exploits which need fixing.
Sorry, if this was unclear, but my suggestion to apply for the kde people was not about the kde project members, but the kde gentoo ebuild maintainers. Adding a temporary patch for the gentoo ebuild seems reasonable until the other things get fixed. Then, of course, change the compilation back to strict ansi. Too many people run into this compile problem, to leave the situation unchanged, IMHO.
1. My system; linux-headers-2.4.23 rebuilt glibc & gcc-3.3.2-r3. "emerge info" at end. 2. edit /usr/include/asm/byteorder.h from static inline __u64 ___arch__swab64(__u64 val) to static __inline__ __u64 ___arch__swab64(__u64 val) 3. test.c works 4. kdemnultimedia dosent. New error further along; plat_hpux.c:28: warning: `plat_hpux_id' defined but not used /bin/sh ../../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr /kde/3.1/include -I/usr/qt/3/include -I/usr/X11R6/include -DQT_THREAD_SUPPORT -D_REE NTRANT -ansi -W -Wall -pedantic -Wshadow -Wpointer-arith -Wmissing-prototypes -Wwrite-s trings -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -DNDEBUG -O2 -march=athlon-xp -fomit-frame-poi nter -Os -falign-jumps=4 -falign-functions=4 -pipe -c -o plat_irix.lo `test -f 'plat_ir ix.c' || echo './'`plat_irix.c plat_irix.c:34: warning: `plat_irix_id' defined but not used /bin/sh ../../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr /kde/3.1/include -I/usr/qt/3/include -I/usr/X11R6/include -DQT_THREAD_SUPPORT -D_REE NTRANT -ansi -W -Wall -pedantic -Wshadow -Wpointer-arith -Wmissing-prototypes -Wwrite-s trings -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -DNDEBUG -O2 -march=athlon-xp -fomit-frame-poi nter -Os -falign-jumps=4 -falign-functions=4 -pipe -c -o plat_linux.lo `test -f 'plat_l inux.c' || echo './'`plat_linux.c In file included from /usr/include/linux/cdrom.h:14, from plat_linux.c:65: /usr/include/asm/byteorder.h: In function `___arch__swab64': /usr/include/asm/byteorder.h:52: error: syntax error before ':' token In file included from plat_linux.c:70: include/wm_cdrom.h: At top level: include/wm_cdrom.h:63: warning: declaration of `index' shadows a global declaration /usr/include/string.h:267: warning: shadowed declaration is here plat_linux.c:112: warning: no previous prototype for `gen_init' plat_linux.c: In function `gen_init': plat_linux.c:111: warning: unused parameter `d' plat_linux.c: In function `wmcd_open': plat_linux.c:128: warning: assignment discards qualifiers from pointer target type plat_linux.c:123: warning: unused variable `warned' plat_linux.c: In function `wmcd_reopen': plat_linux.c:184: warning: passing arg 2 of `wm_lib_message' discards qualifiers from po inter target type plat_linux.c:187: warning: passing arg 2 of `wm_lib_message' discards qualifiers from po inter target type plat_linux.c:192: warning: passing arg 2 of `wm_lib_message' discards qualifiers from po inter target type plat_linux.c: In function `wm_scsi': plat_linux.c:258: warning: passing arg 2 of `wm_lib_message' discards qualifiers from po inter target type plat_linux.c:264: warning: passing arg 2 of `wm_lib_message' discards qualifiers from po inter target type plat_linux.c:256: warning: unused variable `ret' plat_linux.c: At top level: plat_linux.c:337: warning: declaration of `index' shadows a global declaration /usr/include/string.h:267: warning: shadowed declaration is here plat_linux.c:338: warning: no previous prototype for `gen_get_drive_status' plat_linux.c:425: warning: no previous prototype for `gen_get_trackcount' plat_linux.c:440: warning: no previous prototype for `gen_get_trackinfo' plat_linux.c:462: warning: no previous prototype for `gen_get_cdlen' plat_linux.c:474: warning: no previous prototype for `gen_play' plat_linux.c:512: warning: no previous prototype for `gen_pause' plat_linux.c:521: warning: no previous prototype for `gen_resume' plat_linux.c:530: warning: no previous prototype for `gen_stop' plat_linux.c:540: warning: no previous prototype for `gen_eject' plat_linux.c: In function `gen_eject': plat_linux.c:549: warning: passing arg 2 of `wm_lib_message' discards qualifiers from po inter target type plat_linux.c:553: warning: passing arg 2 of `wm_lib_message' discards qualifiers from po inter target type plat_linux.c:575: warning: passing arg 2 of `wm_lib_message' discards qualifiers from po inter target type plat_linux.c:582: warning: passing arg 2 of `wm_lib_message' discards qualifiers from po inter target type plat_linux.c:594: warning: passing arg 2 of `wm_lib_message' discards qualifiers from po inter target type plat_linux.c: At top level: plat_linux.c:627: warning: no previous prototype for `gen_closetray' plat_linux.c: In function `gen_closetray': plat_linux.c:630: warning: passing arg 2 of `wm_lib_message' discards qualifiers from po inter target type plat_linux.c: At top level: plat_linux.c:675: warning: no previous prototype for `gen_set_volume' plat_linux.c:700: warning: no previous prototype for `gen_get_cdtext' plat_linux.c: In function `gen_get_cdtext': plat_linux.c:701: warning: implicit declaration of function `wm_scsi_get_cdtext' plat_linux.c: At top level: plat_linux.c:710: warning: no previous prototype for `gen_get_volume' plat_linux.c: In function `gen_get_volume': plat_linux.c:709: warning: unused parameter `d' plat_linux.c: At top level: plat_linux.c:28: warning: `plat_linux_id' defined but not used make[3]: *** [plat_linux.lo] Error 1 make[3]: Leaving directory `/home/tmp/portage/kdemultimedia-3.1.4-r1/work/kdemultimedia- 3.1.4/kscd/libwm' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/tmp/portage/kdemultimedia-3.1.4-r1/work/kdemultimedia- 3.1.4/kscd' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/tmp/portage/kdemultimedia-3.1.4-r1/work/kdemultimedia- 3.1.4' make: *** [all] Error 2 !!! ERROR: kde-base/kdemultimedia-3.1.4-r1 failed. !!! Function kde_src_compile, Line 137, Exitcode 2 !!! died running emake, kde_src_compile:make 4. "emerge info" system is 99% "~x86" Portage 2.0.49-r18 (default-x86-1.4, gcc-3.3.2, glibc-2.3.2-r9, 2.6.0-test9-mm1) ================================================================= System uname: 2.6.0-test9-mm1 i686 AMD Athlon(tm) XP 2000+ Gentoo Base System version 1.4.3.12 distcc 2.11.2 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [enabled] ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -fomit-frame-pointer -Os -falign-jumps=4 -falign-functions=4 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=athlon-xp -fomit-frame-pointer -Os -falign-jumps=4 -falign-functions=4 -pipe" DISTDIR="/home/portage/distfiles" FEATURES="autoaddcvs buildpkg ccache sandbox userpriv" GENTOO_MIRRORS="ftp://ftp.ucsb.edu/pub/mirrors/linux/gentoo http://gentoo.orgenstate.edu/ ftp://mirror.iawnet.sandia.gov/pub/gentoo/" MAKEOPTS="-j4 " PKGDIR="/home/portage/packages" PORTAGE_TMPDIR="/home/tmp" PORTDIR="/home/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnowext X alsa apm arts avi berkdb bonobo cdr crypt cups encode esd foomaticdb gdbm gif gnome gpm gtk gtk2 gvim hpijs imlib java jpeg kde libg++ libwww mad mikmod mmxext motif mozilla mpeg ncurses oggvorbis opengl oss pam pdflib perl png python qt quicktime readline ruby samba sdl slang snmp spell sse ssl svga tcltk tcpd truetype x86 xml2 xmms xv zlib"
Ah, yes. Can you change :- Line 46: "asm" => "__asm__" Line 52: "asm" => "__asm__" And then "static __inline__" should work fine. This should be the patch we commit in: "inline" goes to "__inline__" and the two "asm"'s in that function go to "__asm__"'s.
I goofed gcc -c test.c worked but gcc -ansi test.c didnt. Got plasmaroo's Comment 38 now gcc -ansi test.c works. will try kdemultimedeia again.
Ok changeing /usr/include/asm/byteorder.h to " static __inline__ __u64 ___arch__swab64(__u64 val) { union { struct { __u32 a,b; } s; __u64 u; } v; v.u = val; #ifdef CONFIG_X86_BSWAP __asm__("bswapl %0 ; bswapl %1 ; xchgl %0,%1" : "=r" (v.s.a), "=r" (v.s.b) : "0" (v.s.a), "1" (v.s.b)); #else v.s.a = ___arch__swab32(v.s.a); v.s.b = ___arch__swab32(v.s.b); __asm__("xchgl %0,%1" : "=r" (v.s.a), "=r" (v.s.b) : "0" (v.s.a), "1" (v.s.b)); " allows "gcc -ansi -c test.c" to work and kdemultimedia to emerge.
Bug 34277 is a varition to this bug. I got the same error after changing "inline" to __inline__ , see my comment 37.
*** Bug 34277 has been marked as a duplicate of this bug. ***
*** Bug 35080 has been marked as a duplicate of this bug. ***
I manually applied these __ "fixes" to the 2.4.23 headers now, the test.c compiles fine with -ansi flag, and kdemultimedia-3.1.4-r1 emerged fine. Thanks for all the hints so far. It seems that this inline- to- __inline__ and asm- to- __asm__ conversion solves some of the problems, but I am far too noob-ish talking of kernel header code to make any serious guess on whether that could be a considerable patch. Just by the way this problem is created I felt like this definitely is a kernel-headers problem right from the beginning, with all these single-sided condition checks etc... I'm really disappointed by the way the kernel devs handle this situation.
Created attachment 21757 [details, diff] sys-kernel/linux-headers/files/linux-headers-strict-ansi-fix.patch
Can somebody replace the "linux-headers-strict-ansi-fix.patch" they have in their portage tree to the one I've attached to this bug, run "ebuild /usr/portage/sys-kernel/linux-headers/# ebuild goes here # digest" and then merge their linux-headers and confirm that this works? Thanks a lot.
plasmaroo, I hereby confirm that your "linux-headers-strict-ansi-fix.patch" works fine. Just compiled kdemultimedia-3.2.0_beta2, no ansi-strict problem anymore. There was no need to do a digest, as patches have do not require digests in portage. Many thanks. BTW when will the patch be integrated in portage?
Confirmed plasmaroo, this fixed kdemultimedia-1.3.4-r1 for me. Some warnings are still emitted around plat_linux.c, but the compile moves on.
Fixed and in portage, thanks to everybody involved. Just 'emerge sync' and re-merge your headers!
Will the recompilation of the headers force the users to also recompile glibc and their whole systems? Or are the changes compatible for glibc and linux-headers?
In this case, glibc will not have any trouble unless your new kernel headers implement something new -- here, they don't; they just restructure code. Glibc will run fine even if headers with newer features are introduced: however, in that scenario, glibc will not support features which the new headers might provide unless you recompile.
