Bugzilla Bug 29958

Emerging of libcap fails. 

Reproducible: Always
Steps to Reproduce:
1. emerge -U libcap 
2. 
3. 
Actual Results:  
cap_sys.c:16: error: can't find a register in class `BREG' while reloading 
`asm' 
cap_sys.c: In function `capset': 
cap_sys.c:20: warning: traditional C rejects ISO C style function definitions 
make[1]: *** [cap_sys.o] Error 1 
make[1]: Leaving directory `/var/tmp/portage/libcap-1.10/work/libcap-1.10/
libcap                                                                                                   
' 
make: *** [all] Error 2 
 
!!! ERROR: sys-libs/libcap-1.10 failed. 
!!! Function src_compile, Line 43, Exitcode 2 
!!! (no error message) 

Expected Results:  
Clean install. 

Portage 2.0.49-r3 (default-x86-1.4, gcc-3.3.1, glibc-2.3.2-r1, 
2.4.20-gentoo-r7) 
================================================================= 
System uname: 2.4.20-gentoo-r7 i686 AMD Athlon(tm) XP 2500+ 
ACCEPT_KEYWORDS="x86" 
AUTOCLEAN="yes" 
CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer -fPIC" 
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 /opt/tomcat/conf /usr/kde/3.2/share/
config /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=athlon-xp -O3 -pipe -fomit-frame-pointer -fPIC" 
DISTDIR="/usr/portage/distfiles" 
FEATURES="sandbox ccache autoaddcvs" 
GENTOO_MIRRORS="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="" 
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" 
USE="oss apm encode foomaticdb libg++ mad mikmod ncurses nls quicktime spell 
xv gtkhtml gdbm berkdb slang readline tetex bonobo svga tcltk guile sdl gpm 
tcpd pam libwww ssl perl esd imlib motif opengl cdr scanner acpi alsa arts avi 
crypt cups dga doc emacs ethereal gif -gnome gphoto2 -gtk java jpeg kde mmx 
mpeg oggvorbis pdflib png python qt ruby sip tiff truetype usb X xml xml2 xmms 
zlib x86"

Created an attachment (id=18508) [details]
Full log

Yeah.. thats a tricky one really. all .so should be able to be compiled with
-fPIC, you will also notice this same exact thing happen on proftpd in sys_cap.c


The simple solution is to add
----------------------
inherit flag-o-matic
filter-flags -fPIC
----------------------
to the ebuild.

Ulrich Drepper <drepper@redhat.com> has written an interesting read on How
to Write Shared Libraries archived at http://linbsd.net/~solar/ukuug2002slides.pdf
which explain some techniques on coding -fPIC aware code.

-fPIC basicly reserves the EBX register to resolve text relocations.

This can eaisly be seen in this example
gcc -o ebx.c ebx ; should compile fine
gcc -o ebx.c ebx -fPIC ; will fail with standard BREG error

int main(int argc, char **argv) {
   int i = 0;
   __asm__ __volatile__("addl $1,%%ebx\n\t"::"b"(i));
   return i;
}

fpic is now filtered in latest stable while latest unstable utilizes the
debian patch to properly support PIC

Confirmed libcap with -fPIC works on x86 compile & runtime. Thanks so much
for finding that solution it's so desired over filtering. 

Now if we could only get util-linux -2.12 2.11z-r7 with the pic patch bumped
to stable.

> Now if we could only get util-linux -2.12 2.11z-r7 
> with the pic patch bumped to stable.

Will r7 support non-gentoo encryption modules? I'm using a SuSE encryption
module (loop_fish2) and while this is running perfectly under current r6,
I got lots of problems with current *unstable*  util-linux:
"ioctl: LOOP_SET_STATUS : Invalid argument"

Steps to reproduce:
insmod /PATH_TO_SUSE_ENCRYPTION_MODULE/loop_fish2.o
mount /MY_ENCRYPTED_PARTITION

I will supply the source of the module so you can check if it will load with
util-linux -2.12 2.11z-r7.

Created an attachment (id=18522) [details]
Proprietary SuSE loop_fish2 encryption module

Arent, 
perhaps bug #25192 http://bugs.gentoo.org/show_bug.cgi?id=25192 would be
a better place for such things. 
This libcap bug is closed and the chances of it being found by any developer
working with encryption are slim.