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
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 th
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
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 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 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
>
> int main(void)
> { assert(0);
> return 0;
> }
>
> $ ulimit -a
> core file size (blocks, -c) u
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 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
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,
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
>
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
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 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.
>>
>>
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
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
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
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: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
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: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.
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: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
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
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
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
> 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
> 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,
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 :
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: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
> 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 (sh
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 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
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 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
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
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_
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
>> 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 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
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
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 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
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
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:
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 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 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 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 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 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 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 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 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
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: http://cygw
64 matches
Mail list logo
