On Fri, 24 Aug 2007 14:44:01 +0200
Raphael Hertzog <hertzog@debian.org> wrote:
> > The second stage is to replace the dpkg-shlibdeps diversion too. It has
> > to identify the shared dependencies of a foreign binary, then look up
> > the packages that provide those. It needs updating because it is
> > currently somewhere around dpkg-dev 1.10. The standard dpkg method has
> > to be adapted for cross-building because you can't read the binaries
> > normally.
>
> If dpkg-cross can depend on binutils-multiarch, then dpkg-shlibdeps needs
> no modification to be able to read binaries.
I'll look into that. I know there's been a lot of discussion around
multiarch in the past. I'll have to check on the current status.
> Furthermore it's already smart enough to ignore libraries which are
> incompatible (another type reported by objdump -a).
>
> > Alternatively, dpkg-shlibdeps could do the complete job and check the
> > alternative dpkg data itself when in cross-compiling mode.
>
> We could detect that cross-compiling mode simply because the analyzed
> binaries do not match the host binaries.
Is it possible to use a more routine method of checking the values
returned by dpkg-architecture?
(e.g. in makefile syntax)
DEB_HOST_GNU_TYPE=$(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
DEB_BUILD_GNU_TYPE=$(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
(On the basis of the line of least surprise for existing
cross-builders?)
> How is $crossroot supposed to be defined ?
Currently, it is read in from a dpkg-cross configuration file. Any
other method could be arranged. $crossroot isn't that common, yet,
because Emdebian has been working primarily with the rootfs and there
has been only limited opportunity for splitting packages or using
optional dependencies. It is part of why I need to do after these
dpkg-cross changes in order to build an Emdebian distribution based on
GPE and Gtk.
Although I wish to remove the diversions, there is clearly still going
to be a need for dpkg-cross when actually cross-building packages. Even
when building a toolchain or rootfs, libraries need to be processed by
dpkg-cross to make the foreign binary available to the build process
in /usr/${archtriplet}/lib and include/.
There is also a need for the cross-config.$arch files that are
currently part of dpkg-cross. These are cache values read in for
autotools builds that describe the common differences between the build
and host architectures so that ./configure gets sensible values that
actually work on the host, despite what would have been generated
normally on the build arch. These config values are read in
by ./configure using the CONFIG_SITE variable.
> How can we map the elf type to the archtriplet ?
dpkg-cross already has a working perl table to do this. It is
incomplete but has sufficient coverage for the current cross-building
requirements. (%archdetecttable in Debian::DpkgCross. See also %
crossprefixtable).
Debian::DpkgCross is still a work-in-migration so the documentation is
quite poor, even if I say so myself. I can't really improve that until
the codebase within the module has had a chance to settle, which in
turn means deciding issues like $crossroot, %archtable etc.
%archtable has recently been remapped to use dpkg-architecture wherever
possible but it does still map some architectures that
dpkg-architecture either does not define or defines differently:
%archtable = (
'armeb' => 'armeb-linux-gnueabi', #XXX This differs from dpkg-architecture
'hurd-i386' => 'i386-gnu', #XXX This differs from dpkg-architecture
's390x' => 's390-linux-gnu', #XXX This differs from dpkg-architecture
'openbsd-i386' => 'i386-openbsd', #XXX This differs from dpkg-architecture
'freebsd-i386' => 'i386-freebsd', #XXX This differs from dpkg-architecture
'darwin-i386' => 'i386-darwin', #XXX This differs from dpkg-architecture
'win32-i386' => 'i386-cygwin'
);
dpkg-architecture values:
armeb => armeb-linux-gnu
hurd-i386 => i486-gnu
s390x => s390x-linux-gnu
openbsd-i386 => i486-openbsd
freebas-i386 => i486-freebsd
darwinbsd-i386 is unknown to dpkg-architecture
win32-i386 is unknown to dpkg-architecture
These remaining issues need to be discussed on debian-embedded. (My
internet connection has become quite brittle in the last few days so
discussion on IRC is difficult. I'll raise these remaining
discrepancies on the mailing list.)
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
Attachment:
pgpIkkCzE_fzF.pgp
Description: PGP signature