When building sys-apps/attr on ROOT!=SYSROOT for a final rootfs, it fails with this error: ./configure --prefix=/usr --host=arm-carel-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-gettext --libexecdir=/usr/lib --bindir=/bin --build=i686-pc-linux-gnu checking for arm-carel-linux-gnu-gcc... arm-carel-linux-gnu-gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... yes checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether arm-carel-linux-gnu-gcc accepts -g... yes checking for arm-carel-linux-gnu-gcc option to accept ANSI C... none needed checking for gmake... /usr/bin/gmake checking for glibtool... no checking for libtool... /usr/bin/libtool checking for tar... /bin/tar checking for gzip... /bin/gzip checking for makedepend... /bin/true checking for awk... /bin/awk checking for sed... /bin/sed checking for echo... /bin/echo checking for sort... /bin/sort checking whether ln -s works... yes checking for rpm... no checking for an ANSI C-conforming const... yes checking how to run the C preprocessor... arm-carel-linux-gnu-gcc -E checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for mode_t... yes checking for working alloca.h... yes checking for alloca... yes configure: creating ./config.status config.status: creating include/builddefs config.status: creating include/config.h === include === gmake[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. rm -f attr ln -s . attr === libmisc === gmake[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. /usr/bin/libtool --mode=compile arm-carel-linux-gnu-gcc -O -ggdb -fno-inline -O -ggdb -fno-inline -DNDEBUG -funsigned-char -fno-strict-aliasing -Wall -DVERSION=\"2.4.28\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"attr\" -I./include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -O -ggdb -fno-inline -DNDEBUG -funsigned-char -fno-strict-aliasing -Wall -DVERSION=\"2.4.28\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"attr\" -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -c quote.c libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' gmake[1]: *** [quote.lo] Error 1 make: *** [default] Error 2 the problem is that the libtool used it's the system's one, that is not tailored for the correct CHOST. I've worked this around by emerging libtool in SYSROOT with -O (to avoid it taking up autoconf as runtime dependency, that in turn requires perl, that is not crosscompilable), and then setting LIBTOOL=/usr/arm-carel-linux-gnu/usr/bin/libtool . I think crossdev should consider libtool as an extra stage that might be needed. Another problem is that acl fails to build against libattr even with the libtool hack: === 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 !!! ERROR: sys-apps/acl-2.2.34 failed. Call stack: ebuild.sh, line 1546: Called dyn_compile ebuild.sh, line 937: Called src_compile acl-2.2.34.ebuild, line 42: Called die !!! (no error message) !!! If you need support, post the topmost build error, and the call stack if relevant. I'll try to modify crossdev tonight, and see what happens.
Created attachment 103976 [details, diff] Ebuild patch This patch replace AC_PATH_PROG calls with AC_PATH_TOOL, so that it will use ${CHOST}-libtool if present (see bug #158067), and allows attr to be crosscompiled easily.
I'm going to attach a patch and an ebuild patch that solves the issue for me (I sent the patch upstream, waiting to see what they think of it).
Created attachment 104781 [details, diff] Ebuild patch
Created attachment 104782 [details, diff] attr-2.4.32-libtool.patch
this patch doesn't seem to be applied in the ebuild, cross compiling is still nerfed..
Any word on this? Please please please put it in there, if it will help crosscompiling to work, period. I can't build anything for i686 (on my amd64 host), as everything that tries to be compiled starts at the first step, with attr and the infamous bug: libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' What needs to happen to get this committed ASAP? It's been long enough. :)
*** Bug 191363 has been marked as a duplicate of this bug. ***
for me the patch applied from Diego Pettenò works, thanks for that. But again, problem appears for acl. Isn't it better to put this problem more in general terms? I mean Is there some other bug open?
(In reply to comment #8) > > Isn't it better to put this problem more in general terms? > I mean Is there some other bug open? > See bug 158068 for ACL patch.
attr-2.4.39 should handle this
