Libcap compilation chokes on the /usr/include/asm/bitops.h as supplied with the kernels up to 2.4.21 The inline directoive is not nderstood, and complaints are issued by the gcc compiler, changing all inline instances to __inline__ instances will make the build go through
This is the exact error off my MIPS box, which uses 2.4.21 headers from a CVS snapshot from linux-mips.org. I don't know much about the use of the inline or __inline__ keywords in gcc, nor the difference between them. Perhaps someone can clarify their differance and whether it's safe to change all instances of "inline" to "__inline__"? Calculating dependencies ...done! >>> emerge (1 of 1) sys-libs/libcap-1.10 to / >>> md5 src_uri ;-) libcap-1.10.tar.bz2 >>> Unpacking source... >>> Unpacking libcap-1.10.tar.bz2 to /usr/obj/portage/libcap-1.10/work * Applying libcap-1.10-python.patch... [ ok ] >>> Source unpacked. make -C libcap CC='gcc' CFLAGS='-Dlinux -ansi -D_POSIX_SOURCE -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wtraditional -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -pedantic -O3 -mips3 -mtune=r4400 -mabi=32 -pipe -fomit-frame-pointer -fPIC -I/usr/include/python2.2 -I/usr/obj/portage/libcap-1.10/work/libcap-1.10/libcap/include' LD='ld' LIBS='-L/usr/obj/portage/libcap-1.10/work/libcap-1.10/libcap -lcap' LDFLAGS='-s ' VERSION='1' MINOR='10' LIBDIR='/lib' INCDIR='/usr/include' SBINDIR='/sbin' MANDIR='/usr/man' all make[1]: Entering directory `/usr/obj/portage/libcap-1.10/work/libcap-1.10/libcap' => making cap_names.c from <linux/capability.h> gcc -Dlinux -ansi -D_POSIX_SOURCE -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wtraditional -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -pedantic -O3 -mips3 -mtune=r4400 -mabi=32 -pipe -fomit-frame-pointer -fPIC -I/usr/include/python2.2 -I/usr/obj/portage/libcap-1.10/work/libcap-1.10/libcap/include -s _makenames.c -o _makenames In file included from /usr/include/linux/fs.h:26, from /usr/include/linux/capability.h:17, from _makenames.c:12: /usr/include/asm/bitops.h:585: syntax error before "int" _makenames.c: In function `main': _makenames.c:41: warning: traditional C rejects string concatenation _makenames.c:42: warning: traditional C rejects string concatenation _makenames.c:43: warning: traditional C rejects string concatenation _makenames.c:44: warning: traditional C rejects string concatenation _makenames.c:45: warning: traditional C rejects string concatenation _makenames.c:46: warning: traditional C rejects string concatenation _makenames.c:47: warning: traditional C rejects string concatenation _makenames.c:48: warning: traditional C rejects string concatenation _makenames.c:58: warning: traditional C rejects string concatenation _makenames.c:59: warning: traditional C rejects string concatenation _makenames.c:60: warning: traditional C rejects string concatenation make[1]: *** [_makenames] Error 1 make[1]: Leaving directory `/usr/obj/portage/libcap-1.10/work/libcap-1.10/libcap' make: *** [all] Error 2 !!! ERROR: sys-libs/libcap-1.10 failed. !!! Function src_compile, Line 39, Exitcode 2 !!! (no error message)
In the mentioned bitops.h there are some routines with something like: int inline blah () or void __inline__ blah() The compilation falls over the first for but does accept the second form so there is a commandline option supplied to gcc that makes gss complain about " inline " but not " __inline__ ", I hope this clarifies the issue a bit?
What is the proper fix for it tho?
There are no more complaints when -ansi is left off My guess: -ansi alse means inline should be __inline__ the dropping of -ansi doesn't solve the "warning: traditional C rejects string concatenation" My guess, the defaults for gcc changed ?
dropping of -ansi helps get past the __inline__ problem modification of _cap_debug(f, x...) to _cap_debug(f...) removes a lot of warning messages The cast warnings from esp. libcap_wrap.c seem to be unavoidable. Hope it helps
Ok, -ansi is filtered out now, so this should be fixed.
