Bugzilla Bug 158068

Splitting out the second issue of bug #158040 here:

=== getfacl ===
gmake[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent make
rule.
arm-carel-linux-gnu-gcc -O -ggdb -fno-inline -O -ggdb -fno-inline -DNDEBUG
-funsigned-char -fno-strict-aliasing -Wall -DVERSION=\"2.2.34\"
-DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"acl\" -I./include -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64  -O -ggdb -fno-inline -DNDEBUG -funsigned-char
-fno-strict-aliasing -Wall -DVERSION=\"2.2.34\"
-DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"acl\" -I../include -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64    -c -o getfacl.o getfacl.c
arm-carel-linux-gnu-gcc -O -ggdb -fno-inline -O -ggdb -fno-inline -DNDEBUG
-funsigned-char -fno-strict-aliasing -Wall -DVERSION=\"2.2.34\"
-DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"acl\" -I./include -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64  -O -ggdb -fno-inline -DNDEBUG -funsigned-char
-fno-strict-aliasing -Wall -DVERSION=\"2.2.34\"
-DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"acl\" -I../include -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64    -c -o user_group.o user_group.c
/usr/arm-carel-linux-gnu/usr/bin/libtool --mode=link arm-carel-linux-gnu-gcc -o
getfacl    getfacl.o user_group.o   ../libacl/libacl.la /usr/lib/libattr.la
../libmisc/libmisc.la
mkdir .libs
arm-carel-linux-gnu-gcc -o .libs/getfacl getfacl.o user_group.o 
../libacl/.libs/libacl.so -lattr /usr/lib/libattr.so ../libmisc/.libs/libmisc.a
/usr/libexec/gcc/arm-carel-linux-gnu/ld: skipping incompatible /lib/libattr.so
when searching for /lib/libattr.so
/usr/libexec/gcc/arm-carel-linux-gnu/ld: cannot find /lib/libattr.so
collect2: ld returned 1 exit status
gmake[1]: *** [getfacl] Error 1
make: *** [default] Error 2

This is caused by the configure script, that tests for presence of
/usr/lib/libattr.la and use that if found, which a) makes libtool use
pointless, as libtool is supposed to find the library by itself when passing
-lattr and b) disallow to crosscompile as it will involve the library specified
with full path that's obviously incompatible; it's also broken for multilib
systems when building for the ABI that is *not* the one linked in /usr/lib.

The attached patch applies the same libtool fix as per bug #158040 and then
removes the tests for /usr/lib/libattr.la presence entirely. The package builds
fine both native and in cross-compile.

HTH,
Diego

Same as per bug #158040, going to attach the new patches.

Created an attachment (id=104783) [details]
Ebuild patch

Created an attachment (id=104784) [details]
acl-2.2.39-leave-las-to-libtool.patch

Created an attachment (id=104785) [details]
attr-2.4.32-libtool.patch

Is there any point to ignore this bug (and #158040)? or is it just that it's
not a priority?

*** Bug 191363 has been marked as a duplicate of this bug. ***

added to acl-2.2.45