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.
On Tue, Oct 11, 2011, Wookey wrote: 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 x86_64- linux-gnu/ libattr. so: file not recognized: File format not recognized
> 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-
> /usr/lib/
(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 gnueabi- gcc should have a x86_86 library directory in its
seems to come from spec files, which is weird: I don't think
arm-linux-
library search path, that seems like an Ubuntu gcc-4.x bug.
--
Loïc Minier