Re: Which is it -pc- or -unknown-

2017-10-21 Thread Steven Penny

On Sat, 21 Oct 2017 16:17:13, cyg Simple wrote:

5 sec * 2300 packages = 11,500 sec
11,500 sec is 3.19 hours

> Which in a build like FFmpeg or similar, is statistically 0.
> 


1 package once in a while doesn't matter.

> So perhaps you have some data to show a non-trivial amount of time saved
> that
> would make this worth it?

3.19 hours * many builds is equal to days and weeks.

The 5 sec is your guess, probably less but ...  Minutia ends up being
quite a large sum when you repeat a process over and over.

The 2300 packages is a round of the number of packages Yaakov supports.


I was wondering when your side of the discussion would finally fail, and here
we have it.

1. You have provided no concrete examples, just some numbers pulled out of the
  air. Look, I can do that too! 5 sec * 1,000,000 packages = 5,000,000 sec!
  OMG PATCH IT NOW!

2. You specifically mention Yaakav, and you are right, he above probably anyone
  would have the most incentive to see this "fixed". However he has made it
  vividly clear that this "patch" (im quoting because you have also failed to
  produce one so far) isnt need and wont be accepted even if you wrote it.

Good day.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-21 Thread cyg Simple
On 10/21/2017 3:26 PM, Steven Penny wrote:
> On Sat, 21 Oct 2017 13:29:43, cyg Simple wrote:
>> Changing the default does improve the speed of configure because
>> configure no longer needs to execute GCC to figure out where the build
>> files are.  Yes the time saved is small but time is expensive so any
>> saving is a big deal, especially with such a small change.
> 
> I would argue that the difference you are talking about is less than 5
> seconds.

5 sec * 2300 packages = 11,500 sec
11,500 sec is 3.19 hours

> Which in a build like FFmpeg or similar, is statistically 0.
> 

1 package once in a while doesn't matter.

> So perhaps you have some data to show a non-trivial amount of time saved
> that
> would make this worth it?

3.19 hours * many builds is equal to days and weeks.

The 5 sec is your guess, probably less but ...  Minutia ends up being
quite a large sum when you repeat a process over and over.

The 2300 packages is a round of the number of packages Yaakov supports.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-21 Thread Steven Penny

On Sat, 21 Oct 2017 13:29:43, cyg Simple wrote:

Changing the default does improve the speed of configure because
configure no longer needs to execute GCC to figure out where the build
files are.  Yes the time saved is small but time is expensive so any
saving is a big deal, especially with such a small change.


I would argue that the difference you are talking about is less than 5 seconds.
Which in a build like FFmpeg or similar, is statistically 0.

So perhaps you have some data to show a non-trivial amount of time saved that
would make this worth it?


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-21 Thread cyg Simple
On 10/20/2017 6:47 PM, Steven Penny wrote:
> On Fri, 20 Oct 2017 15:53:28, cyg Simple wrote:
>> I appreciate what Yaakov does but I bet these are not built in native
>> Cygwin mode so a host must be supplied.  In native mode the default is
>> typically used and currently it doesn't match the expected host
>> environment.
> 
> Really this discussion boils down to a single question:
> 
> What does not patching this break?
> 

As Yakoov has already pointed out, nothing is broken.

> Currently the answer is nothing, per my previous post:
> 
> http://cygwin.com/ml/cygwin/2017-10/msg00227.html
> 
> so the onus is not on Yaakov or whoever, the onus is on you to answer that
> question. Until then, you are breathing air that is not cold.
> 

Changing the default does improve the speed of configure because
configure no longer needs to execute GCC to figure out where the build
files are.  Yes the time saved is small but time is expensive so any
saving is a big deal, especially with such a small change.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-20 Thread Steven Penny

On Fri, 20 Oct 2017 15:53:28, cyg Simple wrote:

I appreciate what Yaakov does but I bet these are not built in native
Cygwin mode so a host must be supplied.  In native mode the default is
typically used and currently it doesn't match the expected host environment.


Really this discussion boils down to a single question:

What does not patching this break?

Currently the answer is nothing, per my previous post:

http://cygwin.com/ml/cygwin/2017-10/msg00227.html

so the onus is not on Yaakov or whoever, the onus is on you to answer that
question. Until then, you are breathing air that is not cold.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-20 Thread Yaakov Selkowitz
On 2017-10-20 14:53, cyg Simple wrote:
> I appreciate what Yaakov does but I bet these are not built in native
> Cygwin mode so a host must be supplied.  In native mode the default is
> typically used and currently it doesn't match the expected host environment.

You lose the bet.  Every single package I ship is built natively(*) on
Cygwin -- and hence without specifying build or host -- without any such
problems.  (Yes, I do provide a Fedora-to-Cygwin cross-compiler
toolchain, but that is used primarily by those working on the
newlib-cygwin code; I don't use it myself.)

Now, can we start discussing whatever specific issue you encountered,
rather than being stuck on misconceptions?

(*) Obviously my mingw64-* packages aren't "native" but cross-compiled
with --build and --host specified, but they too are built on Cygwin,
with our mingw64 toolchain.

-- 
Yaakov



signature.asc
Description: OpenPGP digital signature


Re: Which is it -pc- or -unknown-

2017-10-20 Thread cyg Simple
On 10/20/2017 1:41 PM, Marco Atzeri wrote:
> On 20/10/2017 17:44, cyg Simple wrote:
>> On 10/20/2017 11:24 AM, 
> 
>> Why is it different?  Give a reason not just
>> some lame excuse.
> 
> This is extremely rude, in my opinion.
> 

Thanks for your opinion.  I reworded most of my original text in the
mail but missed this one.

> Yaakov has been extremely patient with you but you are always
> disregarding our point of view, that only shows us that
> you have a bad understanding of the triplet concept.
> 
> Please consider one point, that clearly you are missing,
> about who has the experience and knowledge on the matter.
> 

You don't know how much experience I also have.  Really, it isn't about
that.

> We have around 3800 packages on cygwin,
> and on https://www.cygwin.com/cygwin-pkg-maint
> you will see who is the maintainer of each one
> 
> The top contributors are:
> 
>    2717 Yaakov Selkowitz

I appreciate what Yaakov does but I bet these are not built in native
Cygwin mode so a host must be supplied.  In native mode the default is
typically used and currently it doesn't match the expected host environment.

>     212 Achim Gratz
>     169 Jari Aalto
>     149 Marco Atzeri
>  82 Ken Brown
>  70 Achim Gratz/Yaakov Selkowitz
> 
> 
> You don't tell the brewer how to make the beer.

The brewer is using a recipe to make the beer.  That doesn't mean the
recipe cannot be improved.  But in this case the brewer doesn't need to
change anything other than the suggestion of which host the recipe is
brewed on.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-20 Thread cyg Simple
On 10/20/2017 2:44 PM, Brian Inglis wrote:
> On 2017-10-20 11:41, Marco Atzeri wrote:
>> On 20/10/2017 17:44, cyg Simple wrote:
>>> On 10/20/2017 11:24 AM, 
>>> Why is it different?  Give a reason not just some lame excuse.
>> This is extremely rude, in my opinion.
> 
> He's not asking the question he needs answered and is getting exasperated.
> 

I asked the question I wanted to ask, it was answered.

>> You don't tell the brewer how to make the beer.
> 
> I think the home brewer wants to make the standard brew, but no one is
> explaining how to get "./configure && make" to produce the *PC* product, 
> instead
> of some /unknown/ swill. ;^>
> 

This isn't the question that needed answered.  Sorry but I'm only
talking about the default vendor from config.guess versus the chosen
vendor and don't need help with ./configure && make.  Erik Blake finally
supplied a modicum of a reason why -unknown- is used but wasn't
insistent that it needed to stay -unknown-.  Feel free to tell me why
you think config.guess should supply a default vendor of -unknown- for
Cygwin even when config.sub doesn't?

The purpose of config.guess is to supply configure the default build
environment.  If the host isn't supplied to configure then it defaults
to match the build string.  Since the build environment for Cygwin is
x86_64-pc-cygwin then config.guess should default to that.  This isn't a
problem with most packages because they don't provide tools based on the
host triplet.  However, there are packages that do use the host triplet
to provide a hosted set of tools.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-20 Thread cyg Simple
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-.

x86_64:Linux:*:*)
echo ${UNAME_MACHINE}-pc-linux-${LIBC}
exit ;;


>  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.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-20 Thread Brian Inglis
On 2017-10-20 11:41, Marco Atzeri wrote:
> On 20/10/2017 17:44, cyg Simple wrote:
>> On 10/20/2017 11:24 AM, 
>> Why is it different?  Give a reason not just some lame excuse.
> This is extremely rude, in my opinion.

He's not asking the question he needs answered and is getting exasperated.

> You don't tell the brewer how to make the beer.

I think the home brewer wants to make the standard brew, but no one is
explaining how to get "./configure && make" to produce the *PC* product, instead
of some /unknown/ swill. ;^>

"Euch ist bekannt was wir bedürfen, wir wollen starke Getränke schlürfen!"
Bayern ist toll - Alles Gute - Prost! Slainthe! Cheers!

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-20 Thread Eric Blake
On 10/20/2017 11:11 AM, cyg Simple wrote:

I may regret joining this thread, but here goes.

>> 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.
 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.

>  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.

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.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: Which is it -pc- or -unknown-

2017-10-20 Thread Marco Atzeri

On 20/10/2017 17:44, cyg Simple wrote:
On 10/20/2017 11:24 AM, 



Why is it different?  Give a reason not just
some lame excuse.


This is extremely rude, in my opinion.

Yaakov has been extremely patient with you but you are always
disregarding our point of view, that only shows us that
you have a bad understanding of the triplet concept.

Please consider one point, that clearly you are missing,
about who has the experience and knowledge on the matter.

We have around 3800 packages on cygwin,
and on https://www.cygwin.com/cygwin-pkg-maint
you will see who is the maintainer of each one

The top contributors are:

   2717 Yaakov Selkowitz
212 Achim Gratz
169 Jari Aalto
149 Marco Atzeri
 82 Ken Brown
 70 Achim Gratz/Yaakov Selkowitz


You don't tell the brewer how to make the beer.

Cheers from Munich
Marco

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-20 Thread cyg Simple
On 10/20/2017 12:11 PM, cyg Simple wrote:
> On 10/20/2017 11:54 AM, Yaakov Selkowitz wrote:
>> On 2017-10-20 10:44, cyg Simple wrote:
>>> On 10/20/2017 11:24 AM, Yaakov Selkowitz wrote:
 On 2017-10-20 08:28, cyg Simple wrote:
> On 10/19/2017 4:33 PM, Yaakov Selkowitz wrote:
>> 2) the output of config.guess is a default and does NOT reflect, or need
>> to match, our chosen triplet.  There is nothing to fix in config.guess.
>
> Fine, it doesn't have to match, why don't you want it to?

 Because there is no correlation, is completely normal, and therefore no
 need to special case Cygwin.
>>>
>>> What is *normal* about it?  Just because other's do it?  I gave
>>> scenarios in the mail which you elided from your response which give
>>> credence to a reason to change it.
>>
>> You are still looking at these from the same perspective you were
>> yesterday.  Let me restate this one (hopefully last) time:
>>
>> 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?  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-?
> 

And to further my proposal that -pc- should be the correct config.guess
vendor I find the following comment in config.sub.

# We use `pc' rather than `unknown'
# because (1) that's what they normally are, and
# (2) the word "unknown" tends to confuse beginning users.
i*86 | x86_64)
  basic_machine=$basic_machine-pc
  ;;

I also find in the config.guess file the following filter for Linux on
x86_64.

x86_64:Linux:*:*)
echo ${UNAME_MACHINE}-pc-linux-${LIBC}
exit ;;

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-20 Thread cyg Simple
On 10/20/2017 11:54 AM, Yaakov Selkowitz wrote:
> On 2017-10-20 10:44, cyg Simple wrote:
>> On 10/20/2017 11:24 AM, Yaakov Selkowitz wrote:
>>> On 2017-10-20 08:28, cyg Simple wrote:
 On 10/19/2017 4:33 PM, Yaakov Selkowitz wrote:
> 2) the output of config.guess is a default and does NOT reflect, or need
> to match, our chosen triplet.  There is nothing to fix in config.guess.

 Fine, it doesn't have to match, why don't you want it to?
>>>
>>> Because there is no correlation, is completely normal, and therefore no
>>> need to special case Cygwin.
>>
>> What is *normal* about it?  Just because other's do it?  I gave
>> scenarios in the mail which you elided from your response which give
>> credence to a reason to change it.
> 
> You are still looking at these from the same perspective you were
> yesterday.  Let me restate this one (hopefully last) time:
> 
> 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?  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-?

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-20 Thread Yaakov Selkowitz
On 2017-10-20 10:44, cyg Simple wrote:
> On 10/20/2017 11:24 AM, Yaakov Selkowitz wrote:
>> On 2017-10-20 08:28, cyg Simple wrote:
>>> On 10/19/2017 4:33 PM, Yaakov Selkowitz wrote:
 2) the output of config.guess is a default and does NOT reflect, or need
 to match, our chosen triplet.  There is nothing to fix in config.guess.
>>>
>>> Fine, it doesn't have to match, why don't you want it to?
>>
>> Because there is no correlation, is completely normal, and therefore no
>> need to special case Cygwin.
> 
> What is *normal* about it?  Just because other's do it?  I gave
> scenarios in the mail which you elided from your response which give
> credence to a reason to change it.

You are still looking at these from the same perspective you were
yesterday.  Let me restate this one (hopefully last) time:

Your assumption is that the default and chosen triplets must/should be
one and the same.  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.

-- 
Yaakov



signature.asc
Description: OpenPGP digital signature


Re: Which is it -pc- or -unknown-

2017-10-20 Thread cyg Simple
On 10/20/2017 11:24 AM, Yaakov Selkowitz wrote:
> On 2017-10-20 08:28, cyg Simple wrote:
>> On 10/19/2017 4:33 PM, Yaakov Selkowitz wrote:
>>> 2) the output of config.guess is a default and does NOT reflect, or need
>>> to match, our chosen triplet.  There is nothing to fix in config.guess.
>>
>> Fine, it doesn't have to match, why don't you want it to?
> 
> Because there is no correlation, is completely normal, and therefore no
> need to special case Cygwin.
> 

What is *normal* about it?  Just because other's do it?  I gave
scenarios in the mail which you elided from your response which give
credence to a reason to change it.

There is nothing that is *normal* in any scenario of config.guess.  It
is what the maintainers decide.  You've not given a reason for the
decision to make the *default* not match the *chosen* vendor.  You just
stand on the podium of unreason to state something as normal that has no
merit in being normal.  Doing so doesn't make Cygwin a special case.

Yes, I can override the default, but I shouldn't have to is my reasoning
of normal.  In my sense of reasoning the normal should be the *default*
matching the *chosen*.  Why is it different?  Give a reason not just
some lame excuse.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-20 Thread Yaakov Selkowitz
On 2017-10-20 08:28, cyg Simple wrote:
> On 10/19/2017 4:33 PM, Yaakov Selkowitz wrote:
>> 2) the output of config.guess is a default and does NOT reflect, or need
>> to match, our chosen triplet.  There is nothing to fix in config.guess.
> 
> Fine, it doesn't have to match, why don't you want it to?

Because there is no correlation, is completely normal, and therefore no
need to special case Cygwin.

-- 
Yaakov



signature.asc
Description: OpenPGP digital signature


Re: Which is it -pc- or -unknown-

2017-10-20 Thread cyg Simple
On 10/19/2017 4:33 PM, Yaakov Selkowitz wrote:
> 2) the output of config.guess is a default and does NOT reflect, or need
> to match, our chosen triplet.  There is nothing to fix in config.guess.

Fine, it doesn't have to match, why don't you want it to?  Don't give me
the historical reasons idea.

Scenario:
I know nothing of your *chosen* x86_64-pc-cygwin.
I have found a new compiler toolchain I want to build from source.
I use the defaults for the configure script.
I end up with host tools of x86_64-unknown-cygwin.
This now doesn't match your *chosen* x86_64-pc-cygwin.

Scenario:
I know nothing of your *chosen* x86_64-pc-cygwin.
I download the latest version of binutils
I use the defaults for the configure script.
I end up with host tools of x86_64-unknown-cygwin.
This now doesn't match your *chosen* x86-64-pc-cygwin.

What is your angst toward changing the *default* to match the *chosen*?

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-19 Thread Brian Inglis
On 2017-10-19 19:11, Yaakov Selkowitz wrote:
> On 2017-10-19 18:49, Steven Penny wrote:
>> On Thu, 19 Oct 2017 17:00:12, cyg Simple wrote:
>>> So says you!  The vendor portion has been agreed to be -pc- and it isn't
>>> -unknown-, a patch then should be created for config.guess to match the
>>> agreed upon vendor.  The config.guess script supplies the default to
>>> configure for the build and host.  The fact that config.guess supplies
>>> x86_64-unknown-cygwin is used by configure is the reason my assumptions
>>> are correct.  If -pc- should be used then config.guess needs to change.
>> Let us bring some sanity to this discussion/argument. With this repository:
>>    git clone --depth 1 git://github.com/php/php-src
>>    cd php-src
>>    ./buildconf
>> Test 1:
>>    $ ./configure --host x86_64-pc-cygwin
>>    checking build system type... x86_64-unknown-cygwin
>>    checking host system type... x86_64-pc-cygwin
>>    checking for x86_64-pc-cygwin-gcc... x86_64-pc-cygwin-gcc
>>    checking whether the C compiler works... yes
> Two things wrong with this:
> 1) If you specify --host, you need to specify --build as well.
> 2) If you're not cross-compiling or building a toolchain package, you
> shouldn't be specifying either.
>> Test 2:
>>    $ ./configure --host x86_64-unknown-cygwin
>>    checking build system type... x86_64-unknown-cygwin
>>    checking host system type... x86_64-unknown-cygwin
>>    checking for x86_64-unknown-cygwin-gcc... no
>>    checking for cc... cc
>>    checking whether the C compiler works... yes
>> So yes, specifying "--host x86_64-unknown-cygwin" causes it to not find
>> "x86_64-unknown-cygwin-gcc.exe", which makes sense because that doesnt
>> exist.
> True, when you *need* to specify --build/--host, then x86_64-pc-cygwin
> should be used.  When not (as in this case), then omit them.

So if autoconf does not find the triplet prefixed build tool, it should use the
non-triplet prefixed build tool, and if it doesn't do that, then there is an
issue either with the package autoconf setup or the autoconf package being used?

If that is the case with the OP's build, they should report it to the upstream
package maintainer.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-19 Thread Yaakov Selkowitz
On 2017-10-19 18:49, Steven Penny wrote:
> On Thu, 19 Oct 2017 17:00:12, cyg Simple wrote:
>> So says you!  The vendor portion has been agreed to be -pc- and it isn't
>> -unknown-, a patch then should be created for config.guess to match the
>> agreed upon vendor.  The config.guess script supplies the default to
>> configure for the build and host.  The fact that config.guess supplies
>> x86_64-unknown-cygwin is used by configure is the reason my assumptions
>> are correct.  If -pc- should be used then config.guess needs to change.
> 
> Let us bring some sanity to this discussion/argument. With this repository:
> 
>    git clone --depth 1 git://github.com/php/php-src
>    cd php-src
>    ./buildconf
> 
> Test 1:
> 
>    $ ./configure --host x86_64-pc-cygwin
>    checking build system type... x86_64-unknown-cygwin
>    checking host system type... x86_64-pc-cygwin
>    checking for x86_64-pc-cygwin-gcc... x86_64-pc-cygwin-gcc
>    checking whether the C compiler works... yes

Two things wrong with this:

1) If you specify --host, you need to specify --build as well.
2) If you're not cross-compiling or building a toolchain package, you
shouldn't be specifying either.

> Test 2:
> 
>    $ ./configure --host x86_64-unknown-cygwin
>    checking build system type... x86_64-unknown-cygwin
>    checking host system type... x86_64-unknown-cygwin
>    checking for x86_64-unknown-cygwin-gcc... no
>    checking for cc... cc
>    checking whether the C compiler works... yes
> 
> So yes, specifying "--host x86_64-unknown-cygwin" causes it to not find
> "x86_64-unknown-cygwin-gcc.exe", which makes sense because that doesnt
> exist.

True, when you *need* to specify --build/--host, then x86_64-pc-cygwin
should be used.  When not (as in this case), then omit them.

-- 
Yaakov



signature.asc
Description: OpenPGP digital signature


Re: Which is it -pc- or -unknown-

2017-10-19 Thread Steven Penny

On Thu, 19 Oct 2017 17:00:12, cyg Simple wrote:

So says you!  The vendor portion has been agreed to be -pc- and it isn't
-unknown-, a patch then should be created for config.guess to match the
agreed upon vendor.  The config.guess script supplies the default to
configure for the build and host.  The fact that config.guess supplies
x86_64-unknown-cygwin is used by configure is the reason my assumptions
are correct.  If -pc- should be used then config.guess needs to change.


Let us bring some sanity to this discussion/argument. With this repository:

   git clone --depth 1 git://github.com/php/php-src
   cd php-src
   ./buildconf

Test 1:

   $ ./configure --host x86_64-pc-cygwin
   checking build system type... x86_64-unknown-cygwin
   checking host system type... x86_64-pc-cygwin
   checking for x86_64-pc-cygwin-gcc... x86_64-pc-cygwin-gcc
   checking whether the C compiler works... yes

Test 2:

   $ ./configure --host x86_64-unknown-cygwin
   checking build system type... x86_64-unknown-cygwin
   checking host system type... x86_64-unknown-cygwin
   checking for x86_64-unknown-cygwin-gcc... no
   checking for cc... cc
   checking whether the C compiler works... yes

So yes, specifying "--host x86_64-unknown-cygwin" causes it to not find
"x86_64-unknown-cygwin-gcc.exe", which makes sense because that doesnt exist.
However notice carefully in the next step that it finds
"x86_64-pc-cygwin-gcc.exe:

   $ ls -l /bin/cc
   lrwxrwxrwx 1 Steven None 7 Sep  9 17:18 /bin/cc -> gcc.exe

   $ find /bin -samefile /bin/gcc
   /bin/gcc.exe
   /bin/x86_64-pc-cygwin-gcc-6.4.0.exe
   /bin/x86_64-pc-cygwin-gcc.exe


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-19 Thread Yaakov Selkowitz
On 2017-10-19 18:21, Brian Inglis wrote:
> I think the OP's problem is he knows no way to override the default and use 
> only
> the standard ./configure && make build approach.

Which works just fine btw, so there's no need to override it.

> The OP could take a build config.cache and save it in /etc/config.cache, 
> change
> all -unknown-cygwin to -pc-cygwin, then create a shell script /etc/config.site
> like: [snip]

None of this is necessary.

> Or he could use cygport with the Cygwin source packages.

And as much as I'd recommend it, it's not strictly necessary for sources
that one is building for themselves.  Even cygport only specifies
--build and --host when cross-compiling, not normally.

-- 
Yaakov



signature.asc
Description: OpenPGP digital signature


Re: Which is it -pc- or -unknown-

2017-10-19 Thread Brian Inglis
On 2017-10-19 15:14, Yaakov Selkowitz wrote:
> On 2017-10-19 16:00, cyg Simple wrote:
>> On 10/19/2017 4:35 PM, Yaakov Selkowitz wrote:
>>> On 2017-10-19 15:02, cyg Simple wrote:
 On 10/19/2017 3:54 PM, Brian Inglis wrote:
> On 2017-10-19 12:59, Yaakov Selkowitz wrote:
>> On 2017-10-19 13:40, cyg Simple wrote:
>>> x86_64-pc-cygwin is just not correct regardless of the lack of past 
>>> issues.
>>
>> As I have said several times, this assertion is incorrect.  You need to
>> use the triplet which matches the toolchain with which you are building.
>> For example, Fedora and RHEL all use $arch-redhat-linux as their
>> triplet, and there is nothing wrong with that.
>
> Vendor -unknown- is just a default in various config cases, so specifying 
> -pc-
> for consistency on Cygwin builds is a valid choice by the maintainers.

 FINE!  But config.guess should match the CHOSEN one.
>>>
>>> Incorrect assumption.
>>
>> You keep saying my assumption is incorrect but that isn't the case.  My
>> assumption is based on data supplied by the configure process.
> 
> Your assumption is that the default and chosen triplets must be one and
> the same.  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.
> 
> Several of us with years of experience in these matters have tried to
> help explain this to you.  Repeatedly pointing to the same piece of
> "evidence" as supposed proof for your "case", as if it were up for
> debate, isn't helping you to understand how things actually work.  This
> discussion would be better served by being specific about the package
> you are trying to build, how you are trying to build it, and the exact
> error message you are seeing.

I think the OP's problem is he knows no way to override the default and use only
the standard ./configure && make build approach. This seems to be explained
somewhat by running $ info autoconf "Site Defaults".

The OP could take a build config.cache and save it in /etc/config.cache, change
all -unknown-cygwin to -pc-cygwin, then create a shell script /etc/config.site
like:

# /etc/config.site for configure
#
# setup with export CONFIG_SITE=/etc/config.site in ~/.*profile
#
# Give Autoconf 2.x generated configure scripts a shared default
# cache file for feature test results, architecture-specific.
[ "$cache_file" = "/dev/null" ] && cache_file="/etc/config.cache"

then as noted above add "export CONFIG_SITE=/etc/config.site" to some
~/.*profile so it gets set up automatically.

He could also set up the script and cache files under $prefix/share/ for any
specific install targets, and not export CONFIG_SITE.

Or he could use cygport with the Cygwin source packages.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-19 Thread JonY
On 10/19/2017 04:18 PM, cyg Simple wrote:
> On 10/19/2017 10:18 AM, Ken Brown wrote:
>> On 10/19/2017 9:19 AM, cyg Simple wrote:
>>> On 10/18/2017 6:58 PM, JonY wrote:
 I agree with Yaakov, why does it need to change?

>>>
>>> See my response to Yaakov.  If you supply explicit host and build to
>>> configure it does not work.
>>
>> So don't do that.  Specifying host is for cross-compilation.  Specifying
>> build without host is for overriding the result of config.guess (never
>> necessary on Cygwin).  See
>>
>>
>> https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html
>>
>>
>> In particular:  "If you mean to override the result of config.guess, use
>> --build, not --host, since the latter enables cross-compilation."
>>
> 
> So?! It is still incorrect for the --target of the GCC build to be
> x86_64-pc-cygwin.  My example didn't specify a different build from
> host.  I ran across this from a package that was refusing to accept the
> config.guess build triplet so I tried specifying both.  At that point it
> failed to find x86_64-unknown-cygwin-gcc.
> 
> And ./configure --build=`/path/to/config.guess` will not work either as
> currently delivered.
> 
> x86_64-pc-cygwin IS NOT CORRECT.  It needs fixed in the build process.
> 

If it means that much to you, use -pc- instead.



signature.asc
Description: OpenPGP digital signature


Re: Which is it -pc- or -unknown-

2017-10-19 Thread Yaakov Selkowitz
On 2017-10-19 16:00, cyg Simple wrote:
> On 10/19/2017 4:35 PM, Yaakov Selkowitz wrote:
>> On 2017-10-19 15:02, cyg Simple wrote:
>>> On 10/19/2017 3:54 PM, Brian Inglis wrote:
 On 2017-10-19 12:59, Yaakov Selkowitz wrote:
> On 2017-10-19 13:40, cyg Simple wrote:
>> x86_64-pc-cygwin is just not correct regardless of the lack of past 
>> issues.
>
> As I have said several times, this assertion is incorrect.  You need to
> use the triplet which matches the toolchain with which you are building.
> For example, Fedora and RHEL all use $arch-redhat-linux as their
> triplet, and there is nothing wrong with that.

 Vendor -unknown- is just a default in various config cases, so specifying 
 -pc-
 for consistency on Cygwin builds is a valid choice by the maintainers.
>>>
>>> FINE!  But config.guess should match the CHOSEN one.
>>
>> Incorrect assumption.
> 
> You keep saying my assumption is incorrect but that isn't the case.  My
> assumption is based on data supplied by the configure process.

Your assumption is that the default and chosen triplets must be one and
the same.  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.

Several of us with years of experience in these matters have tried to
help explain this to you.  Repeatedly pointing to the same piece of
"evidence" as supposed proof for your "case", as if it were up for
debate, isn't helping you to understand how things actually work.  This
discussion would be better served by being specific about the package
you are trying to build, how you are trying to build it, and the exact
error message you are seeing.

-- 
Yaakov



signature.asc
Description: OpenPGP digital signature


Re: Which is it -pc- or -unknown-

2017-10-19 Thread cyg Simple
On 10/19/2017 4:35 PM, Yaakov Selkowitz wrote:
> On 2017-10-19 15:02, cyg Simple wrote:
>> On 10/19/2017 3:54 PM, Brian Inglis wrote:
>>> On 2017-10-19 12:59, Yaakov Selkowitz wrote:
 On 2017-10-19 13:40, cyg Simple wrote:
> x86_64-pc-cygwin is just not correct regardless of the lack of past 
> issues.

 As I have said several times, this assertion is incorrect.  You need to
 use the triplet which matches the toolchain with which you are building.
 For example, Fedora and RHEL all use $arch-redhat-linux as their
 triplet, and there is nothing wrong with that.
>>>
>>> Vendor -unknown- is just a default in various config cases, so specifying 
>>> -pc-
>>> for consistency on Cygwin builds is a valid choice by the maintainers.
>>
>> FINE!  But config.guess should match the CHOSEN one.
> 
> Incorrect assumption.
> 

