> 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: http://cygw
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
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 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:
Geetings, Larry,
Some comments about this (sorry if this is off-tipic):
Since you're providing this Cygwin serv
On 4/7/2014 9:50 PM, Christopher Faylor wrote:
On Mon, Apr 07, 2014 at 09:28:29PM -0400, Larry Hall (Cygwin) wrote:
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 dail
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
>
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:
>
>
>> 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 b
On 4/7/2014 6:41 PM, Peter A. Castro wrote:
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 certainly c
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 poin
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
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 be 65535
On Mon, Apr 07, 2014 at 06:12:56PM -0400, Larry Hall (Cygwin) wrote:
> On 4/7/2014 5:09 PM, Colin wrote:
>
>
>
> >>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 fo
On Mon, 7 Apr 2014, Larry Hall (Cygwin) wrote:
On 4/7/2014 5:09 PM, Colin wrote:
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
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 4/7/2014 5:09 PM, Colin wrote:
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 can eit
Larry Hall (Cygwin 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
> >> as exp
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:
"...defau
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 whenev
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 ho
>> 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 n
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
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_
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
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' m
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 and
On 4/7/2014 7:23 AM, Corinna Vinschen wrote:
On Apr 7 11:08, Colin wrote:
Corinna Vinschen cygwin.com> writes:
On Apr 4 09:44, Colin wrote:
Corinna Vinschen cygwin.com> writes:
Alternatively, even though I hate to point people to older versions
of Cygwin, you could try the old Cygwin
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
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 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
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 (sh
> 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 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 g
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
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 :
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,
> 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
> 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 NIH
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 th
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 work
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
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
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 ma
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.
>
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.
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 f
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 li
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
On Apr 7 11:08, Colin wrote:
> Corinna Vinschen cygwin.com> writes:
>
> >
> > On Apr 4 09:44, Colin wrote:
> > > Corinna Vinschen 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 no
Corinna Vinschen cygwin.com> writes:
>
> On Apr 4 09:44, Colin wrote:
> > Corinna Vinschen 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 think it was compiled for
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
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.
>>
>>
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 th
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
>> >> dlli
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
>
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,
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 creat
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 alwa
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
>
> int main(void)
> { assert(0);
> return 0;
> }
>
> $ ulimit -a
> core file size (blocks, -c) u
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 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
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 installat
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 __declspec(dllexport/dllim
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 th
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$
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 t
64 matches
Mail list logo
