On Wed, Nov 21, 2012 at 07:09:34PM +0000, Wookey wrote: > Unfortunately because dpkg-buildflag settings are not arch-specific > this goes wrong when a native (amd64) gcc comes along and is then told to > find it's libraries in /usr/lib/aarch64-linux-gnu: > /bin/bash ../../libtool --tag=CC --mode=link gcc -I../../src/include -Wall -Wshadow -Wpointer-arith -Wwrite-strings > -Wstrict-prototypes -Wl,-Bsymbolic-functions -Wl,-z,relro -L/usr/lib/aarch64-linux-gnu -L/lib/aarch64-linux-gnu > -L/usr/lib -Wl,-rpath-link=/usr/lib/aarch64-linux-gnu:/lib/aarch64-linux-gnu:/usr/lib -o qgen common.o file.o first.o > ql_y.o ql_l.o qgen.o second.o third.o -lfl libtool: link: gcc -I../../src/include -Wall -Wshadow -Wpointer-arith > -Wwrite-strings -Wstrict-prototypes -Wl,-Bsymbolic-functions -Wl,-z -Wl,relro > -Wl,-rpath-link=/usr/lib/aarch64-linux-gnu:/lib/aarch64-linux-gnu:/usr/lib -o qgen common.o file.o first.o ql_y.o > ql_l.o qgen.o second.o third.o -L/usr/lib/aarch64-linux-gnu -L/lib/aarch64-linux-gnu -L/usr/lib -lfl > /usr/bin/ld: skipping incompatible /usr/lib/aarch64-linux-gnu/libfl_pic.a when searching for /usr/lib/aarch64-linux-gnu/libfl_pic.a > /usr/bin/ld: cannot find /usr/lib/aarch64-linux-gnu/libfl_pic.a inside > /usr/bin/ld: skipping incompatible /usr/lib/aarch64-linux-gnu/libc.so when searching for -lc > /usr/bin/ld: skipping incompatible /usr/lib/aarch64-linux-gnu/libc.a when searching for -lc Well, what's wrong with this? These should all be warnings, not errors; the compiler should fall back to searching for these in its own built-in path after skipping the incompatible-arch ones, at which point it should find them successfully. It definitely is a bug in the toolchain that these flags need to be passed at all, and I've not run into any cases where passing them confuses the native toolchain into doing the wrong thing. > So, is there a way to make dpkg-buildflags arch-specific, so they are > picked up for one CC and not another? There definitely isn't at present. If there's a concrete need for them then it's worth discussing how we could standardize this - ideally with other cross-building distros, since as Guillem points out most of the changes would need to happen upstream. But it's definitely unclear to me at this point why this would be needed at all in practice. > Yes I realise that fixing the compiler would be a better fix in this case, > but the concept of varying buildflags between architectures is a useful > one, as especially during bootstrap when cross-compiling is required it is > very likely to be the case the cross-compiler needs so different flags to > the more capable native toolchain. Ideally we should not have to pass *any* flags to the compiler by default as part of a bootstrap. Barring that, ideally we would be bootstrapping using a compiler with characteristics very similar to our native one so that the same flags can be used everywhere. Choice #3, putting effort into a design to allow passing separate flags to the native and cross compilers, is a fairly unpalatable workaround. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature