Re: dpkg-cross
+++ Nikita V. Youshchenko [04-06-05 09:50 +0400]:
> > +++ Nikita V. Youshchenko [04-06-03 23:02 +0400]:
> I forgot to mention in the previous mail that I never objected against
> providing repository with cros-compiler stuff.
> Just the opposite :). I think a cron script should be running somewhere
> that detects new versions of gcc-*/binutils/glibc/linux-kernel-headers in
> the debian archive, and re-builds cross debs :).
Indeed, that's definately where we want to be headed for (although some
system for preserving particularly 'good' versions (migration to emdebian
'stable' ?) would be good too.
I tried your script here but it died in the binutils build with:
gcc -DHAVE_CONFIG_H -I. -I../../binutils -I. -D_GNU_SOURCE -I. -I../../binutils -I../bfd -I../../binutils/../bfd -I../../binutils/../include -I../../binutils/../intl -I../intl -DLOCALEDIR="\"/usr/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation -W -Wall -Wstrict-prototypes -Wmissing-prototypes -g -O2 -c ../../binutils/ieee.c
gcc -DHAVE_CONFIG_H -I. -I../../binutils -I. -D_GNU_SOURCE -I. -I../../binutils -I../bfd -I../../binutils/../bfd -I../../binutils/../include -I../../binutils/../intl -I../intl -DLOCALEDIR="\"/usr/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation -W -Wall -Wstrict-prototypes -Wmissing-prototypes -g -O2 -c ../../binutils/rdcoff.c
/bin/sh ./libtool --mode=link gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -g -O2 -o objdump objdump.o budemang.o prdbg.o rddbg.o debug.o stabs.o ieee.o rdcoff.o bucomm.o version.o filemode.o ../opcodes/libopcodes.la ../bfd/libbfd.la ../libiberty/libiberty.a -ldl
gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -g -O2 -o objdump objdump.o budemang.o prdbg.o rddbg.o debug.o stabs.o ieee.o rdcoff.o bucomm.o version.o filemode.o ../opcodes/.libs/libopcodes.a -L/usr/src/compilers/arm/binutils/binutils-2.14.90.0.7/builddir-arm-linux/bfd /usr/src/compilers/arm/binutils/binutils-2.14.90.0.7/builddir-arm-linux/bfd/.libs/libbfd.a ../bfd/.libs/libbfd.a ../libiberty/libiberty.a -ldl
bucomm.o(.text+0xa99): In function `make_tempname':
../../binutils/bucomm.c:425: warning: the use of `mktemp' is dangerous, better use `mkstemp'
/bin/sh ../../binutils/../ylwrap "" ../../binutils/arparse.y y.tab.c arparse.c y.tab.h arparse.h -- -d
../../binutils/../ylwrap: line 86: -d: command not found
make[4]: *** [arparse.c] Error 1
make[4]: Leaving directory `/usr/src/compilers/arm/binutils/binutils-2.14.90.0.7/builddir-arm-linux/binutils'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/usr/src/compilers/arm/binutils/binutils-2.14.90.0.7/builddir-arm-linux/binutils'
make[2]: *** [all-recursive-am] Error 2
make[2]: Leaving directory `/usr/src/compilers/arm/binutils/binutils-2.14.90.0.7/builddir-arm-linux/binutils'
make[1]: *** [all-binutils] Error 2
make[1]: Leaving directory `/usr/src/compilers/arm/binutils/binutils-2.14.90.0.7/builddir-arm-linux'
make: *** [build-arm-linux-stamp] Error 2
I haven't checked in detail but it seems ylwrap is passed a command name in
a parameter at line 86 and it is null for some reason.
>
> Unfortunately I've found a bug in dpkg-cross -b, that affects
> linux-kernel-headers at least for arm target. It does not preserve
> symlinks that point to directories containing headers. So asm/arch is not
> there in linux-kernel-headers-arm-cross; this causes problems because
> #include <asm/arch/...> is often used in kernel headers included from user
> space.
> The problem is that this bug can't be fixed within approach how dpkg-cross
> - -b currently works. Currently, dpkg-cross first analyses contents of a
> package by parsing the output of dpkg-dev --sys-tarfile | tar tf -, and
> then extracts only needed files. Symlinks can't be analysed or even
> detected this way.
>
> I'm currently in process of re-implementing dpkg-cross -b procedure, such
> that it first completely unpacks a package to a temporary directory, then
> analyses the resulting directory tree and creates the tree for the
> destination package. I've already found that things can be done much
> cleaner this way. I expect this work to be finished in a day or two
> (currently it's about 50% complete).
> Probably both upload of new dpkg-cross to debian and any announces of
> cross-debs repository should be delayed until this is ready.
OK, and I've found a problem with stag-addons 1.1.1: my fix for making it
neatly replace the necessary scripts from dpkg-dev breaks (unless
stag-addons contains no scripts also diverted by dpkg-cross) because by
saying 'replaces dpkg-dev', the diverted dpkg-shlibdeps.orig gets replaced
by the the stag-addons version, not the newer dpkg-cross version
(/usr/bin/dpkg-shlibdeps), which is what we want to replace. See my other
message about emdebian path-name changes in dpkg-shlibdeps, explaining why I
think we still need to replace this (but would like to be proved wrong).
Once there is no need to replace this dpkg-cross diverted script then I
think this problem goes away.
It's remarkably involved to get this all right.
Wookey
--
Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679
work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
Reply to: