On Mon, Apr 07, 2014 at 02:19:10PM -0400, Christopher Faylor wrote:
On Mon, Apr 07, 2014 at 02:08:42PM +0200, Corinna Vinschen wrote:
On Apr 5 12:20, Achim Gratz wrote:
Corinna Vinschen writes:
FYI, I contacted Chuck off-list 6 days ago but he didn't reply yet.
Same here.
I hope Chuck
On Sun, Apr 6, 2014 at 1:59 PM, David Stacey wrote:
On 06/04/14 17:38, Achim Gratz wrote:
David Stacey writes:
Thank you for your reply. Yes, I was aware of that discussion. I'm not
talking about breaking up 'perl_vendor' for 32-bit Cygwin (although
IMHO that would be a good thing in the
On Mon, Apr 07, 2014 at 08:55:52PM +0200, Corinna Vinschen wrote:
On Apr 7 14:20, Christopher Faylor wrote:
On Mon, Apr 07, 2014 at 02:19:10PM -0400, Christopher Faylor wrote:
On Mon, Apr 07, 2014 at 02:08:42PM +0200, Corinna Vinschen wrote:
On Apr 5 12:20, Achim Gratz wrote:
Corinna
Reini Urban writes:
The new 5.18.2 package will be unified for 32bit and 64bit, yes.
Looking forward to it…
perl_vendor will probably stay as is, as it is the easiest for the
user and the maintainer.
I beg to differ. It would be vastly easier for everyone if perl_vendor
simply depended on
On Apr 7 15:23, Christopher Faylor wrote:
On Mon, Apr 07, 2014 at 08:55:52PM +0200, Corinna Vinschen wrote:
On Apr 7 14:20, Christopher Faylor wrote:
On Mon, Apr 07, 2014 at 02:19:10PM -0400, Christopher Faylor wrote:
On Mon, Apr 07, 2014 at 02:08:42PM +0200, Corinna Vinschen wrote:
On
Corinna Vinschen writes:
Done. Achim, if you would be so kind...
I'll do it tomorrow evening as the latest update of the !package file
hasn't picked it up yet. I have an early morning meeting tomorrow and
need to fetch some sleep, so I don't want to wait another hour… hope
this is OK.
On Mon, Apr 07, 2014 at 09:39:46PM +0200, Achim Gratz wrote:
Corinna Vinschen writes:
Done. Achim, if you would be so kind...
I'll do it tomorrow evening as the latest update of the !package file
hasn't picked it up yet. I have an early morning meeting tomorrow and
need to fetch some sleep, so
On Mon, Apr 7, 2014 at 2:29 PM, Achim Gratz wrote:
Reini Urban writes:
The new 5.18.2 package will be unified for 32bit and 64bit, yes.
Looking forward to it...
perl_vendor will probably stay as is, as it is the easiest for the
user and the maintainer.
I beg to differ. It would be vastly
CVSROOT:/cvs/src
Module name:src
Branch: cygwin-1_7_29-release-branchpoint
Changes by: cori...@sourceware.org 2014-04-07 11:12:59
Modified files:
winsup/cygserver: ChangeLog bsd_helper.cc bsd_mutex.cc client.cc
cygserver.cc process.cc
CVSROOT:/cvs/src
Module name:src
Changes by: cori...@sourceware.org 2014-04-07 11:19:30
Modified files:
winsup/cygserver: ChangeLog process.cc
Log message:
* process.cc (process::process): Only notice that signal_arrived is
NULL in debug output.
CVSROOT:/cvs/src
Module name:src
Branch: cygwin-1_7_29-release-branchpoint
Changes by: cori...@sourceware.org 2014-04-07 11:20:08
Modified files:
winsup/cygserver: ChangeLog process.cc
Log message:
* process.cc (process::process): Only notice that
CVSROOT:/cvs/src
Module name:src
Branch: cygwin-1_7_29-release-branchpoint
Changes by: cori...@sourceware.org 2014-04-07 11:26:16
Modified files:
winsup/cygwin : ChangeLog cygserver_ipc.h shm.cc
Log message:
* cygserver_ipc.h (ipc_set_proc_info): Add
CVSROOT:/cvs/src
Module name:src
Changes by: cori...@sourceware.org 2014-04-07 11:41:50
Modified files:
winsup/cygwin/release: 1.7.29
Log message:
release/1.7.29
Patches:
CVSROOT:/cvs/src
Module name:src
Branch: cygwin-1_7_29-release-branchpoint
Changes by: cori...@sourceware.org 2014-04-07 11:41:51
Modified files:
winsup/cygwin/release: 1.7.29
Log message:
release/1.7.29
Patches:
Hi Richard,
On Sat, Apr 5, 2014 at 6:51 PM, Richard wrote:
Hello Everyone,
I recently (two weeks ago or so) upgraded the cygwin installation on an XP
64 bit (corp edition) box and in getting things running on it again I've
been having various troubles, even though I was VERY careful to
On Sun, Apr 6, 2014 at 8:35 AM, Rob wrote:
I think so. I've not yet struck a case on Windows where either int or long
are not 4 bytes. (Haven't tried Cygwin64.)
Obviously you never used a 16-bit compiler :)
(where int is 16 bits and long is 32 bits usually)
Csaba
--
GCS a+ e++ d- C++ ULS$
Jean-Pierre Flori writes:
The problem we recently encountered was the following:
in gmp-impl.h, mpn_store (which can be either a macro or a function if
efficient assembly is available, and so is always a function on x86_64)
was not marked __declspec(dllexport/dllimport).
I can confirm that
On Apr 6 20:20, Jean-Pierre Flori wrote:
[...]
The problem we recently encountered was the following:
in gmp-impl.h, mpn_store (which can be either a macro or a function if
efficient assembly is available, and so is always a function on x86_64)
was not marked
On Apr 5 09:51, Richard wrote:
Hello Everyone,
I recently (two weeks ago or so) upgraded the cygwin installation on
an XP 64 bit (corp edition) box and in getting things running on it
again I've been having various troubles, even though I was VERY
careful to watch for any installation
On Apr 6 16:35, sisyph...@optusnet.com.au wrote:
-Original Message- From: Joseph Maxwell
[quote]
int x = 0xAB78 in decimal format is : 43896
and
unsigned int y = 0xAB78 in decimal format is : 43896
The size of int is 4 bytes
[/quote]
Not quite what I expected, sine the
On Apr 6 13:29, Patrick Rouleau wrote:
Hi!
After a fresh Cygwin installation, /etc/group contains this line:
root:S-1-5-32-544:0:
When we update the file /etc/group with mkgroup, that line is lost.
Is it possible to update mkgroup to include that line in its output?
Just add it
On Apr 4 22:07, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
Any ideas, please?
http://cygwin.com/problems.html
http://cygwin.com/acronyms/#STC
$ cat assert.c
#include assert.h
int main(void)
{ assert(0);
return 0;
}
$ ulimit -a
core file size (blocks, -c) unlimited
Le Mon, 07 Apr 2014 10:43:12 +0200, Corinna Vinschen a écrit :
On Apr 6 20:20, Jean-Pierre Flori wrote:
[...]
The problem we recently encountered was the following:
in gmp-impl.h, mpn_store (which can be either a macro or a function if
efficient assembly is available, and so is always a
On Apr 5 04:13, Linda Walsh wrote:
Corinna Vinschen wrote:
On Apr 1 09:39, Linda Walsh wrote:
If I mount a device using mount vol in 2 different places, will they
have different device numbers the same?
The same, just as on Linux.
---
Why special case junctions created with
On Apr 7 09:14, Jean-Pierre Flori wrote:
Le Mon, 07 Apr 2014 10:43:12 +0200, Corinna Vinschen a écrit :
On Apr 6 20:20, Jean-Pierre Flori wrote:
Looking at the exes produced (.libs/t-neg.exe) gives with the dllimport
magic:
100401115: 48 89 c1mov%rax,%rcx
Le Mon, 07 Apr 2014 09:14:41 +, Jean-Pierre Flori a écrit :
Looking a little further, it seems the problematic functions are those
directly assembled from assembly code.
That was the case of mpn_store on x86_64.
And when I remove all dllimport, the call to the function mpn_addadd_n
also
Le Mon, 07 Apr 2014 11:39:32 +0200, Corinna Vinschen a écrit :
On Apr 7 09:14, Jean-Pierre Flori wrote:
Le Mon, 07 Apr 2014 10:43:12 +0200, Corinna Vinschen a écrit :
On Apr 6 20:20, Jean-Pierre Flori wrote:
Looking at the exes produced (.libs/t-neg.exe) gives with the
dllimport magic:
On Apr 5 02:35, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
I can’t push this through your list spam filter. Another attempt...
I was trying a few times, and finally deleted the strace attachment. Let's
see if this will go through.
Excuse me for being a bit straightforward, but the spam
Le Mon, 07 Apr 2014 09:49:27 +, Jean-Pierre Flori a écrit :
Le Mon, 07 Apr 2014 09:14:41 +, Jean-Pierre Flori a écrit :
Looking a little further, it seems the problematic functions are those
directly assembled from assembly code.
That was the case of mpn_store on x86_64.
And when I
Le Mon, 07 Apr 2014 10:42:13 +, Jean-Pierre Flori a écrit :
Le Mon, 07 Apr 2014 09:49:27 +, Jean-Pierre Flori a écrit :
Le Mon, 07 Apr 2014 09:14:41 +, Jean-Pierre Flori a écrit :
Looking a little further, it seems the problematic functions are those
directly assembled from
Corinna Vinschen corinna-cygwin at cygwin.com writes:
On Apr 4 09:44, Colin wrote:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
Alternatively, even though I hate to point people to older versions
of Cygwin, you could try the old Cygwin 1.5.25. I'm not quite sure,
but I
On Apr 7 11:08, Colin wrote:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
On Apr 4 09:44, Colin wrote:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
Alternatively, even though I hate to point people to older versions
of Cygwin, you could try the old Cygwin
Le Mon, 07 Apr 2014 10:43:30 +, Jean-Pierre Flori a écrit :
Note in particular the __nm_ prefix.
It is as advertiserd here: http://www.cygwin.com/ml/cygwin/2002-01/
msg00236.html But when looking at the Cygwin32 produced import lib, I
don't see any nm prefix.
In fact, I see some...
On Apr 7 11:26, Jean-Pierre Flori wrote:
Le Mon, 07 Apr 2014 10:43:30 +, Jean-Pierre Flori a écrit :
Note in particular the __nm_ prefix.
It is as advertiserd here: http://www.cygwin.com/ml/cygwin/2002-01/
msg00236.html But when looking at the Cygwin32 produced import lib, I
don't
m0viefreak wrote:
I fixed it for now by placing an empty dummy default-manifest.o file in
working directory.
May you describe how you have crated it or attach here your empty file?
I tried in different ways but always fail in building with:
...default-manifest.o: file not recognized: File
On Apr 7 11:57, Corinna Vinschen wrote:
On Apr 5 02:35, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
I can’t push this through your list spam filter. Another attempt...
I was trying a few times, and finally deleted the strace attachment. Let's
see if this will go through.
Excuse
Le Mon, 07 Apr 2014 13:30:27 +0200, Corinna Vinschen a écrit :
I'm sorry, but I don't know how this works exactly. The nm prefix is
only added for external references, not for inlined functions, but I
don't know the gory details. You may be better off to ask on the gcc
mailing list.
No
On Apr 7 11:50, Jean-Pierre Flori wrote:
Le Mon, 07 Apr 2014 13:30:27 +0200, Corinna Vinschen a écrit :
I'm sorry, but I don't know how this works exactly. The nm prefix is
only added for external references, not for inlined functions, but I
don't know the gory details. You may be
Hi Cygwin friends and users,
I just released Cygwin 1.7.29-2. This is a bugfix release.
What's new:
---
- Allow quoting of arguments to the CYGWIN environment variable, i.e.,
set CYGWIN=error_start=c:\bin\someprogram -T
Bug Fixes
-
- Try harder to do the right thing in
Le Mon, 07 Apr 2014 13:57:30 +0200, Corinna Vinschen a écrit :
On Apr 7 11:50, Jean-Pierre Flori wrote:
Le Mon, 07 Apr 2014 13:30:27 +0200, Corinna Vinschen a écrit :
I'm sorry, but I don't know how this works exactly. The nm prefix is
only added for external references, not for
Le Mon, 07 Apr 2014 13:28:19 +, Jean-Pierre Flori a écrit :
Le Mon, 07 Apr 2014 13:57:30 +0200, Corinna Vinschen a écrit :
On Apr 7 11:50, Jean-Pierre Flori wrote:
Le Mon, 07 Apr 2014 13:30:27 +0200, Corinna Vinschen a écrit :
I'm sorry, but I don't know how this works exactly.
On 04/07/2014 02:47 AM, Corinna Vinschen wrote:
There's no standard which restricts the sizes of the datatypes in
that way. There's only this rule to follow:
sizeof (char) = sizeof (short) = sizeof (int) = sizeof (long)
Well, there IS the C rule that sizeof(char)==1, and also that char
Hmm, not me. In my case a stackdump is generated...
There seems to be an access denied condition C05 along the lines of the
strace output that I've sent.
What could have caused that? Can that be a reason for me not getting the core
dump at all?
Thanks,
Anton Lavrentiev
Contractor
I created a fix and I'm just building cygwin 1.7.29 with it.
That's a good news, and thanks for the quick fix! I'll let you
know if the issue is resolved on my end, too.
Anton Lavrentiev
Contractor NIH/NLM/NCBI
On Apr 7 08:16, Eric Blake wrote:
On 04/07/2014 02:47 AM, Corinna Vinschen wrote:
There's no standard which restricts the sizes of the datatypes in
that way. There's only this rule to follow:
sizeof (char) = sizeof (short) = sizeof (int) = sizeof (long)
Well, there IS the C
On Apr 7 14:02, Jean-Pierre Flori wrote:
Le Mon, 07 Apr 2014 13:28:19 +, Jean-Pierre Flori a écrit :
Le Mon, 07 Apr 2014 13:57:30 +0200, Corinna Vinschen a écrit :
On Apr 7 11:50, Jean-Pierre Flori wrote:
Le Mon, 07 Apr 2014 13:30:27 +0200, Corinna Vinschen a écrit :
I'm
Le Mon, 07 Apr 2014 16:36:18 +0200, Corinna Vinschen a écrit :
On Apr 7 14:02, Jean-Pierre Flori wrote:
Le Mon, 07 Apr 2014 13:28:19 +, Jean-Pierre Flori a écrit :
Le Mon, 07 Apr 2014 13:57:30 +0200, Corinna Vinschen a écrit :
On Apr 7 11:50, Jean-Pierre Flori wrote:
Le Mon, 07
On Apr 7 14:21, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
Hmm, not me. In my case a stackdump is generated...
There seems to be an access denied condition C05 along the lines of the
strace output that I've sent.
What could have caused that? Can that be a reason for me not getting
Does it still occur after update?
Haven't tried it yet; is the new snapshot out already? -- can't see it on the
website...
Anton Lavrentiev
Contractor NIH/NLM/NCBI
On 04/07/2014 08:42 AM, Corinna Vinschen wrote:
On Apr 7 08:16, Eric Blake wrote:
On 04/07/2014 02:47 AM, Corinna Vinschen wrote:
There's no standard which restricts the sizes of the datatypes in
that way. There's only this rule to follow:
sizeof (char) = sizeof (short) = sizeof (int)
On Apr 7 14:47, Jean-Pierre Flori wrote:
Le Mon, 07 Apr 2014 16:36:18 +0200, Corinna Vinschen a écrit :
At this point gcc doesn't know that foo will get exported from a DLL,
but it generates the .def directive nevertheless. If I create the same
code in gas:
.text .globl nothing
On Apr 7 15:03, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
Does it still occur after update?
Haven't tried it yet; is the new snapshot out already? -- can't see it on
the website...
http://cygwin.com/ml/cygwin-announce/2014-04/msg5.html
Corinna
--
Corinna Vinschen
On Apr 7 09:39, Eric Blake wrote:
On 04/07/2014 08:42 AM, Corinna Vinschen wrote:
On Apr 7 08:16, Eric Blake wrote:
On 04/07/2014 02:47 AM, Corinna Vinschen wrote:
There's no standard which restricts the sizes of the datatypes in
that way. There's only this rule to follow:
On 4/7/2014 7:23 AM, Corinna Vinschen wrote:
On Apr 7 11:08, Colin wrote:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
On Apr 4 09:44, Colin wrote:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
Alternatively, even though I hate to point people to older versions
of
On 4/7/2014 8:03 AM, Eduard wrote:
Hi,
We run
Cygwin 1.7.25-1.7.28 on Win7-64bit.
perl version is v5.14.2.
Sometimes during system call from perl we see the following error:
0 [sig] perl 9852 stopped_or_terminated: couldn't wake up wait event
0x110, Win32 error 6
The process hangs
Greetings, Corinna Vinschen!
I don't think your original concern is as big a problem as you
think, as is indicated by the above setup on linux.
I.e. is there some other reason to not treat linkd mounts
the same as mountvol mounts -- in a manner equivalent to linux's
'bind' mounts?
I.e.
Corinna Vinschen wrote:
Look, directory reparse points are, by and large, symlinks to another,
real directory entry. The directory has a primary path, which is its
own path under which it has been created, and the reparse point is just
a pointer to this directory. If that's not a symlink, what
On Mon, Apr 7, 2014 at 11:37 AM, Larry Hall (Cygwin) wrote:
On 4/7/2014 8:03 AM, Eduard wrote:
Hi,
We run
Cygwin 1.7.25-1.7.28 on Win7-64bit.
perl version is v5.14.2.
Sometimes during system call from perl we see the following error:
0 [sig] perl 9852 stopped_or_terminated:
On Apr 7 11:49, David Rothenberger wrote:
I'm having a problem doing hostname resolution on one of my Windows
7 64 machines after updating cygwin to 1.7.29-2. I first noticed it
with ssh. I get an error whenever I try to ssh to any machine using
a hostname; it complains the hostname cannot be
I fixed it for now by placing an empty dummy default-manifest.o file in
working directory.
May you describe how you have crated it or attach here your empty file?
I tried in different ways but always fail in building with:
...default-manifest.o: file not recognized: File format not
On 4/7/2014 3:09 PM, Corinna Vinschen wrote:
On Apr 7 11:49, David Rothenberger wrote:
I'm having a problem doing hostname resolution on one of my Windows
7 64 machines after updating cygwin to 1.7.29-2. I first noticed it
with ssh. I get an error whenever I try to ssh to any machine using
a
Larry Hall (Cygwin) wrote:
On 4/7/2014 3:09 PM, Corinna Vinschen wrote:
On Apr 7 11:49, David Rothenberger wrote:
I'm having a problem doing hostname resolution on one of my Windows
7 64 machines after updating cygwin to 1.7.29-2. I first noticed it
with ssh. I get an error whenever I try to
Ciao m0viefreak,
Il 07/04/2014 21:09, m0viefreak ha scritto:
I fixed it for now by placing an empty dummy default-manifest.o file in
working directory.
May you describe how you have crated it or attach here your empty file?
I tried in different ways but always fail in building with:
Larry Hall (Cygwin reply-to-list-only-lh at cygwin.com writes:
Cygwin 1.5.25 seems like a good option. So I downloaded setup-
legacy.exe
from fruitbat and ran it on an XP machine which has not previously
seen
Cygwin. Initially I installed just the base Cygwin files. The process
ran
On 4/7/2014 5:09 PM, Colin wrote:
snip
Indeed. And if your path under bash doesn't include /usr/bin, then I'll
wager your postinstall scripts didn't run or at least
completely/correctly.
See /etc/postinstall for the scripts. If you aren't able to figure out
what didn't run properly, you
On 07/04/2014 13:02, Ronald Fischer wrote:
I have installed fish 2.1.0. Works fine, when invoking a new fish shell
manually.
However, when doing a
chere -ifcm -t mintty -s fish
and invoke the new fish shell from the Windows Explorer context menu, I
get plenty of error messages, like this:
On Mon, 7 Apr 2014, Larry Hall (Cygwin) wrote:
On 4/7/2014 5:09 PM, Colin wrote:
snip
Indeed. And if your path under bash doesn't include /usr/bin, then I'll
wager your postinstall scripts didn't run or at least
completely/correctly.
See /etc/postinstall for the scripts. If you aren't
On Mon, Apr 07, 2014 at 06:12:56PM -0400, Larry Hall (Cygwin) wrote:
On 4/7/2014 5:09 PM, Colin wrote:
snip
Indeed. And if your path under bash doesn't include /usr/bin, then I'll
wager your postinstall scripts didn't run or at least
completely/correctly.
See /etc/postinstall for the
On 2014-04-08 03:51, Corinna Vinschen wrote:
On Apr 7 09:39, Eric Blake wrote:
C99 5.2.4.2.1 Sizes of integer types limits.h
requires CHAR_BIT to be 8 or larger, UCHAR_MAX to be 255 or larger,
USHRT_MAX to be 65535 or larger (oh, so I was wrong above; 8-bit short
is not allowed), UINT_MAX to
On Mon, Apr 07, 2014 at 11:34:02AM -0700, Linda Walsh wrote:
Corinna Vinschen wrote:
Look, directory reparse points are, by and large, symlinks to another,
real directory entry. The directory has a primary path, which is its
own path under which it has been created, and the reparse point is
On 4/7/2014 6:41 PM, Peter A. Castro wrote:
snip
Geetings, Larry,
Some comments about this (sorry if this is off-tipic):
Since you're providing this Cygwin service, I don't consider information
about this service to be off-topic. And, of course, if *I* don't consider
it off-topic, it
On Mon, Apr 07, 2014 at 09:28:29PM -0400, Larry Hall (Cygwin) wrote:
On 4/7/2014 6:41 PM, Peter A. Castro wrote:
snip
Geetings, Larry,
Some comments about this (sorry if this is off-tipic):
Since you're providing this Cygwin service, I don't consider information
about this service to be
On Tue, Apr 08, 2014 at 09:52:02AM +1000, Duncan Roe wrote:
On Mon, Apr 07, 2014 at 11:34:02AM -0700, Linda Walsh wrote:
Corinna Vinschen wrote:
Look, directory reparse points are, by and large, symlinks to another,
real directory entry. The directory has a primary path, which is its
own path
On 4/7/2014 9:50 PM, Christopher Faylor wrote:
On Mon, Apr 07, 2014 at 09:28:29PM -0400, Larry Hall (Cygwin) wrote:
snip
2) Packaging changes of setup.exe have made extracting the version string
impossible, save for actually running setup, which isn't something I'm
going to do on a
On Mon, 7 Apr 2014, Christopher Faylor wrote:
Greetings, Chris,
On Mon, Apr 07, 2014 at 09:28:29PM -0400, Larry Hall (Cygwin) wrote:
On 4/7/2014 6:41 PM, Peter A. Castro wrote:
snip
Geetings, Larry,
Some comments about this (sorry if this is off-tipic):
Since you're providing this Cygwin
Hello,
It looks like in order to effectively kill the process by Windows means (i.e.
what Cygwin kill -f is supposed to do),
the process handle must be obtained with the SYNCHRONIZE right (in addition to
PROCESS_TERMINATE), otherwise
WaitForSingleObject() fails with code 5, permission denied
On Tue, Apr 08, 2014 at 03:01:18AM +, Lavrentiev, Anton (NIH/NLM/NCBI) [C]
wrote:
Hello,
It looks like in order to effectively kill the process by Windows means (i.e.
what Cygwin kill -f is supposed to do),
the process handle must be obtained with the SYNCHRONIZE right (in addition to
Nah. Maybe we'll have something when the Singularity finally occurs.
I cannot supply patches for you guys because of the GPL. No need to be
sarcastic all the time --
for the project lead it does not sound witty.
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports:
78 matches
Mail list logo
