Hi there,
I trust this message finds you well. I am writing to inquire about an unknown
debit that has appeared on my bank account from your store.
I do not have a record of making a order from your store in the recent past,
and I am troubled that this may be an mistake. I would be grateful
I've read through the Cygwin FAQ, googled around, and I wasn't able to find the
appropriate answer, which is why I'm sending it to this mailing list.
Apologies if this is not the correct place.
At the end of setup-x86_64.exe run, I get a popup about an Unknown package
error.
A
On 2021-06-02 19:58, Voris, Ben via Cygwin wrote:
-Original Message-
From: Brian Inglis [mailto:brian.ing...@systematicsw.ab.ca]
Sent: 24 May 2021 11:09
To: cygwin@cygwin.com
Cc: Voris, Ben
Subject: Re: curl SFTP transfer from Cygwin on Win10 to Ubuntu 18.04 fails with
Unknown host
-Original Message-
From: Brian Inglis [mailto:brian.ing...@systematicsw.ab.ca]
Sent: 24 May 2021 11:09
To: cygwin@cygwin.com
Cc: Voris, Ben
Subject: Re: curl SFTP transfer from Cygwin on Win10 to Ubuntu 18.04 fails with
Unknown host key type: 1835008
On 2021-05-17 17:55, Brian Inglis
(connection
#0)
* SFTP 0x8000847c8 state change from SSH_STOP to SSH_INIT
* Found host nucnuc in /home/BVoris/.ssh/known_hosts
* Unknown host key type: 1835008
* SFTP 0x8000847c8 state change from SSH_INIT to SSH_SESSION_FREE
* SFTP 0x8000847c8 state change from SSH_SESSION_FREE to SSH_STOP
* mul
e change from SSH_STOP to SSH_INIT
* Found host nucnuc in /home/BVoris/.ssh/known_hosts
* Unknown host key type: 1835008
* SFTP 0x8000847c8 state change from SSH_INIT to SSH_SESSION_FREE
* SFTP 0x8000847c8 state change from SSH_SESSION_FREE to SSH_STOP
* multi_done
* The cache now contains 0
T
* Found host nucnuc in /home/BVoris/.ssh/known_hosts
* Unknown host key type: 1835008
* SFTP 0x8000847c8 state change from SSH_INIT to SSH_SESSION_FREE
* SFTP 0x8000847c8 state change from SSH_SESSION_FREE to SSH_STOP
* multi_done
* The cache now contains 0 members
* SSH DISCONNECT starts now
* SSH
>-Original Message-
>From: g...@gwkmon.musgravegroup.net
>Sent: Friday 8 January 2021 14:04
>To: SCM Team
>Subject: NoMa: Service 311-ntp on host trastratumts1.musgravegroup.net is
>UNKNOWN
>* NoMa *
>ID: 146297
>Notification Type: PROB
-Original Message-
From: g...@gwkmon.musgravegroup.net
Sent: Friday 8 January 2021 14:04
To: SCM Team
Subject: NoMa: Service 311-ntp on host trastratumts1.musgravegroup.net is
UNKNOWN
* NoMa *
ID: 146297
Notification Type: PROBLEM
Service: 311-ntp
Host: trastratumts1
Dear Jay,
> On the advice of Jon Turney, I ran a "bt f" command after gdb caught the
> exception, and it appears that a Trend Micro dll (TmUmEvt64.dll) is where the
> error occurs:
Since the message with a similar problem I posted is from April 2016, it would
also make sense to report this to T
On 2019-10-25 20:34, Jay P. Elston wrote:
> On October 25, 2019 6:48 AM, Michael Soegtrop wrote:
>> It has been reported in the past that antivirus software from Trend Micro
>> result in STATUS_GUARD_PAGE_VIOLATION in ntdll!RtlAllocateHeap ().
>> See:
>> http://cygwin.1069669.n5.nabble.com/XWin-sta
d126544.html#a126561
On the advice of Jon Turney, I ran a "bt f" command after gdb caught the
exception, and it appears that a Trend Micro dll (TmUmEvt64.dll) is where the
error occurs:
Thread 7 received signal ?, Unknown signal.
[Switching to Thread 8736.0x2bf4]
0x77947b97 in
Dear Jon,
It has been reported in the past that antivirus software from Trend Micro
result in STATUS_GUARD_PAGE_VIOLATION in ntdll!RtlAllocateHeap ().
See:
http://cygwin.1069669.n5.nabble.com/XWin-startup-crash-x86-64-Windows-10-td126544.html#a126561
Best regards,
Michael
Intel Deutschland Gm
On 23/10/2019 18:25, Jay P. Elston wrote:
Hi all,
I developed a problem debugging threads on my Cygwin installed on a Window 7 PC
-- gdb throws an unknown target exception when it gets to the pthread_crreate()
call.
This seems to be saying that the exception isn't thrown when not run
Hi all,
I developed a problem debugging threads on my Cygwin installed on a Window 7 PC
-- gdb throws an unknown target exception when it gets to the pthread_crreate()
call.
This problem seems localized to my PC (even after reinstalling Cygwin), and I
am wondering what my next trouble
Ken Brown schreef op 2018-08-16 20:20:
On 8/16/2018 2:11 PM, waterlan wrote:
Ken Brown schreef op 2018-05-14 14:35:
This is a newlib issue that has been fixed:
https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=commitdiff;h=829820af6e5bccefe93485023e93821807fb99b8;hp=e494b560350cabef9412
-I/usr/include -DDEBUG=0 -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -DUNIX -DWCD_USECURSES -D_XOPEN_SOURCE
-D_XOPEN_SOURCE_EXTENDED -c wcwidth.c -o wcwidth.o
In file included from /usr/include/ssp/wchar.h:5:0,
from /usr/include/wchar.h:336,
from wcwidth.c:62:
/usr/inclu
-D_FILE_OFFSET_BITS=64 -DUNIX -DWCD_USECURSES -D_XOPEN_SOURCE
-D_XOPEN_SOURCE_EXTENDED -c wcwidth.c -o wcwidth.o
In file included from /usr/include/ssp/wchar.h:5:0,
from /usr/include/wchar.h:336,
from wcwidth.c:62:
/usr/include/ssp/wchar.h:78:1: error: unknown ty
On Jun 28 10:19, Timo Maier wrote:
> Hello Corinna,
>
> yes, pls send me the DLL, I will try.
Thanks for testing!
Turns out the drive in question returns a non-standard error code,
ERROR_NOT_READY rather than ERROR_NO_MEDIA_IN_DRIVE to indicate that no
media is present. This error code is not d
Hello Corinna,
yes, pls send me the DLL, I will try.
--
Timo
--
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
On Jun 22 14:33, Timo Maier wrote:
> Hello,
>
> the following is done with: mt V2.5.2, Corinna Vinschen, Aug 26 2013
>
> I have a Quantum LTO 6 Tape Drive (QUANTUM_ULTRIUM-HH6) which works in
> general with the latest cygwin64. I can use mt to rewind or eject and tar can
> write and read the ta
if the tape is ready with "status",
but no matter if the tape is in or not, status always says ONLINE.
Can anyone help, please? Thanks in advance.
***
C:\Tools\cygwin64\bin>mt -f /dev/nst0 status 3
drive type : 01 (Unknown type of tape device)
BUG=0 -D_LARGEFILE_SOURCE
> -D_FILE_OFFSET_BITS=64 -DUNIX -DWCD_USECURSES -D_XOPEN_SOURCE
> -D_XOPEN_SOURCE_EXTENDED -c wcwidth.c -o wcwidth.o
>
> In file included from /usr/include/ssp/wchar.h:5:0,
> from /usr/include/wchar.h:336,
> from wcw
Hans-Bernhard Bröker writes:
> That does look rather weird. Why would one write that instead of just
> -D_FORTIFY_SOURCE=2 ?
That's what cygport does and Yaakov said he'd copied it from Fedora.
But yes, that _is_ unexpected and it did break stuff elsewehere.
Regards,
Achim.
--
+<[Q+ Matrix-12
$ gcc -D_FORTIFY_SOURCE=1 -fstack-protector-strong -c twchar.c -O2
-D_XOPEN_SOURCE
In file included from /usr/include/ssp/wchar.h:5:0,
from /usr/include/wchar.h:336,
from twchar.c:1:
/usr/include/ssp/wchar.h:78:1: error: unknown type name 'FILE'
EXTENDED -c wcwidth.c -o wcwidth.o
In file included from /usr/include/ssp/wchar.h:5:0,
from /usr/include/wchar.h:336,
from wcwidth.c:62:
/usr/include/ssp/wchar.h:78:1: error: unknown type name 'FILE'
__ssp_decl(wchar_t *, fgetws, (wchar_t *__restrict __buf, i
On 4/30/2018 11:16 AM, Keith Christian wrote:
More information:
Why is setup mentioning a .gz extension?
-rw-r--r-- 1 kchristian Domain Users 686572 Feb 9 06:52
/cygdrive/c/Users/kchristian/Downloads/http%3a%2f%2fcygwin.mirror.constant.com%2f/x86/release/cvs/cvs-1.11.23-2.tar.xz
Here are the
On 4/30/2018 5:09 PM, Keith Christian wrote:
I've seen this message when updating Cygwin the past few times (x86 version.)
How to troubleshoot this, or, what else is needed by the Maintainer(s) to fix?
Keith
Are you installing or upgrading CVS ?
If upgrading, I assume that the automatic upgra
More information:
Why is setup mentioning a .gz extension?
-rw-r--r-- 1 kchristian Domain Users 686572 Feb 9 06:52
/cygdrive/c/Users/kchristian/Downloads/http%3a%2f%2fcygwin.mirror.constant.com%2f/x86/release/cvs/cvs-1.11.23-2.tar.xz
Here are the relevant lines in setup.ini:
@ cvs
sdesc: "Vers
I've seen this message when updating Cygwin the past few times (x86 version.)
How to troubleshoot this, or, what else is needed by the Maintainer(s) to fix?
Keith
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http:/
Anyone?
--
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
et the following output:
Entry for the SYSTEM sid was not found in passwd.
Unknown system name
So, to work around this, I generated the /etc/passwd file since it is
no longer generated by default using:
mkpasswd > /etc/passwd
Then, if I try to execute cron-config again, I still get the same output:
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
>
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
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
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 expect
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
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 pac
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 th
> 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
ed 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-
>
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
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-
>
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
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 a
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
fai
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. The
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.
>>
>> F
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 t
storical 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
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 creat
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 co
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
ld 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&#
l 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
ter 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 buil
hich 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 case
mple, 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 cho
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
>>> 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
> 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.
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
> 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!!
>
olchain 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
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
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 imperat
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
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 b
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
s 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
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
>>>
e 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 rig
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
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.
>>
_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.gue
>>> 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 differen
-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
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&#
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
e/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-unkn
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
>&
gt;>> 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.
>
>
e/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'
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
gt;>> 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.
>
&
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?
&g
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?
&g
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.
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
On 2017-10-18 09:11, Corinna Vinschen wrote:
> On Oct 18 07:52, Ken Brown wrote:
>> On 10/18/2017 6:13 AM, Corinna Vinschen wrote:
>>> On Oct 17 18:36, Jeffrey Walton wrote:
On Mon, Oct 16, 2017 at 3:12 AM, Jeffrey Walton wrote:
> Hi Everyone,
>
> I'm trying to build Emacs on Cygw
On 10/18/2017 10:11 AM, Corinna Vinschen wrote:
On Oct 18 07:52, Ken Brown wrote:
[CC-ing the OP in case he is not subscribed to the list.]
On 10/18/2017 6:13 AM, Corinna Vinschen wrote:
On Oct 17 18:36, Jeffrey Walton wrote:
On Mon, Oct 16, 2017 at 3:12 AM, Jeffrey Walton wrote:
Hi Everyon
On Oct 18 07:52, Ken Brown wrote:
> [CC-ing the OP in case he is not subscribed to the list.]
>
> On 10/18/2017 6:13 AM, Corinna Vinschen wrote:
> > On Oct 17 18:36, Jeffrey Walton wrote:
> > > On Mon, Oct 16, 2017 at 3:12 AM, Jeffrey Walton
> > > wrote:
> > > > Hi Everyone,
> > > >
> > > > I'm
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 ;;
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 distr
[CC-ing the OP in case he is not subscribed to the list.]
On 10/18/2017 6:13 AM, Corinna Vinschen wrote:
On Oct 17 18:36, Jeffrey Walton wrote:
On Mon, Oct 16, 2017 at 3:12 AM, Jeffrey Walton wrote:
Hi Everyone,
I'm trying to build Emacs on Cygwin. I use the platform as a test bed
because of
On Oct 17 18:36, Jeffrey Walton wrote:
> On Mon, Oct 16, 2017 at 3:12 AM, Jeffrey Walton wrote:
> > Hi Everyone,
> >
> > I'm trying to build Emacs on Cygwin. I use the platform as a test bed
> > because of Newlib. Emacs is failing with:
>
> Forgive my ignorance... Should this question go to the N
1 - 100 of 346 matches
Mail list logo
