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
>>> agr
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
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.
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 /
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
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 buil
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
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
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 pas
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. Onc
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
> 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_6
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
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
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.gues
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.
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 th
> 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!!
>
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
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, thi
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 ca
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 whic
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 us
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 t
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. D
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
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 wa
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
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. Regard
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
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
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/octa
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-cyg
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.
./configur
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. Specify
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 "gi
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/si
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*:*
>>
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}-unkno
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 remot
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 c
41 matches
Mail list logo