You keep saying my assumption is incorrect but that isn't the case.  My
assumption is based on data supplied by the configure process.

>>> Perhaps a statement on the cygwin-apps list could clarify what should be 
>>> done by
>>> maintainers to ensure this override, and maybe retire the use of -unknown- 
>>> by
>>> any Cygwin apps in future, with a notice to this (cygwin) list for those who
>>> choose to build packages from net sources.
>>
>> I don't care which is used as long as config.guess matches what is chosen.
> 
> That is not a requirement.
> 
>>> Perhaps also patches should be submitted to the config and automake 
>>> maintainers
>>> to ensure that {i*,x86_64}:CYGWIN*:*... always produce vendor -pc-. Not sure
>>> about vendors for {amd64,powerpcle}:CYGWIN*:*... in config.guess, which are
>>> currently also set to -unknown-.
>>
>> Exactly what I'm saying.  It needs to match what is being distributed
>> just for consistency and to avoid confusion.
> 
> No patch is needed here.

So says you!  The vendor portion has been agreed to be -pc- and it isn't
-unknown-, a patch then should be created for config.guess to match the
agreed upon vendor.  The config.guess script supplies the default to
configure for the build and host.  The fact that config.guess supplies
x86_64-unknown-cygwin is used by configure is the reason my assumptions
are correct.  If -pc- should be used then config.guess needs to change.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-19 Thread Yaakov Selkowitz
On 2017-10-19 15:26, cyg Simple wrote:
> My assumption is because of config.guess' default.  It isn't incorrect,
> it is a valid assumption.  You cannot have both, it is one or the other.

Your assumption that the default provided by config.guess must match the
one we have chosen is incorrect.  Once you are prepared to accept that,
then we can help address whatever real-world issues you are encountering.

> I've Cc Ben Elliston to give his opinion.  Sorry, Ben.

As the Cygwin maintainer of autotools (and, for that matter, the
majority of our packages), I assure you that no changes are necessary.
Trying to go over my head to upstream to tell me what our triplet should
or shouldn't be is not the way to go about this.

-- 
Yaakov



signature.asc
Description: OpenPGP digital signature


Re: Which is it -pc- or -unknown-

2017-10-19 Thread Yaakov Selkowitz
On 2017-10-19 15:02, cyg Simple wrote:
> On 10/19/2017 3:54 PM, Brian Inglis wrote:
>> On 2017-10-19 12:59, Yaakov Selkowitz wrote:
>>> On 2017-10-19 13:40, cyg Simple wrote:
 x86_64-pc-cygwin is just not correct regardless of the lack of past issues.
>>>
>>> As I have said several times, this assertion is incorrect.  You need to
>>> use the triplet which matches the toolchain with which you are building.
>>> For example, Fedora and RHEL all use $arch-redhat-linux as their
>>> triplet, and there is nothing wrong with that.
>>
>> Vendor -unknown- is just a default in various config cases, so specifying 
>> -pc-
>> for consistency on Cygwin builds is a valid choice by the maintainers.
> 
> FINE!  But config.guess should match the CHOSEN one.

Incorrect assumption.

>> Perhaps a statement on the cygwin-apps list could clarify what should be 
>> done by
>> maintainers to ensure this override, and maybe retire the use of -unknown- by
>> any Cygwin apps in future, with a notice to this (cygwin) list for those who
>> choose to build packages from net sources.
> 
> I don't care which is used as long as config.guess matches what is chosen.

That is not a requirement.

>> Perhaps also patches should be submitted to the config and automake 
>> maintainers
>> to ensure that {i*,x86_64}:CYGWIN*:*... always produce vendor -pc-. Not sure
>> about vendors for {amd64,powerpcle}:CYGWIN*:*... in config.guess, which are
>> currently also set to -unknown-.
> 
> Exactly what I'm saying.  It needs to match what is being distributed
> just for consistency and to avoid confusion.

No patch is needed here.

-- 
Yaakov



signature.asc
Description: OpenPGP digital signature


Re: Which is it -pc- or -unknown-

2017-10-19 Thread Vince Rice
> On Oct 19, 2017, at 3:21 PM, cyg Simple  wrote:
> 
> On 10/19/2017 4:02 PM, Vince Rice wrote:
>>> On Oct 19, 2017, at 2:08 PM, cyg Simple  wrote:
>>> 
>>> On 10/19/2017 2:51 PM, Yaakov Selkowitz wrote:
 
 When you *really* need to use --build and/or --host, then you need to
 use x86_64-pc-cygwin, as that is our chosen name.
>>> 
>>> Then config.guess needs to change to match the chosen name!!
>>> 
>>> Why confuse everyone?  Make up your mind and choose one.  I can submit
>>> the patches to the config maintainer.
>> 
>> It's not confusing everyone. You're the only one jumping up and down, you 
>> have refused to provide information needed to help you, and in spite of 
>> that, Yaakov has given you a reasonable guess at a solution.
>> 
> 
> I'm not providing the name of the package because I don't need help
> configuring it and I don't want the discussion to become how to do that.
> 
>> I can only conclude you just like to hear yourself scream. If only we were 
>> in space…
> 
> I would float near you and SCREAM in your ear.  At least I have Brian
> thinking that config.guess needs to change so it has helped some.
> 
> So, Vince, what is the triplet you like for x86_64 Cygwin?

You missed the point of the joke, just like you've missed the point of this 
entire conversation. I'll leave you to Yaakov.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-19 Thread Yaakov Selkowitz
On 2017-10-19 15:21, cyg Simple wrote:
> I'm not providing the name of the package because I don't need help
> configuring it and I don't want the discussion to become how to do that.

This is *exactly* what this discussion *should* have been about from the
beginning, because that would have been a productive discussion.  This,
unfortunately, has not been.

> I would float near you and SCREAM in your ear.  At least I have Brian
> thinking that config.guess needs to change so it has helped some.
> 
> So, Vince, what is the triplet you like for x86_64 Cygwin?

This isn't a matter for debate and we're not taking a vote on it.  For
(hopefully) the last time:

1) our chosen toolchain triplet is x86_64-pc-cygwin.  This is what you
need to use when specifying --build and/or --host.
2) the output of config.guess is a default and does NOT reflect, or need
to match, our chosen triplet.  There is nothing to fix in config.guess.
3) the *correct* course of action if config.{guess,sub} do not recognize
64-bit Cygwin is to update those files (e.g. with gnuconfigize in cygport).

-- 
Yaakov



signature.asc
Description: OpenPGP digital signature


Re: Which is it -pc- or -unknown-

2017-10-19 Thread cyg Simple
On 10/19/2017 4:21 PM, Yaakov Selkowitz wrote:
> On 2017-10-19 14:08, cyg Simple wrote:
>> On 10/19/2017 2:51 PM, Yaakov Selkowitz wrote:
>>>
>>> When you *really* need to use --build and/or --host, then you need to
>>> use x86_64-pc-cygwin, as that is our chosen name.
>>
>> Then config.guess needs to change to match the chosen name!!
> 
> No, it doesn't.  Don't confuse the default triplet with the chosen one.
> 
>> Why confuse everyone?  Make up your mind and choose one.
> 
> We have chosen one, and this is what everyone needs to use, and it does
> NOT have to match the default.
> 
>> I can submit the patches to the config maintainer.
> 
> The code is correct as it is; the only thing needing to be changed here
> is incorrect assumptions.

My assumption is because of config.guess' default.  It isn't incorrect,
it is a valid assumption.  You cannot have both, it is one or the other.

I've Cc Ben Elliston to give his opinion.  Sorry, Ben.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-19 Thread cyg Simple
On 10/19/2017 4:02 PM, Vince Rice wrote:
>> On Oct 19, 2017, at 2:08 PM, cyg Simple  wrote:
>>
>> On 10/19/2017 2:51 PM, Yaakov Selkowitz wrote:
>>>
>>> When you *really* need to use --build and/or --host, then you need to
>>> use x86_64-pc-cygwin, as that is our chosen name.
>>
>> Then config.guess needs to change to match the chosen name!!
>>
>> Why confuse everyone?  Make up your mind and choose one.  I can submit
>> the patches to the config maintainer.
> 
> It's not confusing everyone. You're the only one jumping up and down, you 
> have refused to provide information needed to help you, and in spite of that, 
> Yaakov has given you a reasonable guess at a solution.
> 

I'm not providing the name of the package because I don't need help
configuring it and I don't want the discussion to become how to do that.

> I can only conclude you just like to hear yourself scream. If only we were in 
> space…

I would float near you and SCREAM in your ear.  At least I have Brian
thinking that config.guess needs to change so it has helped some.

So, Vince, what is the triplet you like for x86_64 Cygwin?

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-19 Thread Yaakov Selkowitz
On 2017-10-19 14:08, cyg Simple wrote:
> On 10/19/2017 2:51 PM, Yaakov Selkowitz wrote:
>>
>> When you *really* need to use --build and/or --host, then you need to
>> use x86_64-pc-cygwin, as that is our chosen name.
> 
> Then config.guess needs to change to match the chosen name!!

No, it doesn't.  Don't confuse the default triplet with the chosen one.

> Why confuse everyone?  Make up your mind and choose one.

We have chosen one, and this is what everyone needs to use, and it does
NOT have to match the default.

> I can submit the patches to the config maintainer.

The code is correct as it is; the only thing needing to be changed here
is incorrect assumptions.

-- 
Yaakov



signature.asc
Description: OpenPGP digital signature


Re: Which is it -pc- or -unknown-

2017-10-19 Thread cyg Simple
On 10/19/2017 3:54 PM, Brian Inglis wrote:
> On 2017-10-19 12:59, Yaakov Selkowitz wrote:
>> On 2017-10-19 13:40, cyg Simple wrote:
>>> x86_64-pc-cygwin is just not correct regardless of the lack of past issues.
>>
>> As I have said several times, this assertion is incorrect.  You need to
>> use the triplet which matches the toolchain with which you are building.
>> For example, Fedora and RHEL all use $arch-redhat-linux as their
>> triplet, and there is nothing wrong with that.
> 
> Vendor -unknown- is just a default in various config cases, so specifying -pc-
> for consistency on Cygwin builds is a valid choice by the maintainers.
> 

FINE!  But config.guess should match the CHOSEN one.

> Perhaps a statement on the cygwin-apps list could clarify what should be done 
> by
> maintainers to ensure this override, and maybe retire the use of -unknown- by
> any Cygwin apps in future, with a notice to this (cygwin) list for those who
> choose to build packages from net sources.
> 

I don't care which is used as long as config.guess matches what is chosen.

> Perhaps also patches should be submitted to the config and automake 
> maintainers
> to ensure that {i*,x86_64}:CYGWIN*:*... always produce vendor -pc-. Not sure
> about vendors for {amd64,powerpcle}:CYGWIN*:*... in config.guess, which are
> currently also set to -unknown-.
> 

Exactly what I'm saying.  It needs to match what is being distributed
just for consistency and to avoid confusion.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-19 Thread Vince Rice
> On Oct 19, 2017, at 2:08 PM, cyg Simple  wrote:
> 
> On 10/19/2017 2:51 PM, Yaakov Selkowitz wrote:
>> 
>> When you *really* need to use --build and/or --host, then you need to
>> use x86_64-pc-cygwin, as that is our chosen name.
> 
> Then config.guess needs to change to match the chosen name!!
> 
> Why confuse everyone?  Make up your mind and choose one.  I can submit
> the patches to the config maintainer.

It's not confusing everyone. You're the only one jumping up and down, you have 
refused to provide information needed to help you, and in spite of that, Yaakov 
has given you a reasonable guess at a solution.

I can only conclude you just like to hear yourself scream. If only we were in 
space…
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-19 Thread Brian Inglis
On 2017-10-19 12:59, Yaakov Selkowitz wrote:
> On 2017-10-19 13:40, cyg Simple wrote:
>> x86_64-pc-cygwin is just not correct regardless of the lack of past issues.
> 
> As I have said several times, this assertion is incorrect.  You need to
> use the triplet which matches the toolchain with which you are building.
> For example, Fedora and RHEL all use $arch-redhat-linux as their
> triplet, and there is nothing wrong with that.

Vendor -unknown- is just a default in various config cases, so specifying -pc-
for consistency on Cygwin builds is a valid choice by the maintainers.

Perhaps a statement on the cygwin-apps list could clarify what should be done by
maintainers to ensure this override, and maybe retire the use of -unknown- by
any Cygwin apps in future, with a notice to this (cygwin) list for those who
choose to build packages from net sources.

Perhaps also patches should be submitted to the config and automake maintainers
to ensure that {i*,x86_64}:CYGWIN*:*... always produce vendor -pc-. Not sure
about vendors for {amd64,powerpcle}:CYGWIN*:*... in config.guess, which are
currently also set to -unknown-.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-19 Thread cyg Simple
On 10/19/2017 2:51 PM, Yaakov Selkowitz wrote:
> 
> When you *really* need to use --build and/or --host, then you need to
> use x86_64-pc-cygwin, as that is our chosen name.

Then config.guess needs to change to match the chosen name!!

Why confuse everyone?  Make up your mind and choose one.  I can submit
the patches to the config maintainer.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-19 Thread cyg Simple
On 10/19/2017 2:59 PM, Yaakov Selkowitz wrote:
> On 2017-10-19 13:40, cyg Simple wrote:
>> x86_64-pc-cygwin is just not correct regardless of the lack of past issues.
> 
> As I have said several times, this assertion is incorrect.  You need to
> use the triplet which matches the toolchain with which you are building.
>  For example, Fedora and RHEL all use $arch-redhat-linux as their
> triplet, and there is nothing wrong with that.

Yaakov, you have already stated that the triplet for Cygwin on x86_64
should be x86_64-unknown-cygwin.  That in itself makes it imperative
that the maintainers distribute a triplet toolchain that matches it.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-19 Thread Yaakov Selkowitz
On 2017-10-19 13:40, cyg Simple wrote:
> x86_64-pc-cygwin is just not correct regardless of the lack of past issues.

As I have said several times, this assertion is incorrect.  You need to
use the triplet which matches the toolchain with which you are building.
 For example, Fedora and RHEL all use $arch-redhat-linux as their
triplet, and there is nothing wrong with that.

-- 
Yaakov



signature.asc
Description: OpenPGP digital signature


Re: Which is it -pc- or -unknown-

2017-10-19 Thread Yaakov Selkowitz
On 2017-10-19 11:44, cyg Simple wrote:
> On 10/19/2017 11:04 AM, Yaakov Selkowitz wrote:
>> We've been building packages for 64-bit Cygwin for years now without a
>> problem.  Maybe you could just tell what you're trying to do and the
>> problem you're seeing so that we can assist you, instead of this
>> circular discussion of a nonexistent problem.
> 
> The scenario occurred when I was trying to configure a package and that
> package was refusing to accept the config.guess build triplet.

While you're still being vague (in terms of which package you are
building and exactly what the error is), that sounds like an issue with
(usually old) sources bundling an ancient config.{guess,sub} which
doesn't know about 64-bit Cygwin.  I have several packages like this.
cygport's gnuconfigize command is intended to help with such cases.

> So I decided to do
> 
> cyg=`/path/to/config.guess`; ./configure --host=$cyg --build=$cyg

This is incorrect.

> The configure couldn't find x86_64-unknown-cygwin-gcc.  When I looked in
> /usr/bin I found x86_64-pc-cygwin-gcc instead!!  So which is it, it
> cannot be both!

When you *really* need to use --build and/or --host, then you need to
use x86_64-pc-cygwin, as that is our chosen name.

-- 
Yaakov



signature.asc
Description: OpenPGP digital signature


Re: Which is it -pc- or -unknown-

2017-10-19 Thread cyg Simple
On 10/19/2017 2:37 PM, Steven Penny wrote:
> On Thu, 19 Oct 2017 12:47:29, cyg Simple wrote:
>> > may we know which package ?
>> > > If it refuses triplet has a strange way to use Autoconf/Automake
>> > and changing the compiler seems the wrong way to solve the issue
>>
>> No, it doesn't matter.  Delivering x86_64-pc-cygwin anything is wrong
>> since the triplet is x86_64-unknown-cygwin.
> 
> Wrong. It does matter. By failing to provide a package you are in
> violation of
> MCVE:
> 
> http://stackoverflow.com/help/mcve
> 
> and deserve 0 help. If you want help, you need to give people enough so
> that
> they can help you. Otherwise Yaakov is right:
> 
>> circular discussion of a nonexistent problem
> 

So you support the maintainers supplying an incorrect triplet?

x86_64-pc-cygwin is just not correct regardless of the lack of past issues.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-19 Thread Steven Penny

On Thu, 19 Oct 2017 12:47:29, cyg Simple wrote:

> may we know which package ?
> 
> If it refuses triplet has a strange way to use Autoconf/Automake

> and changing the compiler seems the wrong way to solve the issue

No, it doesn't matter.  Delivering x86_64-pc-cygwin anything is wrong
since the triplet is x86_64-unknown-cygwin.


Wrong. It does matter. By failing to provide a package you are in violation of
MCVE:

http://stackoverflow.com/help/mcve

and deserve 0 help. If you want help, you need to give people enough so that
they can help you. Otherwise Yaakov is right:


circular discussion of a nonexistent problem



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-19 Thread cyg Simple
On 10/19/2017 12:41 PM, Marco Atzeri wrote:
> On 19/10/2017 18:21, cyg Simple wrote:
> 

 ./configure --host=x86_64-unknown-cygwin --build=x86_64-unknown-cygwin
>>>
>>>
>>> the correct way is
>>>   ./configure
>>>
>>
>> Normally yes, but ...
>>
>>> don't add what you don't need..
>>
>> I was trying to help a package refusing the config.guess triplet so I
>> needed it.  Regardless delivering a target build of x86_64-pc-cygwin is
>> not correct!  It needs to be x86_64-unknown-cygwin.
> 
> may we know which package ?
> 
> If it refuses triplet has a strange way to use Autoconf/Automake
> and changing the compiler seems the wrong way to solve the issue

No, it doesn't matter.  Delivering x86_64-pc-cygwin anything is wrong
since the triplet is x86_64-unknown-cygwin.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-19 Thread cyg Simple
On 10/19/2017 11:04 AM, Yaakov Selkowitz wrote:
> On 2017-10-19 08:25, cyg Simple wrote:
>> On 10/18/2017 7:26 PM, Steven Penny wrote:
>>> On Wed, 18 Oct 2017 08:45:11, Marco Atzeri wrote:
 For a regex pattern you should include both.
 I do not bore which one is built and distributed on my packages.

 E.G. on octave

 /usr/lib/octave/site/oct/i686-pc-cygwin
 /usr/lib/octave/site/oct/x86_64-unknown-cygwin
>>>
>>> This is certainly not right. I can understand that we will have some
>>> discrepancies across packages, but having a different vendor in the same
>>> package
>>> is unacceptable. It suggests that x86_64-unknown-cygwin and i686-pc-cygwin
>>> differ in more ways that one, which they dont. you let it slide, then
>>> people
>>> start asking:
>>>
>>
>> I can live with the historical i*-pc-cygwin mishap.
>>
>>> - where is x86_64-pc-cygwin?
>>
>> This I cannot live with and the package maintainers need to target
>> x86_64-unknown-cygwin instead.  GCC has a target build of
>> x86_64-pc-cygwin, it needs corrected!
> 
> We've been building packages for 64-bit Cygwin for years now without a
> problem.  Maybe you could just tell what you're trying to do and the
> problem you're seeing so that we can assist you, instead of this
> circular discussion of a nonexistent problem.
> 

And I've used the products for years as well, that doesn't make the
product without fallacies.  It is either that config.guess is wrong and
the guess should be x86_64-pc-cygwin or the maintainers are wrong and
should provide host/target for x86_64-unknown-cygwin.  It is that
simple.  It has nothing to do with what I was trying to do when I
discovered the issue; it is an issue.

The scenario occurred when I was trying to configure a package and that
package was refusing to accept the config.guess build triplet.  So I
decided to do

cyg=`/path/to/config.guess`; ./configure --host=$cyg --build=$cyg

The configure couldn't find x86_64-unknown-cygwin-gcc.  When I looked in
/usr/bin I found x86_64-pc-cygwin-gcc instead!!  So which is it, it
cannot be both!

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-19 Thread Marco Atzeri

On 19/10/2017 18:21, cyg Simple wrote:



./configure --host=x86_64-unknown-cygwin --build=x86_64-unknown-cygwin



the correct way is
  ./configure



Normally yes, but ...


don't add what you don't need..


I was trying to help a package refusing the config.guess triplet so I
needed it.  Regardless delivering a target build of x86_64-pc-cygwin is
not correct!  It needs to be x86_64-unknown-cygwin.


may we know which package ?

If it refuses triplet has a strange way to use Autoconf/Automake
and changing the compiler seems the wrong way to solve the issue


Regards
Marco



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-19 Thread cyg Simple
On 10/19/2017 10:41 AM, Marco Atzeri wrote:
> On 19/10/2017 15:17, cyg Simple wrote:
>>
>>
> 

 So the corrective action is to distribute GCC and friends as
 x86_64-unknown-cygwin-*.exe instead of x86_64-pc-cygwin-*.exe.
>>>
>>> Incorrect.  GCC is also fine as is.
>>>
>>
>> No it is not!  The below example should work out of the box and it
>> doesn't.
>>
>> ./configure --host=x86_64-unknown-cygwin --build=x86_64-unknown-cygwin
> 
> 
> the correct way is
>  ./configure
> 

Normally yes, but ...

> don't add what you don't need..

I was trying to help a package refusing the config.guess triplet so I
needed it.  Regardless delivering a target build of x86_64-pc-cygwin is
not correct!  It needs to be x86_64-unknown-cygwin.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-19 Thread cyg Simple
On 10/19/2017 10:18 AM, Ken Brown wrote:
> On 10/19/2017 9:19 AM, cyg Simple wrote:
>> On 10/18/2017 6:58 PM, JonY wrote:
>>> I agree with Yaakov, why does it need to change?
>>>
>>
>> See my response to Yaakov.  If you supply explicit host and build to
>> configure it does not work.
> 
> So don't do that.  Specifying host is for cross-compilation.  Specifying
> build without host is for overriding the result of config.guess (never
> necessary on Cygwin).  See
> 
> 
> https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html
> 
> 
> In particular:  "If you mean to override the result of config.guess, use
> --build, not --host, since the latter enables cross-compilation."
> 

So?! It is still incorrect for the --target of the GCC build to be
x86_64-pc-cygwin.  My example didn't specify a different build from
host.  I ran across this from a package that was refusing to accept the
config.guess build triplet so I tried specifying both.  At that point it
failed to find x86_64-unknown-cygwin-gcc.

And ./configure --build=`/path/to/config.guess` will not work either as
currently delivered.

x86_64-pc-cygwin IS NOT CORRECT.  It needs fixed in the build process.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-19 Thread Yaakov Selkowitz
On 2017-10-19 08:25, cyg Simple wrote:
> On 10/18/2017 7:26 PM, Steven Penny wrote:
>> On Wed, 18 Oct 2017 08:45:11, Marco Atzeri wrote:
>>> For a regex pattern you should include both.
>>> I do not bore which one is built and distributed on my packages.
>>>
>>> E.G. on octave
>>>
>>> /usr/lib/octave/site/oct/i686-pc-cygwin
>>> /usr/lib/octave/site/oct/x86_64-unknown-cygwin
>>
>> This is certainly not right. I can understand that we will have some
>> discrepancies across packages, but having a different vendor in the same
>> package
>> is unacceptable. It suggests that x86_64-unknown-cygwin and i686-pc-cygwin
>> differ in more ways that one, which they dont. you let it slide, then
>> people
>> start asking:
>>
> 
> I can live with the historical i*-pc-cygwin mishap.
> 
>> - where is x86_64-pc-cygwin?
> 
> This I cannot live with and the package maintainers need to target
> x86_64-unknown-cygwin instead.  GCC has a target build of
> x86_64-pc-cygwin, it needs corrected!

We've been building packages for 64-bit Cygwin for years now without a
problem.  Maybe you could just tell what you're trying to do and the
problem you're seeing so that we can assist you, instead of this
circular discussion of a nonexistent problem.

-- 
Yaakov



signature.asc
Description: OpenPGP digital signature


Re: Which is it -pc- or -unknown-

2017-10-19 Thread Marco Atzeri

On 19/10/2017 15:25, cyg Simple wrote:

On 10/18/2017 7:26 PM, Steven Penny wrote:

On Wed, 18 Oct 2017 08:45:11, Marco Atzeri wrote:

For a regex pattern you should include both.
I do not bore which one is built and distributed on my packages.

E.G. on octave

/usr/lib/octave/site/oct/i686-pc-cygwin
/usr/lib/octave/site/oct/x86_64-unknown-cygwin


This is certainly not right. I can understand that we will have some
discrepancies across packages, but having a different vendor in the same
package
is unacceptable. It suggests that x86_64-unknown-cygwin and i686-pc-cygwin
differ in more ways that one, which they dont. you let it slide, then
people
start asking:



I can live with the historical i*-pc-cygwin mishap.


- where is x86_64-pc-cygwin?


This I cannot live with and the package maintainers need to target
x86_64-unknown-cygwin instead.  GCC has a target build of
x86_64-pc-cygwin, it needs corrected!


It seems all cygwin package maintainers have no problem.
So are you causing yourself a not-existing problem ?






--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-19 Thread Marco Atzeri

On 19/10/2017 15:17, cyg Simple wrote:







So the corrective action is to distribute GCC and friends as
x86_64-unknown-cygwin-*.exe instead of x86_64-pc-cygwin-*.exe.


Incorrect.  GCC is also fine as is.



No it is not!  The below example should work out of the box and it doesn't.

./configure --host=x86_64-unknown-cygwin --build=x86_64-unknown-cygwin



the correct way is
 ./configure

don't add what you don't need..


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-19 Thread Ken Brown

On 10/19/2017 9:19 AM, cyg Simple wrote:

On 10/18/2017 6:58 PM, JonY wrote:

I agree with Yaakov, why does it need to change?



See my response to Yaakov.  If you supply explicit host and build to
configure it does not work.


So don't do that.  Specifying host is for cross-compilation.  Specifying 
build without host is for overriding the result of config.guess (never 
necessary on Cygwin).  See



https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html

In particular:  "If you mean to override the result of config.guess, use 
--build, not --host, since the latter enables cross-compilation."


Ken

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-19 Thread cyg Simple
On 10/18/2017 7:26 PM, Steven Penny wrote:
> On Wed, 18 Oct 2017 08:45:11, Marco Atzeri wrote:
>> For a regex pattern you should include both.
>> I do not bore which one is built and distributed on my packages.
>>
>> E.G. on octave
>>
>> /usr/lib/octave/site/oct/i686-pc-cygwin
>> /usr/lib/octave/site/oct/x86_64-unknown-cygwin
> 
> This is certainly not right. I can understand that we will have some
> discrepancies across packages, but having a different vendor in the same
> package
> is unacceptable. It suggests that x86_64-unknown-cygwin and i686-pc-cygwin
> differ in more ways that one, which they dont. you let it slide, then
> people
> start asking:
> 

I can live with the historical i*-pc-cygwin mishap.

> - where is x86_64-pc-cygwin?

This I cannot live with and the package maintainers need to target
x86_64-unknown-cygwin instead.  GCC has a target build of
x86_64-pc-cygwin, it needs corrected!

> - where is i686-unknown-cygwin?
> 

This should never exist under the current scheme.  It should always be
i*-pc-cygwin.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-19 Thread cyg Simple
On 10/18/2017 6:58 PM, JonY wrote:
> On 10/18/2017 10:41 PM, Yaakov Selkowitz wrote:
>> On 2017-10-18 14:10, cyg Simple wrote:
>>> On 10/18/2017 1:11 PM, Yaakov Selkowitz wrote:
 On 2017-10-18 09:05, cyg Simple wrote:
> Does anyone care if a patch to config.guess changes the i*:CYGWIN*:*
> filter to echo ${UNAME_MACHINE}-unknown-cygwin?

 That would be incorrect.  config.guess is fine as it is.
>>>
>>> So the corrective action is to distribute GCC and friends as
>>> x86_64-unknown-cygwin-*.exe instead of x86_64-pc-cygwin-*.exe.
>>
>> Incorrect.  GCC is also fine as is.
>>
> 
> I agree with Yaakov, why does it need to change?
> 

See my response to Yaakov.  If you supply explicit host and build to
configure it does not work.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-19 Thread cyg Simple


On 10/18/2017 6:41 PM, Yaakov Selkowitz wrote:
> On 2017-10-18 14:10, cyg Simple wrote:
>> On 10/18/2017 1:11 PM, Yaakov Selkowitz wrote:
>>> On 2017-10-18 09:05, cyg Simple wrote:
 Does anyone care if a patch to config.guess changes the i*:CYGWIN*:*
 filter to echo ${UNAME_MACHINE}-unknown-cygwin?
>>>
>>> That would be incorrect.  config.guess is fine as it is.
>>
>> So the corrective action is to distribute GCC and friends as
>> x86_64-unknown-cygwin-*.exe instead of x86_64-pc-cygwin-*.exe.
> 
> Incorrect.  GCC is also fine as is.
> 

No it is not!  The below example should work out of the box and it doesn't.

