Re: Non i386 ports.
> I was wondering if it would be possible and worth to have a m68k
> cross-compiler installed and building binary packages for several
> architectures at the same time.
I do that already for most of my packages (i.e., compiling for both,
i386 and m68k). I have a 68k machine, too, but usually compile on the
i386 because it's much, much faster... :-)
Cross-compiling basically this works fine, but there are some points
that could be improved:
- Cross-compiling is usually done by overriding make variables with
environment variables, e.g.:
setenv ARCH m68k
setenv CC m68k-linux-gcc
setenv GCC m68k-linux-gcc
setenv LD m68k-linux-ld
setenv AR m68k-linux-ar
setenv MAKEFLAGS -e
(The latter is necessary so that the environment overrides Makefile
variables also in subordinate Makefiles; setting CC is needed to
change the arch printed by dpkg --print-architecture.) This is a
bit lengthy to type, and you also have to know which variables are
actually used by the Makefiles of the package you're going to build
(e.g., amd also uses $(SYSCC)).
It would be easier to let debian/rules make those settings, because
this file "knows" its package best. The most comfortable way to go
I can think of now would be
setenv ARCH m68k
dpkg-buildpackage ...
But then every debian/rules file would have to test whether $ARCH
(from the environment) is different from the current arch, and act
accordingly. But this would mean to modify every debian/rules for
this (even though most new parts are pretty the same for each
package).
- debmake's build doesn't pass these environment variables, so it
can't be used with cross-compiling. Just a little inconvenience...
- You need a multi-arch 'strip' for install/strip to work (without
arch-related changes...). But most binutils (except as and ar) can
be built with support for a list of architectures, so this is no
big problem (only recompiling binutils).
- Biggest problem: dpkg-shlibdeps doesn't work, because ldd fails on
non-native binaries :-(
I currently solve this by manually modifying the debian/substvars,
left over by a previous native build. (Most times, there are no
changes).
Don't know how to solve this cleanly... :-( A kludge could be to
first run strings on the binary to get the libraries to be linked,
like (untested!):
strings -a xxx | perl -n -e 'print if /^lib\S+.so.\d+$/;'
Then look --based on those names-- in the cross lib dir
(/usr/local/lib/m68k-linux/lib on my system) for the actual library
versions. And, you'd have to have different shlibs files for every
architecture... All not every satisfying :-((
- A smaller problem again: A native build will generate a
PACKAGE_VERSION_i386.changes file, a cross build afterwards
PACKAGE_VERSION_m68k.changes. For uploading, I first have to merge
them and re-sign. A comfortable dpkg-genchanges could notice the
existance of the first *.changes file, sees that it's for the same
package but another architecture, and then adds the new file(s)
*_m68k.deb to this and renames it to
PACKAGE_VERSION_i386+m68k.changes or something like that.
> I think the bigger problem with this is that the developper will
> not be able to test binary packages for other architectures than his
> developping platform, but it could be arranged by marking this
> binary package as 'unstested' in the .changes file. dinstall would
> not install them automatically, but move them into
> Incoming/untested-m68k. That way, people who are currently
> recompiling everything for their architecture will just need to test
> those packages and "validate them".
Good idea. And then let somebody send an OK mail to move them up from
untested.
Roman
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: