Comment 2 for bug 872435

Revision history for this message
Loïc Minier (lool) wrote : Re: [Bug 872435] [NEW] libcap2 fails to cross-build

On Tue, Oct 11, 2011, Wookey wrote:
> Base natty source has no cross support. Adding standard 'set
> cross-build variables' support to this debhelper package makes it try
> to do the right thing, but it tries to link to x86 libraries:
> arm-linux-gnueabi-gcc -Wl,-x -shared -O2 -Dlinux -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -g -L/home/wookey/testing/build/build/xdeb/libcap2/libcap/../libcap -lattr -Wl,-soname,libcap.so.2 -o libcap.so.2.20 cap_alloc.o cap_proc.o cap_extint.o cap_flag.o cap_text.o cap_file.o
> /usr/lib/x86_64-linux-gnu/libattr.so: file not recognized: File format not recognized

 (Just commenting on that part of the report)

 This is a problem that was pretty common, especially before libraries
 were converted to multiarch because many build systems such as libtool
 would add -L/usr/lib early in the search path. It's nice if we can fix
 these build systems, but there's a simpler workaround in having
 binutils configured to support both the host and the build
 architectures. Actually, I thought this was explicitly the case in our
 cross-toolchains for a long time, but I guess that's a recent
 regression? Seems like an Ubuntu binutils bug to me.

 Now in your case the /usr/lib/x86_64-linux-gnu/ library search path
 seems to come from spec files, which is weird: I don't think
 arm-linux-gnueabi-gcc should have a x86_86 library directory in its
 library search path, that seems like an Ubuntu gcc-4.x bug.

--
Loïc Minier