./configure --host=x86_64-unknown-cygwin --build=x86_64-unknown-cygwin

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-18 Thread Yaakov Selkowitz
On 2017-10-18 18:26, Steven Penny wrote:
> On Wed, 18 Oct 2017 08:45:11, Marco Atzeri wrote:
>> For a regex pattern you should include both.
>> I do not bore which one is built and distributed on my packages.
>>
>> E.G. on octave
>>
>> /usr/lib/octave/site/oct/i686-pc-cygwin
>> /usr/lib/octave/site/oct/x86_64-unknown-cygwin
> 
> This is certainly not right. I can understand that we will have some
> discrepancies across packages, but having a different vendor in the same
> package is unacceptable.

According to whom?  'pc' is the default vendor for i*86 for historical
reasons, but 'unknown' is the default for most other architectures.
There really isn't anything unusual here.

-- 
Yaakov



signature.asc
Description: OpenPGP digital signature


Re: Which is it -pc- or -unknown-

2017-10-18 Thread Steven Penny

On Wed, 18 Oct 2017 08:45:11, Marco Atzeri wrote:

For a regex pattern you should include both.
I do not bore which one is built and distributed on my packages.

E.G. on octave

/usr/lib/octave/site/oct/i686-pc-cygwin
/usr/lib/octave/site/oct/x86_64-unknown-cygwin


This is certainly not right. I can understand that we will have some
discrepancies across packages, but having a different vendor in the same package
is unacceptable. It suggests that x86_64-unknown-cygwin and i686-pc-cygwin
differ in more ways that one, which they dont. you let it slide, then people
start asking:

- where is x86_64-pc-cygwin?
- where is i686-unknown-cygwin?

which are both valid questions when a package maintainer does dumb stuff like
this. just realized that for octave package, that is you:

http://cygwin.com/cygwin-pkg-maint

point still stands


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-18 Thread JonY
On 10/18/2017 10:41 PM, Yaakov Selkowitz wrote:
> On 2017-10-18 14:10, cyg Simple wrote:
>> On 10/18/2017 1:11 PM, Yaakov Selkowitz wrote:
>>> On 2017-10-18 09:05, cyg Simple wrote:
 Does anyone care if a patch to config.guess changes the i*:CYGWIN*:*
 filter to echo ${UNAME_MACHINE}-unknown-cygwin?
>>>
>>> That would be incorrect.  config.guess is fine as it is.
>>
>> So the corrective action is to distribute GCC and friends as
>> x86_64-unknown-cygwin-*.exe instead of x86_64-pc-cygwin-*.exe.
> 
> Incorrect.  GCC is also fine as is.
> 

I agree with Yaakov, why does it need to change?



signature.asc
Description: OpenPGP digital signature


Re: Which is it -pc- or -unknown-

2017-10-18 Thread Yaakov Selkowitz
On 2017-10-18 14:10, cyg Simple wrote:
> On 10/18/2017 1:11 PM, Yaakov Selkowitz wrote:
>> On 2017-10-18 09:05, cyg Simple wrote:
>>> Does anyone care if a patch to config.guess changes the i*:CYGWIN*:*
>>> filter to echo ${UNAME_MACHINE}-unknown-cygwin?
>>
>> That would be incorrect.  config.guess is fine as it is.
> 
> So the corrective action is to distribute GCC and friends as
> x86_64-unknown-cygwin-*.exe instead of x86_64-pc-cygwin-*.exe.

Incorrect.  GCC is also fine as is.

-- 
Yaakov



signature.asc
Description: OpenPGP digital signature


Re: Which is it -pc- or -unknown-

2017-10-18 Thread Brian Inglis
On 2017-10-18 13:10, cyg Simple wrote:
> On 10/18/2017 1:11 PM, Yaakov Selkowitz wrote:
>> On 2017-10-18 09:05, cyg Simple wrote:
>>> Does anyone care if a patch to config.guess changes the i*:CYGWIN*:*
>>> filter to echo ${UNAME_MACHINE}-unknown-cygwin?
>>
>> That would be incorrect.  config.guess is fine as it is.
>>
> 
> So the corrective action is to distribute GCC and friends as
> x86_64-unknown-cygwin-*.exe instead of x86_64-pc-cygwin-*.exe.
> 
> MAINTAINERS: Please take note for your next releases.

Does this mean 64 bit binutils needs rebuilt with current config.guess to be
found by an updated gcc, or is there a different config option for that triplet?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-18 Thread cyg Simple
On 10/18/2017 1:11 PM, Yaakov Selkowitz wrote:
> On 2017-10-18 09:05, cyg Simple wrote:
>> Does anyone care if a patch to config.guess changes the i*:CYGWIN*:*
>> filter to echo ${UNAME_MACHINE}-unknown-cygwin?
> 
> That would be incorrect.  config.guess is fine as it is.
> 

So the corrective action is to distribute GCC and friends as
x86_64-unknown-cygwin-*.exe instead of x86_64-pc-cygwin-*.exe.

MAINTAINERS: Please take note for your next releases.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-18 Thread Yaakov Selkowitz
On 2017-10-18 09:05, cyg Simple wrote:
> Does anyone care if a patch to config.guess changes the i*:CYGWIN*:*
> filter to echo ${UNAME_MACHINE}-unknown-cygwin?

That would be incorrect.  config.guess is fine as it is.

-- 
Yaakov



signature.asc
Description: OpenPGP digital signature


Re: Which is it -pc- or -unknown-

2017-10-18 Thread cyg Simple
On 10/17/2017 3:16 PM, cyg Simple wrote:
> The config.guess file[1] is confused.
> 
> 840i*:CYGWIN*:*)
> 841   echo ${UNAME_MACHINE}-pc-cygwin
> 842   exit ;;
> -
> 870amd64:CYGWIN*:*:* | x86_64:CYGWIN*:*:*)
> 871   echo x86_64-unknown-cygwin
> 872   exit ;;
> 
> The GCC executable is x86_64-pc-cygwin-gcc.exe but config.guess on my
> system gives x86_64-unknown-cygwin so specifying a fully qualified host
> doesn't find the executable file.  So which should it be?
> 
> [1]http://git.savannah.gnu.org/cgit/config.git/tree/config.guess?id=c003e5cb947924ca5edd25c3b840aaa373c66b28
> 

Does anyone care if a patch to config.guess changes the i*:CYGWIN*:*
filter to echo ${UNAME_MACHINE}-unknown-cygwin?

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-18 Thread Brian Inglis
On 2017-10-18 00:45, Marco Atzeri wrote:
> On 18/10/2017 05:29, cyg Simple wrote:
>> On 10/17/2017 7:49 PM, Brian Inglis wrote:
>>> On 2017-10-17 13:16, cyg Simple wrote:
>> I'm only concerned with Cygwin at the moment.  As I understand it the we
>> should distribute x86[_64]-unknown-cygwin-*.exe and not as
>> x86[_64]-pc-cygwin-*.exe  We also need to correct config.guess for the
>> i*:CYGWIN*:* match.
> it is irrelevant as x86[_64]-unknown-cygwin-*.exe and
> x86[_64]-pc-cygwin-*.exe are equivalent.
> And usually it is not x86 but i686
>  $ arch
> i686
> For a regex pattern you should include both.
> I do not care which one is built and distributed on my packages.
> E.G. on octave
> /usr/lib/octave/site/oct/i686-pc-cygwin
> /usr/lib/octave/site/oct/x86_64-unknown-cygwin

Do gcc... and binutils have to match so the front end can find the build tools
or are there config options for binutils triplet or vendor?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-18 Thread Marco Atzeri

On 18/10/2017 05:29, cyg Simple wrote:

On 10/17/2017 7:49 PM, Brian Inglis wrote:

On 2017-10-17 13:16, cyg Simple wrote:




I'm only concerned with Cygwin at the moment.  As I understand it the we
should distribute x86[_64]-unknown-cygwin-*.exe and not as
x86[_64]-pc-cygwin-*.exe  We also need to correct config.guess for the
i*:CYGWIN*:* match.



it is irrelevant as x86[_64]-unknown-cygwin-*.exe and
x86[_64]-pc-cygwin-*.exe are equivalent.

And usually it is not x86 but i686

 $ arch
i686

For a regex pattern you should include both.
I do not bore which one is built and distributed on my packages.

E.G. on octave

/usr/lib/octave/site/oct/i686-pc-cygwin
/usr/lib/octave/site/oct/x86_64-unknown-cygwin


Regards
Marco

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-17 Thread Brian Inglis
On 2017-10-17 21:29, cyg Simple wrote:
> On 10/17/2017 7:49 PM, Brian Inglis wrote:
>> On 2017-10-17 13:16, cyg Simple wrote:
>>> The config.guess file[1] is confused.
>>>
>>> 840i*:CYGWIN*:*)
>>> 841 echo ${UNAME_MACHINE}-pc-cygwin
>>> 842 exit ;;
>>> -
>>> 870amd64:CYGWIN*:*:* | x86_64:CYGWIN*:*:*)
>>> 871 echo x86_64-unknown-cygwin
>>> 872 exit ;;
>>>
>>> The GCC executable is x86_64-pc-cygwin-gcc.exe but config.guess on my
>>> system gives x86_64-unknown-cygwin so specifying a fully qualified host
>>> doesn't find the executable file.  So which should it be?
>>>
>>> [1]http://git.savannah.gnu.org/cgit/config.git/tree/config.guess?id=c003e5cb947924ca5edd25c3b840aaa373c66b28
>>
>> There are also similar confusions and differences between projects and 
>> distros
>> about use of x86_64 (or x86-64) and amd64. You may have come across others.
>>
> 
> I'm only concerned with Cygwin at the moment.  As I understand it the we
> should distribute x86[_64]-unknown-cygwin-*.exe and not as
> x86[_64]-pc-cygwin-*.exe  We also need to correct config.guess for the
> i*:CYGWIN*:* match.

It seems that i686-pc-... on lines 840... is common, probably for historical
reasons, and that may be okay for 32 bit builds but I don't know the Cygwin
history here, and x86_64-unknown-... should be selected for 64 bit builds in
lines 870...
Packages for current 32 and 64 bit binutils, cygwin32-..., and gcc... are
prefixed with or found under {i686,x86_64}-pc-cygwin, so you might have to
change the vendor field in config.guess, if you want to stay consistent.
Packages emacs, octave, and pkg-config are the only ones I can find using
x86_64-unknown-cygwin prefix on 64 bit, none with i686-unknown-cygwin on 32 bit.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-17 Thread cyg Simple
On 10/17/2017 7:49 PM, Brian Inglis wrote:
> On 2017-10-17 13:16, cyg Simple wrote:
>> The config.guess file[1] is confused.
>>
>> 840i*:CYGWIN*:*)
>> 841  echo ${UNAME_MACHINE}-pc-cygwin
>> 842  exit ;;
>> -
>> 870amd64:CYGWIN*:*:* | x86_64:CYGWIN*:*:*)
>> 871  echo x86_64-unknown-cygwin
>> 872  exit ;;
>>
>> The GCC executable is x86_64-pc-cygwin-gcc.exe but config.guess on my
>> system gives x86_64-unknown-cygwin so specifying a fully qualified host
>> doesn't find the executable file.  So which should it be?
>>
>> [1]http://git.savannah.gnu.org/cgit/config.git/tree/config.guess?id=c003e5cb947924ca5edd25c3b840aaa373c66b28
> 
> There are also similar confusions and differences between projects and distros
> about use of x86_64 (or x86-64) and amd64. You may have come across others.
> 

I'm only concerned with Cygwin at the moment.  As I understand it the we
should distribute x86[_64]-unknown-cygwin-*.exe and not as
x86[_64]-pc-cygwin-*.exe  We also need to correct config.guess for the
i*:CYGWIN*:* match.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-17 Thread cyg Simple


On 10/17/2017 7:39 PM, Brian Inglis wrote:
> On 2017-10-17 15:31, cyg Simple wrote:
>> On 10/17/2017 3:45 PM, Brian Inglis wrote:
>>> On 2017-10-17 13:16, cyg Simple wrote:
 The config.guess file[1] is confused.
 840i*:CYGWIN*:*)
 841echo ${UNAME_MACHINE}-pc-cygwin
 842exit ;;
 -
 870amd64:CYGWIN*:*:* | x86_64:CYGWIN*:*:*)
 871echo x86_64-unknown-cygwin
 872exit ;;
 The GCC executable is x86_64-pc-cygwin-gcc.exe but config.guess on my
 system gives x86_64-unknown-cygwin so specifying a fully qualified host
 doesn't find the executable file.  So which should it be?
 [1]http://git.savannah.gnu.org/cgit/config.git/tree/config.guess?id=c003e5cb947924ca5edd25c3b840aaa373c66b28
>>> That part of the triplet is defined as vendor, so it was probably initially
>>> Intel, then compatibles came out and that was genericized to PC, then 
>>> someone
>>> objected and discussed and came up with Unknown, rather than say Any or 
>>> None.
>>> It may reflect development ages of projects, autotools, defaults on 
>>> projects, or
>>> project politics.
>>> Some projects still use PC, which may be a project override, others use 
>>> Unknown,
>>> which should be the default in current releases of autotools.
>> So config.guess needs to change, correct?  I thought the I had
>> remembered the discussion that it should be -unknown- for Cygwin.  But
>> the GCC distribution is giving us -pc- instead which means the
>> maintainer specified the target as such.  That needs to change as well.
>> I'm on x86_64 I bet x86 will be -pc- from config.guess just by the way
>> it's coded.  Confusing!
> 
> You might want to diff the upstream config.{guess,sub} with those from
> /usr/share/automake1.{14,15}/ as those are the latest, and earlier releases to
> see if they are just old, in case there are project customizations.
> You can then decide whether you want to look further at how much of the 
> project
> automake infrastructure you want to upgrade, or check if the project has 
> looked
> at, or is working on, doing that.
> If you do so, you could look at offering that back upstream.
> 

Brian, I quoted the git master of config.guess in my original mail.

My concern is that on my 64bit Cygwin version config.guess guesses the
build as x86_64-unknown-cygwin but x86_64-pc-cygwin-gcc.exe is
distributed.  Therefore there is a mismatch between what the maintainer
gives us from the GCC distribution and what the upstream config.guess
gives us.  This leads to not being able to find
x86_64-unknown-cygwin-gcc.exe.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-17 Thread Brian Inglis
On 2017-10-17 13:16, cyg Simple wrote:
> The config.guess file[1] is confused.
> 
> 840i*:CYGWIN*:*)
> 841   echo ${UNAME_MACHINE}-pc-cygwin
> 842   exit ;;
> -
> 870amd64:CYGWIN*:*:* | x86_64:CYGWIN*:*:*)
> 871   echo x86_64-unknown-cygwin
> 872   exit ;;
> 
> The GCC executable is x86_64-pc-cygwin-gcc.exe but config.guess on my
> system gives x86_64-unknown-cygwin so specifying a fully qualified host
> doesn't find the executable file.  So which should it be?
> 
> [1]http://git.savannah.gnu.org/cgit/config.git/tree/config.guess?id=c003e5cb947924ca5edd25c3b840aaa373c66b28

There are also similar confusions and differences between projects and distros
about use of x86_64 (or x86-64) and amd64. You may have come across others.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-17 Thread Brian Inglis
On 2017-10-17 15:31, cyg Simple wrote:
> On 10/17/2017 3:45 PM, Brian Inglis wrote:
>> On 2017-10-17 13:16, cyg Simple wrote:
>>> The config.guess file[1] is confused.
>>> 840i*:CYGWIN*:*)
>>> 841 echo ${UNAME_MACHINE}-pc-cygwin
>>> 842 exit ;;
>>> -
>>> 870amd64:CYGWIN*:*:* | x86_64:CYGWIN*:*:*)
>>> 871 echo x86_64-unknown-cygwin
>>> 872 exit ;;
>>> The GCC executable is x86_64-pc-cygwin-gcc.exe but config.guess on my
>>> system gives x86_64-unknown-cygwin so specifying a fully qualified host
>>> doesn't find the executable file.  So which should it be?
>>> [1]http://git.savannah.gnu.org/cgit/config.git/tree/config.guess?id=c003e5cb947924ca5edd25c3b840aaa373c66b28
>> That part of the triplet is defined as vendor, so it was probably initially
>> Intel, then compatibles came out and that was genericized to PC, then someone
>> objected and discussed and came up with Unknown, rather than say Any or None.
>> It may reflect development ages of projects, autotools, defaults on 
>> projects, or
>> project politics.
>> Some projects still use PC, which may be a project override, others use 
>> Unknown,
>> which should be the default in current releases of autotools.
> So config.guess needs to change, correct?  I thought the I had
> remembered the discussion that it should be -unknown- for Cygwin.  But
> the GCC distribution is giving us -pc- instead which means the
> maintainer specified the target as such.  That needs to change as well.
> I'm on x86_64 I bet x86 will be -pc- from config.guess just by the way
> it's coded.  Confusing!

You might want to diff the upstream config.{guess,sub} with those from
/usr/share/automake1.{14,15}/ as those are the latest, and earlier releases to
see if they are just old, in case there are project customizations.
You can then decide whether you want to look further at how much of the project
automake infrastructure you want to upgrade, or check if the project has looked
at, or is working on, doing that.
If you do so, you could look at offering that back upstream.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-17 Thread cyg Simple
On 10/17/2017 3:45 PM, Brian Inglis wrote:
> On 2017-10-17 13:16, cyg Simple wrote:
>> The config.guess file[1] is confused.
>>
>> 840i*:CYGWIN*:*)
>> 841  echo ${UNAME_MACHINE}-pc-cygwin
>> 842  exit ;;
>> -
>> 870amd64:CYGWIN*:*:* | x86_64:CYGWIN*:*:*)
>> 871  echo x86_64-unknown-cygwin
>> 872  exit ;;
>>
>> The GCC executable is x86_64-pc-cygwin-gcc.exe but config.guess on my
>> system gives x86_64-unknown-cygwin so specifying a fully qualified host
>> doesn't find the executable file.  So which should it be?
>>
>> [1]http://git.savannah.gnu.org/cgit/config.git/tree/config.guess?id=c003e5cb947924ca5edd25c3b840aaa373c66b28
> 
> That part of the triplet is defined as vendor, so it was probably initially
> Intel, then compatibles came out and that was genericized to PC, then someone
> objected and discussed and came up with Unknown, rather than say Any or None.
> It may reflect development ages of projects, autotools, defaults on projects, 
> or
> project politics.
> Some projects still use PC, which may be a project override, others use 
> Unknown,
> which should be the default in current releases of autotools.
> 

So config.guess needs to change, correct?  I thought the I had
remembered the discussion that it should be -unknown- for Cygwin.  But
the GCC distribution is giving us -pc- instead which means the
maintainer specified the target as such.  That needs to change as well.

I'm on x86_64 I bet x86 will be -pc- from config.guess just by the way
it's coded.  Confusing!

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: Which is it -pc- or -unknown-

2017-10-17 Thread Brian Inglis
On 2017-10-17 13:16, cyg Simple wrote:
> The config.guess file[1] is confused.
> 
> 840i*:CYGWIN*:*)
> 841   echo ${UNAME_MACHINE}-pc-cygwin
> 842   exit ;;
> -
> 870amd64:CYGWIN*:*:* | x86_64:CYGWIN*:*:*)
> 871   echo x86_64-unknown-cygwin
> 872   exit ;;
> 
> The GCC executable is x86_64-pc-cygwin-gcc.exe but config.guess on my
> system gives x86_64-unknown-cygwin so specifying a fully qualified host
> doesn't find the executable file.  So which should it be?
> 
> [1]http://git.savannah.gnu.org/cgit/config.git/tree/config.guess?id=c003e5cb947924ca5edd25c3b840aaa373c66b28

That part of the triplet is defined as vendor, so it was probably initially
Intel, then compatibles came out and that was genericized to PC, then someone
objected and discussed and came up with Unknown, rather than say Any or None.
It may reflect development ages of projects, autotools, defaults on projects, or
project politics.
Some projects still use PC, which may be a project override, others use Unknown,
which should be the default in current releases of autotools.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple