Apparently the inline assembly code does not like the -fPIC option. Perhapse users need to be saved from that option for this ebuild. Getting rid of -fPIC lets it build without a problem. On my machine it blocked emerge -u world from completion, it was being installed new as a dependency of something else. gcc output follows: 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 -march=pentium3 -O3 -pipe -fomit-frame-pointer -fPIC -I/usr/include/python2.2 -I/var/tmp/portage/libcap-1.10-r1/work/libcap-1.10/libcap/include -c cap_sys.c -o cap_sys.o In file included from cap_sys.c:10: libcap.h:57:3: warning: suggest hiding #error from traditional C with an indented # libcap.h:58:3: warning: suggest hiding #error from traditional C with an indented # libcap.h:101:25: warning: ISO C does not permit named variadic macros cap_sys.c: In function `capget': cap_sys.c:16: can't find a register in class `BREG' while reloading `asm' distcc[904] ERROR: compile on localhost failed with exit code 1 make[1]: *** [cap_sys.o] Error 1 make[1]: Leaving directory `/var/tmp/portage/libcap-1.10-r1/work/libcap-1.10/libcap' make: *** [all] Error 2 !!! ERROR: sys-libs/libcap-1.10-r1 failed. !!! Function src_compile, Line 42, Exitcode 2 !!! (no error message)
sorry. Summary was wrong, it is libcap, not libpcap.
I have patched libcap so compiling with -fPIC now works fine. Have enabled -fPIC on all archs so prelink will work. see ebuild libcap-1.10-r2.ebuild
I thought the consensus in other bugs was that -fPIC in CFLAGS in NOT officially supported?
Adding -fPIC to executables is certainly not suported. But to properly / corectly compile shared libraries you need to have -fPIC in the compiler options for each compiled object whichgoes into the library. libcap.so is a shared library and thus should have -fPIC in the CFALGS for each compiled object which goes into it.
(Oops, small mistake while copy-n-pasting; shouldn't be doing this this late at night...) What I was going to say in comment #3 is, passing -fPIC as part of CFLAGS to the toplevel makefile will pass it to all makefiles, including the one in progs. Since there are so many bug reports about programs failing to compile/run with this flag (which indeed is counter-produtive when used to compile object code that is not used in shared libs, even if it appears to work), I was going to suggest to add -fPIC only to the makefile in the library subdirectory. Adding it to progs too will basically have the same effect as putting it in global CFLAGS for this particular package. (Sorry about the confusion)
Ok, I admit I was being a bit lazy not fixing it properly. I have updated it now to do it the right way. Thanks for proding me!
