Re: dpkg-cross, dpkg-architecture and arch names
it's interesting to see the dicussion reappear which I started
last year. In that time dpkg-architecture was too inflexible
and I fear that's still the case. Anyway, I'll try to summarize
the problems I encountered.
In the last year I performed an intensive research for some
weeks. I tried a lot of ways to cross compile for the win32
platform. In addition, I talked to many people including this
mailing list and die Debian mingw32 package author.
The (incomplete) result of my research I documented in a Wiki:
Although in the end I was able to produce some Debian packages
for cross compiled libraries, I didn't have the time to clean
them up and to publish them. Maybe I'll do so when I find more
interested w32 cross compiling Debian users.
On Tue, Feb 27, 2007 at 04:29:54AM +0200, Guillem Jover wrote:
> > The default list (on both patched and unpatched versions) includes a
> > lot of arches that make little sense (like bsd-darwin-sh3,
> > kfreebsd-s390) and doesn't include at least one that is useful for
> > cross-building: win32-i386. (for use with mingw32 I think).
Calling it "win32-i386" was my first guess, too. However, looking
deeper at the problem I concluded that the name
is much better. The term "w32" is shorter and it's used very often,
even in dpkg-cross itself (there is a /etc/dpkg-cross/cross-config.w32).
Also, it appears in the name "mingw32".
> When the former system was replaced by the new cputable and ostable,
> the idea was to be able to generate any combination of possible valid
> names that could come up in the future w/o needing to add support for
> those explicitely into dpkg.
As I already stated in the past, this has a problem with different
The generic "i386" may stand for i386, i486, i586, etc.
While "linux-i386" in Debian currently means "i486",
a "w32-i386" should stand for "i586".
Since dpkg-architecture treats the components "w32" and "i386"
separately, the best you can get is:
$ dpkg-architecture -aw32-i386 | grep DEB_HOST_GNU_TYPE
However, what we really need is:
(and no, creating a w32 cross compiler for "i486-mingw32msvc"
doesn't make sense at all)
There are three ways to circumvalent the problem:
1) Fix the dpkg-architecture system. Explicit allowing to use
several CPU variants on the same system would be great.
There are some Debian variants whose binaries are completely
build with i586 optimizations, who would also profit from
getting a standardized name instead of inventing something
like an additional "pentium" line in the cputable.
This has also been discussed in this list. Please look at
the archive before answering to this. The result was (AFAIR)
that dpkg and apt would have to be changed, that it would be
a nice thing in the future, but that there are too few
packages who would profit from that.
2) Append to the cputable:
i586 i586 (i86|pentium)
and use "w32-i586". This would add a new "CPU" for
something that's just a CPU variant. Also, since "i386"
means the whole Intel family, a name like "i586" would be
3) Put into your ~/.dpkg-cross/cross-compile
crossprefix = i586-mingw32msvc-
crossdir = /usr/i586-mingw32msvc
and use "w32-i386". This works well if you cross-compile only
for w32. Before cross compiling for other platforms, you'll
have to remove those lines.
My documentation recommends 3) because I think that "w32-i386"
is the correct name (not "w32-i586" or "w32-pentium"). And because
I wanted to make it as less intrusive into the current system as
> The latter (missing win32), is a matter of adding that to the ostable,
> I can do that, if there's consensus among the win32 porters.
Yes! Please append to /usr/share/dpkg/ostable this line:
w32 mingw32msvc mingw32[^-]*
There are problems with the cputable, but this change to the
ostable is (to my knowledge) a general consensus.
dpkg-cross is already prepared for recognizing w32 binaries
(a patch which I contributed last year). At that time it wasn't
possible to get that additional ostable entry into the dpkg
If this is possible now, by all means, please do so!
> > There are also a load of gnuaebi-linux-foo arches which are clearly
> > bollocks and need removing.
> Given the current implementation which combines the ostable and cputable
> to generate all possible triplets
So I guess that i586-mingw32msvc does not belong to "all possible