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

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

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

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

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

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

[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: No error messages printed out within Windows Command Prompt when shared libraries are not found

[Luca]

Sorry, I have just realized that the issue happens only when I use the "Windows 
Command Prompt" run by Total Commander (www.ghisler.com), while I correctly get 
the notification when using the "Windows Command Prompt" run from the Start 
Menu. This issue is actually related to Total Commander, so I am reporting it 
on the Total Commander forum.
--
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: [PATCH] Revert "Don't override a Keep selection"

[Ken Brown]

On 10/19/2017 11:05 AM, Ken Brown wrote:

On 10/18/2017 11:01 PM, Ken Brown wrote:

On 10/17/2017 3:31 PM, Ken Brown wrote:

On 10/17/2017 2:43 PM, Jon Turney wrote:

On 16/10/2017 20:13, Ken Brown wrote:

This reverts (the rest of) commit b43b697.  Part of that commit was
already reverted in commit ff0bb3d.  The rest is not needed either
since we no longer send the upgrade flag to the solver after the user
has made their selections.
---
  libsolv.cc | 14 +++---
  libsolv.h  |  1 -
  package_meta.h |  2 --
  3 files changed, 3 insertions(+), 14 deletions(-)


Hmm... not sure about this.

Say the initial upgrade solution had something like: package A 1.0 
-> 1.1, and A 1.1 has a dependency on package B 2.0, where currently 
B 1.0 is installed (so B 1.0 -> 2.0)


If the user then changes B to 'keep' (at 1.0), we should report a 
conflict?


Good point.  I wasn't thinking about dependencies with version 
relations.


I just tested this scenario, and it turns out that putting a lock on B 
1.0 overrides the dependency of A 1.1 on B 2.0.  There's no problem 
reported.  On the other hand, if there's no lock, then the dependency 
overrides the Keep choice, again with no problem reported.


Back to the drawing board.


Thinking about this further, using SOLVER_LOCK is probably the right 
thing to do in this situation, even if no problem is reported.  We can't 
insist that users install the recommended version.  For example, if I 
choose to downgrade binutils while keeping the current gcc, then I'm 
responsible for any breakage this might cause, with or without a warning 
from setup.


I'll prepare a new patch that restores the SOLVER_LOCK functionality 
that was inadvertently removed in commit ff0bb3d.


Attached.  I kept making mistakes while doing this, so I hope I got it 
right in the end.


Here's a related question.  Currently if libsolv decides I should 
install something and I choose Skip instead, it will get installed 
anyway (with no problem report).  Maybe we should have a taskSkip that 
generates a SOLVER_LOCK in that case, analogous to taskKeep?


Ken
From 610426eabeccb3c04bbd7f49862248beb82b280a Mon Sep 17 00:00:00 2001
From: Ken Brown 
Date: Thu, 19 Oct 2017 14:44:45 -0400
Subject: [PATCH] Fix the functionality of taskKeep

A taskKeep is generated whenever the user wants to keep an installed
version that's different from the default_version, where the latter is
whatever the solver has chosen.  We need to make sure that
default_version is set appropriately wherever it is needed.
---
 choose.cc  |  7 +++
 libsolv.cc | 11 ++-
 package_meta.h |  2 +-
 prereq.cc  |  3 +--
 4 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/choose.cc b/choose.cc
index f0e6802..ad37639 100644
--- a/choose.cc
+++ b/choose.cc
@@ -420,6 +420,13 @@ ChooserPage::changeTrust(int button, bool test, bool 
initial)
 {
   // but initially we want a task list with any package changes caused by
   // command line options
+  // and we don't want to generate spurious Keep tasks
+  for (packagedb::packagecollection::iterator p = db.packages.begin ();
+  p != db.packages.end (); ++p)
+   {
+ packagemeta *pkg = p->second;
+ pkg->default_version = pkg->installed;
+   }
   q.setTasks();
 }
   db.defaultTrust(q, mode, test);
diff --git a/libsolv.cc b/libsolv.cc
index 289f19c..e623555 100644
--- a/libsolv.cc
+++ b/libsolv.cc
@@ -526,7 +526,8 @@ SolverTasks::setTasks()
 
   // decode UI state to action
   // skip and keep don't change dependency solution
-  // except when we want to keep an old version
+  // except when we want to keep a version different from the one
+  // chosen by the solver
   if (pkg->installed != pkg->desired)
 {
   if (pkg->desired)
@@ -538,7 +539,7 @@ SolverTasks::setTasks()
{
  if (pkg->picked())
add(pkg->installed, taskReinstall); // reinstall
- else if (pkg->installed < pkg->default_version)
+ else if (pkg->installed != pkg->default_version)
add(pkg->installed, taskKeep); // keep
}
   // only install action makes sense for source packages
@@ -591,7 +592,7 @@ SolverSolution::trans2db() const
i != db.packages.end(); i++)
 {
   packagemeta *pkg = i->second;
-  pkg->desired = pkg->installed;
+  pkg->desired = pkg->default_version = pkg->installed;
   pkg->pick(false);
 }
   // Now make changes according to trans.  transErase requires some
@@ -614,7 +615,7 @@ SolverSolution::trans2db() const
case SolverTransaction::transInstall:
  if (pv.Type() == package_binary)
{
- pkg->desired  = pv;
+ pkg->desired = pkg->default_version = pv;
  pkg->pick(true);
}
  else  // source package
@@ -623,7 +624,7 @@ SolverSolution::trans2db() const
case 

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

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

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

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

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

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

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

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

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

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

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

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

[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

Problem with Fossil version

[Will Parsons]

I've been using fossil as my SCM system of choice for some years now, and
have been in the habit of synching my repositories under Cygwin with those on
a remote Unix (FreeBSD) system.  Recently, though, I created a new repository
under FreeBSD and found I cannot clone it to Cygwin.

Apparently, this is due to an upgrade to fossil on the FreeBSD side, which is
now at version 2.2 while the Cygwin version is still 1.34, which seems to
date back to 2015.  Is there a specific reason the Cygwin fossil hasn't been
upgraded to a 2.x version?

-- 
Will


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

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

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

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

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

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

[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: [Attn. Maintainers] Perl 5.26.1 (release is imminent)

[Achim Gratz]

Yaakov Selkowitz writes:
>> git-svn:  Subversion compatibility support for Git version control 
>> system
>> git:  Distributed version control system
>
> Adam, git will break if it doesn't get rebuilt and uploaded together
> with the 5.26 upgrade.  How soon can you rebuild it with Achim's repo?

The core git functionality is not affected or I would have noticed, but
yes it'd be nice if git could be updated in sync also.  Adam?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [setup topic/libsolv] Packages contained in multiple repositories

[Achim Gratz]

Jon Turney writes:
>> Extrapolating from my experience with zypper, libsolv should stick with
>> the repo the installed package comes from even if some other repo has a
>> newer version.
>
> Unfortunately, we are limited by the fact that installed.db doesn't
> record which repo an installed package came from.

Which is something we might eventually change, but yes, we can't use
that information at the moment if we can't figure out the sourtce repo
by looking at the version.

> We map repo setup.ini release: labels to package vendor names, so we
> assume it's 'Cygwin' for an installed package (package_db.cc:115), and
> run the solver with SOLVER_FLAG_ALLOW_VENDORCHANGE on (libsolv.cc:745)
> to allow it to get upgraded by a package in the repo it actually came
> from, but we've forgotten.

Well actually zypper does the same thing if you have a package
installed, but it's gone from the repos (we'd call that an orphan
package): it'll show up as "@System" instead of the repo it came from
originally.

> I'm not overly concerned about this: we don't define what happens in
> this situation currently, and if the packages are identical, it's no
> problem.

As long as the repos we're installing from use coordinated
version/release numbers, then we could map them correctly as long as the
packages are not orphaned.  That would also allow to correctly
"transfer" a package from a hypothetical "test" repo into the "current"
repo, regardless of when it was originally installed.

> If the packages are the same version but have different contents,
> you're asking for problems, although I guess it would be nice to do
> something defined in that situation.

I think that the multiple repositories situation for zypper is still
expected to provide either different versions or the same content.  At
least all the repositories that I'm aware of (that are supposed to work
together) keep things that way.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

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

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

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

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

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

[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: [PATCH] Revert "Don't override a Keep selection"

[Ken Brown]

On 10/18/2017 11:01 PM, Ken Brown wrote:

On 10/17/2017 3:31 PM, Ken Brown wrote:

On 10/17/2017 2:43 PM, Jon Turney wrote:

On 16/10/2017 20:13, Ken Brown wrote:

This reverts (the rest of) commit b43b697.  Part of that commit was
already reverted in commit ff0bb3d.  The rest is not needed either
since we no longer send the upgrade flag to the solver after the user
has made their selections.
---
  libsolv.cc | 14 +++---
  libsolv.h  |  1 -
  package_meta.h |  2 --
  3 files changed, 3 insertions(+), 14 deletions(-)


Hmm... not sure about this.

Say the initial upgrade solution had something like: package A 1.0 -> 
1.1, and A 1.1 has a dependency on package B 2.0, where currently B 
1.0 is installed (so B 1.0 -> 2.0)


If the user then changes B to 'keep' (at 1.0), we should report a 
conflict?


Good point.  I wasn't thinking about dependencies with version relations.


I just tested this scenario, and it turns out that putting a lock on B 
1.0 overrides the dependency of A 1.1 on B 2.0.  There's no problem 
reported.  On the other hand, if there's no lock, then the dependency 
overrides the Keep choice, again with no problem reported.


Back to the drawing board.


Thinking about this further, using SOLVER_LOCK is probably the right 
thing to do in this situation, even if no problem is reported.  We can't 
insist that users install the recommended version.  For example, if I 
choose to downgrade binutils while keeping the current gcc, then I'm 
responsible for any breakage this might cause, with or without a warning 
from setup.


I'll prepare a new patch that restores the SOLVER_LOCK functionality 
that was inadvertently removed in commit ff0bb3d.


Ken

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

[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: [Attn. Maintainers] Perl 5.26.1 (release is imminent)

[Yaakov Selkowitz]

On 2017-10-18 13:20, Achim Gratz wrote:
> I've just uploaded the files for the update of Perl to version 5.26 to
> sourceware.  Unfortunatley only a single other package has been staged
> there (znc), so we need to wait for the rest of the maintainers to do
> their uploads.

My uploads are queued up as well.

> Again the reminder that the following packages will have to be re-built
> since they install perl modules:
> 
> git-svn:   Subversion compatibility support for Git version control 
> system
> git:   Distributed version control system

Adam, git will break if it doesn't get rebuilt and uploaded together
with the 5.26 upgrade.  How soon can you rebuild it with Achim's repo?

-- 
Yaakov



signature.asc
Description: OpenPGP digital signature

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

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

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

[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: [setup topic/libsolv] Packages contained in multiple repositories

[Jon Turney]

On 18/10/2017 17:41, Achim Gratz wrote:

Ken Brown writes:

In retrospect, I'm not sure this patch is right, but I'm sending it
anyway for the sake of discussion.  My hesitation comes from the fact
that libsolv might have a good reason for preferring the one it chose,
e.g., if we've assigned priorities to the repos.  On the other hand,
if we've gone to the trouble of assigning priorities, shouldn't
packagemeta reflect our choice?


Extrapolating from my experience with zypper, libsolv should stick with
the repo the installed package comes from even if some other repo has a
newer version.


Unfortunately, we are limited by the fact that installed.db doesn't 
record which repo an installed package came from.


We map repo setup.ini release: labels to package vendor names, so we 
assume it's 'Cygwin' for an installed package (package_db.cc:115), and 
run the solver with SOLVER_FLAG_ALLOW_VENDORCHANGE on (libsolv.cc:745) 
to allow it to get upgraded by a package in the repo it actually came 
from, but we've forgotten.


I'm not overly concerned about this: we don't define what happens in 
this situation currently, and if the packages are identical, it's no 
problem.


If the packages are the same version but have different contents, you're 
asking for problems, although I guess it would be nice to do something 
defined in that situation.

Re: git can not access remote repository anymore after cygwin+git update

[Ronald Fischer]

On Thu, Oct 19, 2017, at 14:28, Marco Atzeri wrote:
> On 19/10/2017 13:38, Ronald Fischer wrote:
> > I'm using 64 Bit Cygwin on Windows 7. After upgrading Git to version
> > 2.14.2 (I think I had 2.13 or 2.12 before), git can not access our
> > repository anymore. Commands such as "git pull" or "git push" result
> > into the error
> > 
> > 
> > fatal: Could not read from remote repository.
> > Please make sure you have the correct access rights
> > and the repository exists.

> it seems your cygwin package was not update correctly:
> 
> cygwin 2.9.0-3  OK
> 
> but
> 
>   3238k 2017/04/01 C:\cygwin64\bin\cygwin1.dll - os=4.0 img=0.0 sys=5.2
>"cygwin1.dll" v0.0 ts=2017-04-01 20:47
> Cygwin DLL version info:
>  DLL version: 2.8.0
> 
> May be is not the root cause but you should reinstall the package
> with no running process. 


This was it! Thanks a lot!!!

Ronald

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

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

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

[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

[PATCH setup] Add bitness to user-agent string

[Jon Turney]

We have no idea about the proportion of 32-bit and 64-bit Cygwin installs.

Add a 'Win32', 'WoW64' or 'Win64' token to the user-agent string to report
bitness.

Future work: it might be useful to report the OS version as well

Signed-off-by: Jon Turney 
---
 nio-ie5.cc | 27 +--
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/nio-ie5.cc b/nio-ie5.cc
index 24d2c13..c8f65a9 100644
--- a/nio-ie5.cc
+++ b/nio-ie5.cc
@@ -31,11 +31,34 @@
 #include "getopt++/StringOption.h"
 
 static StringOption UserAgent ("", '\0', "user-agent", "User agent string for 
HTTP requests");
-static std::string default_useragent = std::string("Cygwin-Setup/") + 
setup_version;
 
 static HINTERNET internet_direct = 0;
 static HINTERNET internet_preconfig = 0;
 
+const std::string &
+determine_default_useragent(void)
+{
+  static std::string default_useragent;
+
+  if (!default_useragent.empty())
+return default_useragent;
+
+  std::string token = "Unknown";
+#ifdef __x86_64__
+  token = "Win64";
+#else
+  typedef BOOL (WINAPI *PFNISWOW64PROCESS)(HANDLE, PBOOL);
+  PFNISWOW64PROCESS pfnIsWow64Process = 
(PFNISWOW64PROCESS)GetProcAddress(GetModuleHandle("kernel32"), 
"IsWow64Process");
+  if (pfnIsWow64Process) {
+BOOL bIsWow64 = FALSE;
+if (pfnIsWow64Process(GetCurrentProcess(), ))
+  token = bIsWow64 ? "WoW64" : "Win32";
+  }
+#endif
+  default_useragent = std::string("Cygwin-Setup/") + setup_version + " (" + 
token + ")";
+  return default_useragent;
+}
+
 NetIO_IE5::NetIO_IE5 (char const *_url, bool direct, bool cachable):
 NetIO (_url)
 {
@@ -51,7 +74,7 @@ NetIO (_url)
 {
   InternetAttemptConnect (0);
 
-  const char *lpszAgent = default_useragent.c_str();
+  const char *lpszAgent = determine_default_useragent().c_str();
   if (UserAgent.isPresent())
 {
   const std::string _agent = UserAgent;
-- 
2.14.2

Re: git can not access remote repository anymore after cygwin+git update

[Marco Atzeri]

On 19/10/2017 13:38, Ronald Fischer wrote:

I'm using 64 Bit Cygwin on Windows 7. After upgrading Git to version
2.14.2 (I think I had 2.13 or 2.12 before), git can not access our
repository anymore. Commands such as "git pull" or "git push" result
into the error


fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.


Since I can't go back to the previous version (I didn't find any Git
mirror which has 2.12 or 2.13), I have now intalled Git for Windows
(https://git-scm.com/) along Cygwin git, also in Version 2.14.2. With
this, I don't have any problems (I have installed it in a separate
directory, which is not in my PATH, and I'm using git-scm for operations
which access our remote repository, and Cygwin git for everything else).

This works fine so far, but I still wonder what has changed in git so
that this is broken. Of course it could also be that the permission
error is not related to the new git version, but to some changes in the
Cygwin core libraries, because they had also been updated.

Note that there is no "real" access problem from the Windows side,
because if it were so, Git for Windows would also report an error.

Any idea what's wrong here?

Ronald



it seems your cygwin package was not update correctly:

cygwin 2.9.0-3  OK

but

 3238k 2017/04/01 C:\cygwin64\bin\cygwin1.dll - os=4.0 img=0.0 sys=5.2
  "cygwin1.dll" v0.0 ts=2017-04-01 20:47
Cygwin DLL version info:
DLL version: 2.8.0

May be is not the root cause but you should reinstall the package
with no running process. Including services


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

[PATCH setup 0/2] Fix gcc 6 warnings

[Jon Turney]

Jon Turney (2):
  Fix -Werror=unused-const-variable error seen with gcc 6
  Fix -Werror=misleading-indentation errors seen with gcc 6

 libgetopt++/src/OptionSet.cc | 6 --
 sha2.c   | 2 ++
 2 files changed, 6 insertions(+), 2 deletions(-)

-- 
2.14.2

[PATCH setup 1/2] Fix -Werror=unused-const-variable error seen with gcc 6

[Jon Turney]

sha2.c:199:24: error: 'sha224_initial_hash_value' defined but not used 
[-Werror=unused-const-variable=]
---
 sha2.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sha2.c b/sha2.c
index 4842e42..67251bc 100644
--- a/sha2.c
+++ b/sha2.c
@@ -195,6 +195,7 @@ static const u_int32_t K256[64] = {
0x90befffaUL, 0xa4506cebUL, 0xbef9a3f7UL, 0xc67178f2UL
 };
 
+#if !defined(SHA2_SMALL)
 /* Initial hash value H for SHA-224: */
 static const u_int32_t sha224_initial_hash_value[8] = {
0xc1059ed8UL,
@@ -206,6 +207,7 @@ static const u_int32_t sha224_initial_hash_value[8] = {
0x64f98fa7UL,
0xbefa4fa4UL
 };
+#endif
 
 /* Initial hash value H for SHA-256: */
 static const u_int32_t sha256_initial_hash_value[8] = {
-- 
2.14.2

[PATCH setup 2/2] Fix -Werror=misleading-indentation errors seen with gcc 6

[Jon Turney]

This looks like an actual bug which has been lurking here since forever,
fortunately not exposed since hardly anything uses Option::Optional...

libgetopt++/src/OptionSet.cc: In member function 'void 
OptionSet::doOption(std::__cxx11::string&, const size_type&)':
libgetopt++/src/OptionSet.cc:125:25: error: this 'if' clause does not guard... 
[-Werror=misleading-indentation]
 if (!isOption(maybepos))
 ^~
libgetopt++/src/OptionSet.cc:128:8: note: ...this statement, but the latter is 
misleadingly indented as if it is guarded by the 'if'
argv.erase(argv.begin() + 1);
^~~~
libgetopt++/src/OptionSet.cc:159:25: error: this 'if' clause does not guard... 
[-Werror=misleading-indentation]
 if (!isOption(maybepos))
 ^~
libgetopt++/src/OptionSet.cc:161:8: note: ...this statement, but the latter is 
misleadingly indented as if it is guarded by the 'if'
argv.erase(argv.begin() + 1);
^~~~
---
 libgetopt++/src/OptionSet.cc | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/libgetopt++/src/OptionSet.cc b/libgetopt++/src/OptionSet.cc
index f57b89a..81ffeae 100644
--- a/libgetopt++/src/OptionSet.cc
+++ b/libgetopt++/src/OptionSet.cc
@@ -122,10 +122,11 @@ OptionSet::doOption(string , string::size_type 
const )
 if (argv.size() > 1) {
 string::size_type maybepos = 
argv[1].find_first_not_of("-");
 
-if (!isOption(maybepos))
+if (!isOption(maybepos)) {
 /* not an option */
 value = argv[1];
argv.erase(argv.begin() + 1);
+}
 }
 } else {
 /* value if present is in this argv */
@@ -156,9 +157,10 @@ OptionSet::doOption(string , string::size_type 
const )
 if (argv.size() > 1) {
 string::size_type maybepos = 
argv[1].find_first_not_of("-");
 
-if (!isOption(maybepos))
+if (!isOption(maybepos)) {
 value = argv[1];
argv.erase(argv.begin() + 1);
+}
 }
 }
 }
-- 
2.14.2

git can not access remote repository anymore after cygwin+git update

[Ronald Fischer]

I'm using 64 Bit Cygwin on Windows 7. After upgrading Git to version
2.14.2 (I think I had 2.13 or 2.12 before), git can not access our
repository anymore. Commands such as "git pull" or "git push" result
into the error


fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.


Since I can't go back to the previous version (I didn't find any Git
mirror which has 2.12 or 2.13), I have now intalled Git for Windows
(https://git-scm.com/) along Cygwin git, also in Version 2.14.2. With
this, I don't have any problems (I have installed it in a separate
directory, which is not in my PATH, and I'm using git-scm for operations
which access our remote repository, and Cygwin git for everything else). 

This works fine so far, but I still wonder what has changed in git so
that this is broken. Of course it could also be that the permission
error is not related to the new git version, but to some changes in the
Cygwin core libraries, because they had also been updated.

Note that there is no "real" access problem from the Windows side,
because if it were so, Git for Windows would also report an error. 

Any idea what's wrong here?

Ronald


cygcheck.out
Description: Binary data

--
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: [Attn. Maintainers] Perl 5.26.1 (release is imminent)

[Marco Atzeri]

On 18/10/2017 20:20, Achim Gratz wrote:





Please upload your packages to sourceware _without_ the !ready cookies
(i.e. don't use cygport upload) and instead place !perl cookies.  This
way the staged uploads can all be activated at the same time so that no
inconsistent intermediate state gets published.

Please post a not here on this list as well when your upload is staged.



uploaded

GraphicsMagick
ImageMagick
gdal
irssi
postgresql



Regards,
Achim.


Regards
Marco