This is the mail archive of the
mailing list for the Cygwin project.
Re: Which is it -pc- or -unknown-
On 10/20/2017 2:34 PM, Eric Blake wrote:
> On 10/20/2017 11:11 AM, cyg Simple wrote:
> I may regret joining this thread, but here goes.
But thanks for doing so anyway.
>>> Your assumption is that the default and chosen triplets must/should be
>>> one and the same.
>> No, I assume no such thing.
>>> They are not, they need not be, and we are far from
>>> being alone in this regard. Once you accept *that*, then the rest of
>>> this will make sense. Further insistence that they should be is
>>> counter-productive at this point.
>> You still skirt a reasoning for it to be so. They don't need to be but
>> why aren't they?
> Because Cygwin is not the only platform where there is this discrepancy.
But only very few. Even Linux on x86_64 has a guess of vendor -pc-.
> Having a different guess from the chosen triplet is nothing unique to
> Cygwin, and therefore, downstream Cygwin need not make any effort to
> change things. Our reasoning for them to be different can thus be
> termed "inertia", if you'd like. But it's not a bug, because it doesn't
> break correct usage, and therefore it does not urgently need to be
> changed, certainly not with a downstream-only patch.
I have backed off of the idea of downstream changes ever since Yaakov
stated that the chosen vendor is -pc- for the packages. Yes, I was
under the impression that the default and chosen should match but I
corrected my thinking on that.
>> You've failed to answer the question by assuming I
>> need to be educated on how it is and refusing to give me a reason of why
>> it is. I know that I can specify something other than the default. I
>> don't know why the default is not the same as the chosen. You keep
>> failing to answer that question. Why does it *need* to stay -unknown-
>> instead of -pc-?
> No one says the default NEEDs to stay -unknown-, but the point we're
> making is that no one has yet provided proof of why it CANNOT stay
> -unknown-, and that absent any proof for a reason to change, it's better
> to leave well enough alone.
But if it is a default and all the maintainers choose -pc- instead of
-unknown- during the configure process then it doesn't matter what the
default is except in the case of the default providing a different host
tool set than what is delivered by setup. So if someone else build
binutils or some other package providing host named tools using the
default host and build then the host tool set is named
x86_64-unknown-cygwin instead of x86_64-pc-cygwin. This is why I am so
adamant for changing config.guess.
Currently for me to build binutils and match what is supplied by
setup.exe without using cygport and using just configure then I must
supply --host and --build to configure so that I get a matching host set.
> You are more than welcome to propose a patch to upstream config.guess
> that provides a different default (config.guess is Free Software, after
> all - as long as you abide by the license terms, you can write and post
> any patch you like, whether or not we agree with it; but in turn, you
> have to be prepared that upstream may reject your patch which leaves you
> with carrying your patch in your personal downstream only); but be aware
> that your patch may go nowhere upstream. Part of that is that upstream
> already knows about MULTIPLE platforms where the default string guesses
> differently than the chosen triple (so Cygwin is not special in that
> regards), and part of that is that upstream tends to prefer deferring to
> the developers of a given platform where that is practical, and this
> thread on the Cygwin list is a good case where the developers of Cygwin
> have stated that such a patch is not necessary (it might not be harmful,
> but it is not necessary). Or, if upstream does, for some reason, agree
> with your patch, it still is not something so urgent that we would
> backport it downstream any faster than normal propagation of other
> upstream packages slowly picking up newer config.guess as they release
> new tarballs.
And I'm willing to supply that patch. Config.guess needs a one line
change and no change to config.sub. Config.sub already provides the
-pc- vendor for the x86_64-cygwin input. Yet another reason for the
patch to config.guess. Once the patch is applied then attrition will
take care of downstream use.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple