Hi! On Tue, 2014-09-09 at 23:28:10 +0200, Stephen Kitt wrote: > On Sat, 30 Aug 2014 15:51:12 +0200, Guillem Jover <guil...@debian.org> wrote: > > But I just noticed that a proper triplet was accepted in the config.git > > repo around 2012 (commit f16804b79ee5a23a9994a1cdc760cd9ba813148a), this > > is what config.sub has to say: > > > > $ /usr/share/misc/config.sub mingw64 > > x86_64-pc-mingw64 > > $ /usr/share/misc/config.sub x86_64-mingw64 > > x86_64-pc-mingw64 > > $ /usr/share/misc/config.sub i686-mingw64 > > i686-pc-mingw64 > > > > So, just one thought, if you are going to end up having to do the work > > that would be required to add support for what amounts to the equivalent > > of a new triplet, you could as well use a proper triplet, like the one > > above? > > That triplet was actually added by the MinGW project, not the MinGW-w64 > project, and is intended for their putative 64-bit support, whenever that > appears;
Oh wow, even more confusion to the already confusing current situation. I assume we cannot expect the mingw-w64 and the mingw64 ports to be ABI compatible? :( > I'll take it up with MinGW-w64 upstream though and see what they make of it. Thanks, that might help. > > In the end it seems to me that as long as the triplet is officially > > supported by config.sub/guess the rest of software should just follow > > suit, which as mentioned before is what needs to be done for each and > > every new architecture anyway. What might be more time consuming is > > hunting down and updating the rest of the affected packages in Debian, > > but given that this has been thought to be a partial architecture from > > the beginning it should not amount to so many packages (in contrast to > > a full fledged architecture, that is). > > I think what will be time-consuming is getting the various required patches > into the various upstream projects; there are very few affected packages in > Debian. Unless you mean we should just go our own way, regardless of what > upstream thinks, and use the mingw64 which is already in config.sub and patch > whatever breaks? Well, not really if that would mean making the situation even worse by conflating what might end up being upstream projects tripping over each other's triplets. (Sorry, this was not clear from the aforementioned commit.) > I'd rather do the work required to get something supported properly in Debian > and by upstream... Sure. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
