Re: How to handle cross compiling source packages?
On Tue, Apr 18, 2006 at 11:16:17AM +0400, Nikita V. Youshchenko wrote:
> I think that archtable appeared at some point to add more architectures
> than dpkg-architecture supports. However, to cross-compile packages for
> architectures we need these architectures to be supported by
> dpkg-architecture anyway. So I think the way to go us remove archtable,
> and make dpkg-architecture to understand additional architectures. Maybe
> by wrapping dpkg-architecture, or by pushing patch to dpkg-architecture
> that will make it to consult external tables (so we could easilly add
> architectures when needed).
dpkg/ostable and dpkg/cputable do have some drawbacks, which need to be
solved.
> Just adding lines to current dpkg-architecture
> tables won't fit IMHO, because to define new architectures for dpkg-cross,
> we have to define more than just architecture name and GNU string.
That's true. However, dpkg-architecture should just consult *other*
tables, not "additional external" tables, shouldn't it?
I'm concerned about making a chaos of dpkg-architecture, maybe creating
more infinite recursion traps, etc.
The whole dpkg-cross should get a design plan, before changing anything
to other tools, such as dpkg-architecture.
dpkg-architecture has one advantage over dpkg-cross, which is a also
disadvantage: It separates CPU and OS type. Currently, it supports
any combination of the existing CPU and OS type without any additional
entries, while the internal tables of dpkg-cross allow just a small
subset of those combinations.
Either cut dpkg-architecture back to the "old" CPU/OS model, which
dpkg-cross uses, or make dpkg-cross use the "new" CPU/OS model of
dpkg-architecture.
While this looks very theoretical, this question is essential, because
it is equivalent to the question whether "i586-mingw32msvc" is
* w32-i386
or
* w32-i586
Do we force all i386 and *-i386 Debian architectures to be "i486",
or is it feasible to map Debian "hurd-i386" to GNU "i486-hurd..."
and "w32-i386" to GNU "i586-mingw32msvc"?
> > > Btw, does dpkg-cross -b preserve *-config files? Not sure...
> >
> > As you tell it ... let's see ...
> > No, currently it doesn't. It seems to me that *-config scripts aren't
> > handled by dpkg-cross at all.
>
> So dpkg-crosst should be fixed to do detect *-config scripts, maybe patch
> them, and to put to /usr/$(DEB_TARGET_GNU_TYPE)/bin/
> Then code that sets up directory for gccross, should symlink existing
> *-config scripts to gccross temporary directory. This will make cross
> build to use those.
>
> Hopely somebody will do this :).
I'd really like to do this, but I'm still not sure how it should be
done. If we put e.g. /usr/i586.../bin/sdl-config on top of the PATH,
a cross compiled program would work, but e.g. a source generator
would maybe not compile because it takes the wrong sdl-config
(/usr/i586.../bin/sdl-config instead of /usr/bin/sdl-config)
This is the general problem that I don't understand: How will
cross compiling an native compiling (e.g. for code generation)
work together? That's the whole point about the "strip" wrapper,
and about the internal dpkg-cross.pl tables.
My other question is: Why should gccross patch the sdl-config
script if it modifies the -L.. and -I.. parameters anyway?
If we don't patch it, it won't matter whether /usr/i5.../bin/sdl-config
is used, or accidently the (eventually also installed) /usr/bin/sdl-config.
Maybe all we need is to tell dpkg-cross to pack /usr/bin/*-config
as well?
(BTW, should it package /usr/bin/*.dll as well? You don't need the
dll file to compile it, and you don't want to run any cross compiled
program, but if you package it, you may want to put the used DLL
files into the package as well)
> > > No it should not. It should check the binary arch, and choose proper
> > > tool.
> >
> > Here is a misunderstanding. Of course you first check the arch, which
> > is then passed as argument $arch to get_tool(). If that $arch is
> > equal to DEB_HOST_ARCH, one should also have a look at $crossprefix.
>
> Maybe. But won't this will break concept of dpkg-cross 'mode'? Or this is
> not needed any longer? Don't know.
Here someone should talk to us who is really using the 'mode'.
> > Arghh ... the only solution that doesn't need a complete redesign of
> > dpkg-cross is to remember the original problem:
> > Do I use $(crossprefix)ranlib or ranlib?
> > Exactly this and nothing else does my patch:
> >
> > patch-dpkgcross-fix-std_tools_2.diff
>
> Ok, committed this to CVS. Maybe not the best thing, but could be done
> fast :).
As the current version in CVS was "broken", this patch was needed
anyway. First make it run, then make it better. :-)
> > > It is important to have these parameters constant for a given
> > > architecture, and not allow to overwrite them for standard
> > > architectures. This makes depending on -arch-cross packages reliable.
> >
> > Okay, so the ideal solution would be to ignore dpkg-architecture, right?
> >
> > Of course, it would be even better to make dpkg-architecture use the
> > tables of dpkg-cross, or to make it more flexible to reflect at least
> > the default values correctly. But this is completely unrealistic, isn't
> > it?
>
> Not sure. If I'm not mistaken, dpkg maintainers seem to have changed
> recently, and now are more open to changes than previously. So it could be
> possible to push cross stuff into dpkg-dev tools, making at least some of
> dpkg-cross wrappers not necessary.
That would be very nice.
> > This isn't the case. For example:
> > * %archtable maps "i386" to "i486-linux-gnu",
> > * `dpkg-architecture -ai386` shows "i486-linux-gnu"
> > * but $crossprefixtable{'i386'}[0] is "i386-linux-gnu-"
> >
> > Why?
>
> Because of historical reasons? Fixed, comitted.
So my next questions: Should we use $crossprefixtable{'i386'}[0]
instead of $archtable{'i386'} ?
> > In addition, the "dpkg-architecture" tables are somewhat too simplified.
> > If I add w32 to dpkg/ostable, "dpkg-architecture -aw32-i386" will always
> > return "i486-...". The only change to make dpkg-architecture use
> > "i586-..." is to add another dpkg/cputype, too, and refer tp w32-i586
> > instead of w32-i386. But as this won't be really a new entry, and will
> > overlap with i386, I really don't like that situation. dpkg-architecture
> > is simply too inflexible, isn't it?
> >
> > Do you have any idea how I should handle this? Is a new dpkg/cputype for
> > i586 really justified?
> >
> > And what about adding w32 to dpkg/ostable? Should it be included in
> > dpkg permanently, or should dpkg-cross bypass dpkg-architecture instead?
>
> My opinion on this is that we should either wrap dpkg-architecture, or
> better push needed changes to dpkg-dev. See above.
This still doesn't solve the main problem: Do we need/want a new CPU
type or do we want w32-i386 map to i586-mingw32msvc.
(currently, dpkg-architecture maps i386 to the GNU CPU type i486, so
"dpkg-architecture -aw32-i386" will always say "i486-mingw32msvc"
instead of "i586-mingw32msvc")
How should this problem be handled in general?
Do we need more Intel CPU types beside i386, or do we need a more
flexible dpkg-architecture?
> > Anyway, I wrote a patch which adds the correct w32-i386 entries to
> > %archdetecttable and %crossprefixtable:
> >
> > patch-dpkgcross-w32-entries.diff
>
> Applied, committed.
These patches currently work only if you set
crossprefix = i586-mingw32msvc-
crossdir = /usr/i586-mingw32msvc
Otherwise, it would take "i486-mingw32msvc", because of the above
mentioned design of dpkg-architecture.
Greets,
Volker
--
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR
Reply to: