Hi Stephen,
Stephen Kitt wrote:
> We still need to figure out how to handle the triplet. There are multiple
> goals, from end users’ perspectives, some conflicting:
>
> * provide a Windows cross-compiler with a good selection of libraries, within
> Debian, so that it’s easy to build Windows programs and their installers;
> * provide a Windows cross-compiler which integrates well with
> externally-provided libraries;
> * provide a Windows cross-compiler fulfilling the requirements of other
> Debian packages (this is what got me started down this path: Wine Gecko,
> Wine Mono, Debian installer components, etc.).
Thanks for this breakdown. The first sounds like (partial) architecture
bringup, the second is an additional compatibility goal, and the third
could be achieved using multilib but is simpler with multiarch.
If I label these as (a), (b), and (c), then which of these goals is
important to you? What about others in mingw-w64 and related
projects?
a. provide a Windows cross-development environment useful for building
non-trivial programs and their installers
b. provide a Windows cross-compiler that integrates well with
existing externally provided libraries
c. provide a Windows cross-compiler sufficient to meet the needs of
Debian packages such as wine, mono, and so on
For bringing up a Debian arch, I would expect (a) and (c) to be
important and (b) to not be important at all. On the other hand, I
wouldn't be surprised if some other people have (b) as a goal, and if
it's easy to get for free then we shouldn't forget about it. :)
[...]
> Guillem has explained in previous emails why -w64-mingw32 causes issues in
> Debian.
Yes, and not only Debian: any system that relies on the notion of ABI
will run into the same problems.
> There are other problems with the triplet which haven’t been
> mentioned so far: mainly, that the same triplet is used for different
> compiler configurations which effectively result in different ABIs. For
> 32-bit targets, there’s DW2 v. SJLJ (64-bit only used SEH); for all targets,
> there’s POSIX v. Win32 threads; a more recent development is support for UCRT
> instead of MSVCRT.
Yes.
> I see two main questions to answer:
For architecture bringup, you left out the most important question of
all: what ABI do you want to use for the new architecture?
Given a choice of ABI and how to name it, it's possible to make
progress within Debian without waiting for upstream. We'd want to
keep upstream involved every step of the way and to benefit from their
expertise, but part of the magic of having a single project for an
entire operating system distribution is that in the worst case we
*can* go it alone.
In fact I doubt that would be necessary. Upstream has similar goals.
Picking a triplet without coordinating with upstream would be highly
dangerous unless we stick "debian" in there somewhere (yuck). I only
mention it as a way to avoid forgetting our responsibilities: if we
aren't able to find the right way to serve these users, in the end we
have no one to blame but ourselves.
Thanks,
Jonathan
