Re: How to handle cross compiling source packages?
> Oh. This may be either nothing, or an undocumented potential problem.
> All I can say is that it works fine for me.
>
> Maybe it's the question whether we really *want* to use
> dpkg-architecture. Either it is used more consequently than it is now,
> or it should be avoided much more than it is now. See below.
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). 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.
> > 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 :).
> > > In general, I think that get_tool should always use $crossprefix
> > > if the given $arch is the current DEB_HOST_ARCH. See below.
> >
> > 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.
> get_tool() has the slight disadvantage (or feature :-)) to return
> an absolute path. Thus, the gccross wrappers are not called, but the
> original tools instead.
>
> So the gccross wrappers should exist (and prepended on PATH) before the
> initialization of $makeflags. However, the dpkg-buildpackage wrapper
> calls setup_cross_env() *before* creating the gccross wrappers.
> But this is necessary, because the initialized PATH and a correct
> $crossprefix are needed to create the gccross wrappers.
>
> So you either change it back (which would be really sad), or you use
> just the basename of the tool returned by get_tool. Both solutions
> aren't good. The old way fails when using a tool that is not extra
> rovided by the cross compiling environment. The other way would cause
> the basename to may have a different prefix than $crossprefix, thus
> bypassing gccross.
>
> 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 :).
> > > One adds proper entries to ostable and maybe cputable, or puts
> > > proper values into ~/.dpkg-cross/cross-compile:
> > > crossprefix = i586-mingw32msvc-
> > > crossdir = /usr/i586-mingw32msvc
> >
> > I think that this should be done not at crossprefix/crossdir values,
> > but at level of 'architecture'. It should be possible to define new
> > 'architecture', that will be understood both by [wrapped]
> > dpkg-architecture and dpkg-cross, and definition of it should define
> > prefix, path and likely other things.
>
> Yes, you are perfectly right. But currently, there's some confusion
> between the $crossprefix and the paths returned by get_tool(). I tapped
> into that trap, too. Now I got it. As least I hope so.
>
> > 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.
At least dpkg-shlibdeps thing is being revised to support multiarch. I have
not checked the result however.
Does anyone has energy to prepare patches against dpkg-dev tools?
> 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.
> 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.
> Anyway, I wrote a patch which adds the correct w32-i386 entries to
> %archdetecttable and %crossprefixtable:
>
> patch-dpkgcross-w32-entries.diff
Applied, committed.
Nikita
Reply to: