On Thu, 23 Aug 2007 21:21:57 +0100
Neil Williams <codehelp@debian.org> wrote:
> On Thu, 23 Aug 2007 05:52:01 +0300
> Guillem Jover <guillem@debian.org> wrote:
>
> > > So far, pre1 is largely complete for dpkg-cross and the
> > > dpkg-buildpackage diversion, barring an unknown number of possible
> > > corner cases.
> >
> > I don't think those diversions are a good solution...
>
> TBH, neither do I.
> "I'd like to be able to not need dpkg-shlibdeps in dpkg-cross but if
> the version in dpkg is not ready to be cross-compiler aware, a merge
> with the latest dpkg code is well overdue. Emdebian has a lot to gain
> from a more intelligent dpkg-shlibdeps to help prune the dependency
> tree ever further."
> > I already offered my help on debian-embedded to try to merge dpkg-cross
> > into dpkg-dev, which would be the proper place for that functionallity,
> > instead of forking it.
>
> Thank you.
As a starter, this is the basis of my explanation of how I see things
(as the person currently rewriting dpkg-cross), copied from my
contributions to #debian-dpkg.
I'd like to dump the current diversion of dpkg-buildpackage and
dpkg-shlibdeps from dpkg-cross. I'll try to outline how it may be
possible to migrate the dpkg-buildpackage diversion into dpkg-dev first.
It's mostly PATH and environment changes. dpkg-buildpackage.orig -a
doesn't do a complete job and we (cross-builders) have needed a
diversion for some time as it ensures that -I/usr/include becomes
-I/usr/${archtriplet}/include and converts any calls to gcc into, for
example, arm-linux-gnu-gcc. Similarly for cpp, g++, ranlib etc. This
allows cross-builds to be done on the same system as normal Debian
builds which is essential as many cross-builders are also maintainers
of Debian packages.
Path changes are done by putting ${archtriplet}-gcc into the path
before gcc - PATH is modified to point to a temporary directory
containing symlinks to the 'gccross' script which processes @ARGV and
swaps things around before calling the correct binary with the new
@ARGV. There's a little more to it than that but that's the principle
effect.
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.
Now if the dpkg version can simply provide a list of .so files, the
cross-build tools can ensure that the correct packages are located.
e.g. in situations where Emdebian changes the dependency tree we don't
want data from /var/lib/dpkg/ we need data from
$crossroot/var/lib/dpkg.
Alternatively, dpkg-shlibdeps could do the complete job and check the
alternative dpkg data itself when in cross-compiling mode.
It's tricky because the actual .so objects came from libfoo-arm-cross_
$version_all.deb but we need to create a dependency on libfoo_
$version_arm.deb, whilst on amd64, i386 or powerpc :-)
(libfoo-arm-cross comes from dpkg-cross which takes the upstream libfoo
package for the target architecture (e.g. arm) and prepares an
Architecture:all package that installs the foreign libraries
in /usr/${archtriplet}/lib ..../include etc. so that the cross-compiler
can find them during the build.)
dpkg-shlibdeps should be relatively easy because both the dpkg
version and the dpkg-cross diversion are in perl. dpkg-buildpackage.orig
is shell but I think most of the changes are doable in shell.
There is always a strict relationship between libfoo-arm-cross_
$version_all.deb and libfoo_$version_arm.deb so a simple reg exp in
perl should be sufficient, once the packages are identified. It's just
that libfoo_$version_arm.deb might not be the Debian libfoo_
$version_arm.deb, it might be an Emdebian one with some ./configure
options disabled so dropping some optional dependencies that are
enabled in Debian.
e.g. libqof1 in Debian depends on libgda2-3. In Emdebian, this
dependency is dropped, allowing libqof1 to be installed without libxml2
which is a large gain in total installed size of the dependency chain
for libqof1. (Such changes require pre-existing upstream support
via ./configure.)
It is also likely that cross-built dependencies will be split into
smaller packages (glibc springs to mind) so that the libbar.so that
would be part of libfoo_$version_arm.deb in Debian is actually in
libbar_$version_arm.deb in Emdebian - built from the same source but
split into a new package. In this situation, libfoo-arm-cross_
$version_all.deb will not contain libbar.so, it will be provided by
libbar-arm-cross_$version_all.deb and libbar_$version_arm.deb would not
exist in Debian. Hence the need for $crossroot/var/lib/dpkg/ (or
equivalent) containing data from the Emdebian target cache.
dpkg-cross 2.0.0 is already a new API that breaks all existing code
that used dpkg-cross (<< 2.0.0) so now is the time to make radical
changes to the cross-building support within Debian.
(dpkg-cross 1.99+2.0.0pre1 is in NEW, destined for experimental.)
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
Attachment:
pgpeIAAZ_7PXI.pgp
Description: PGP signature