Re: DRAFT: Fixing the architecture query options of dpkg.
Hi,
On Mon, Jan 11, 1999 at 03:28:02PM +1100, Martin Mitchell wrote:
> Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
>
> > > At all?? I think that dpkg-cross does a very reasonable job, and I've not
> > > had to use any 'major hacks' to cross compile packages.
> >
> > I am talking about the debian/rules files. There is currently no way to
> > write a good debian/rules files for cross compilation.
>
> It depends very much on the upstream source. Things which use GNU autoconf
> are very easy, small standalone programs are easy, other programs which
> build binaries to build other parts of the package need special support in
> the upstream Makefiles.
I really would have it easier if you were right. Unfortunately, neither bash
nor ncurses were easy, so were ash and sash. Even gcc turned out to be
difficult, and perl is hard, too. All required big changes in the
source, upstream and Debian. Only few packages compiled out of the box, for
example gzip and make. I assume that mostly the basic packages suffer from
this, applications will be easier, but I haven't come this far yet.
> Of the 29 packages I maintain, almost all of them should support dpkg-cross.
> It really isn't that hard to write good debian/rules for cross compilation.
It will be even easier in the future :)
> > I know dpkg-cross, and it does a good job to work around it. Remember it is
> > a _hack_. It's a hack which works quite good, but it is limited due to
> > "broken" debian/rules and upstream Makefiles.
>
> I'd give it more credit than that, it is more elegant than a cheap hack.
I have not said that it is a cheap hack. Please read the jargon file's entry
for hack, especially point 1 and 2. dpkg-cross is both :)
> > * dpkg-cross does only work, if the package in question does not generate
> > binaries to run on the build machine. Some examples:
>
> Yes, but these all would need upstream work to them. It is not the job of
> debian/rules to provide for all these cases.
No, right. The problem exists on both sides.
> > * No prgram I have seen runs "configure --target=something", they all run
> > "configure something", which is not what they mean.
>
> Really?? I thought you had compiled binutils?? For autoconf this is made
> much simpler, agreed. Configure scripts which don't support some kind of
> --target flag need work upstream, it is nothing to do with debian/rules.
I don't remember binutils in particular, I think it was one of the good
packages. It even used the "--build" target. :)
[...]
> Yes, I realize this, and I like your proposal for dpkg-architecture.
Thanks.
> One thing I don't like, you have been mentioning something like this:
>
> dpkg-buildpackage -am68k -target=m68k-linux -B
>
> Why is the same information specified twice, won't you get dpkg-architecture
> to provide the GNU arch string?
You should look at my example script. It does guess the other option if only
one is given. However, sometimes the situation is ambiguous (not currently,
but in the future), for example, when I compile a pentium optimised package,
we _probably_ use i486-linux for both, i386 and i586 distribution. Or, I
could compile a linux package "i386-linux" for the "hurd-i386" tree when we
have binary compatibility (and I want to do something special).
But in general it should be sufficient to specify one.
Thanks,
Marcus
--
"Rhubarb is no Egyptian god." Debian GNU/Linux finger brinkmd@
Marcus Brinkmann http://www.debian.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Reply to: