libcap2 fails to cross-build
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
libcap2 (Debian) |
Fix Released
|
Unknown
|
|||
libcap2 (Ubuntu) |
Fix Released
|
Undecided
|
Loïc Minier |
Bug Description
libcap2 fails to cross-build:
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/
The actual problem seems to be that xdeb fails to install libattr1-
There is also a bug in this versoin of the package so that attempting to do make clean without pam-modules installed fails. That is the subject of a separate bug.
------------
The build command is:
xdeb --only-explicit -a armel --prefer-apt --apt-source --debug --force-rebuild bash
The actual build command xdeb issues is:
debuild --no-lintian -eUSER -eCONFIG_
To easily reproduce the build environment in which this bug was discovered follow the HOWTO here:
https:/
Related branches
Changed in libcap2 (Ubuntu): | |
status: | New → Fix Committed |
assignee: | nobody → Loïc Minier (lool) |
Changed in libcap2 (Debian): | |
status: | Unknown → New |
Changed in libcap2 (Debian): | |
status: | New → Fix Committed |
Changed in libcap2 (Debian): | |
status: | Fix Committed → Fix Released |
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