[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dpkg-buildflags and cross-building

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

Reply to: