% cygcheck -c cygwin tcsh
Cygwin Package Information
Package Version Status
cygwin 1.7.5-1 OK
tcsh 6.17.00.1-1 OK
I've noticed that certain file matching patterns in tcsh under Cygwin
are matching more files than they should. In the c
About a year ago I was able to get assistance compiling my MUD client
Tinyfuge, with a special add-on python library, using cywgin. That
problem turned out needing to send the location of the python library
in the ./configure command.
Now that we have a new major release of cygwin with a new(er) v
On 14/09/2010 19:47, SJ Wright wrote:
> Might there be something else a little off?
>
> The text from the latest stackdump:
>> Stack trace:
>> Frame Function Args
> The rest is blank. Should I be concerned, or is this something that will
> work itself out?
This is a bit of a guess, but try
On 09/14/2010 08:39 AM, Ilia K. wrote:
Hi, All.
I've searched quite a lot for the subj and found no solution yet.
I've installed the last cygwin+openssh on Windows XP. I want to
connect from linux and run some native console applications
(non-cygwin CUI, particularly, cdb and cmd) and I need th
Just setting up a new XP pro box, can't find Pine.
So what MUA is supported atm?
Thanks,
Wes
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#u
On Tue, Sep 14, 2010 at 7:58 PM, Chan Kar Heng wrote:
> Hi there.
>
> I've had the same problem in the past.
> Posted a temporary solution here:
>
> http://www.cygwin.com/ml/cygwin/2009-02/msg00403.html
This is an interesting hack, but unfortunately it won't work for
"native" apps, only for cygwi
On Sep 14 12:02, Corinna Vinschen wrote:
> True. Implementing a full replacement for SetCurrentDirectory as in
> your PoC is still an option. However, I can't do that anymore since
> I'm tainted by reading your code. If you would contemplate to sign
> a copyright assignment(**), we could create
On Sep 14 09:11, Corinna Vinschen wrote:
> I applied the below patch to Cygwin CVS and it appears to work nicely.
> The only potential race I can think of is, if another thread of the same
> Cygwin process calls SetCurrentDirectory. I'm inclined to let this
> situation slip through the cracks sinc
No. They are not multilib capable, so they only target a single system - Win64.
I am assuming that Jon will be providing toolchains that target Win32
shortly. These will be separate packages.
On Tue, Sep 14, 2010 at 5:21 PM, Angelo Graziosi
wrote:
> For the sake of completeness, I would ask if
For the sake of completeness, I would ask if with these packages one can
build applications which run on Win Xp 32.
Thanks,
Angelo.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscr
SJ Wright wrote:
Might there be something else a little off?
The text from the latest stackdump:
Stack trace:
Frame Function Args
The rest is blank. Should I be concerned, or is this something that
will work itself out?
Steve W.
A little more information that seems pertinent to this is
Corinna Vinschen wrote:
> ...or having a cwd below the directory. Trying to remove a directory
> which is the CWD of some process is the most common reason that the
> directory is blocked, because the Win32 CWD is opened without the
> FILE_SHARE_DELETE flag. Especially something like `rm -rf ../f
On Sep 14 20:59, Corinna Vinschen wrote:
> On Sep 14 17:39, John Carey wrote:
> > On Sep 14 01:12, Corinna Vinschen wrote:
> > > Hmm, I'm still wondering. In theory we don't have to replace the
> > > directory name. We just have to InterlockedExchange the handle, since
> > > we only need to repla
On Sep 14 17:39, John Carey wrote:
> On Sep 14 01:12, Corinna Vinschen wrote:
> > On Sep 13 19:47, John Carey wrote:
> > > On Sep 11 03:30, Corinna Vinschen:
> > > Anyway, it looks to me as if overwriting the path in an existing
> > > VistaCwd instance would confuse RtlGetCurrentDirectory_U() and
>
Might there be something else a little off?
The text from the latest stackdump:
Stack trace:
Frame Function Args
The rest is blank. Should I be concerned, or is this something that will
work itself out?
Steve W.
--
Problem reports: http://cygwin.com/problems.html
FAQ:
Hi there.
I've had the same problem in the past.
Posted a temporary solution here:
http://www.cygwin.com/ml/cygwin/2009-02/msg00403.html
Best regards,
KarHeng
Ilia K. wrote:
Hi, All.
I've searched quite a lot for the subj and found no solution yet.
I've installed the last cygwin+openssh on W
On Sep 14 01:12, Corinna Vinschen wrote:
> On Sep 13 19:47, John Carey wrote:
> > On Sep 11 03:30, Corinna Vinschen:
> > Anyway, it looks to me as if overwriting the path in an existing
> > VistaCwd instance would confuse RtlGetCurrentDirectory_U() and
> > probably other Win32 API functions. (It m
On Sep 14 09:39, Earl Chew wrote:
> > There shouldn't be any race. When you set the delete disposition,
> > the file is actually deleted as soon as the last handle to the file
> > is closed. If the file isn't opened by another process, it will
> > disappear right at the NtClose at the end of unli
> There shouldn't be any race. When you set the delete disposition,
> the file is actually deleted as soon as the last handle to the file
> is closed. If the file isn't opened by another process, it will
> disappear right at the NtClose at the end of unlink_nt. Please note
> that the call to che
On Sep 14 18:11, Corinna Vinschen wrote:
> On Sep 14 10:12, Corinna Vinschen wrote:
> > On Sep 13 19:47, John Carey wrote:
> > > Anyway, it looks to me as if overwriting the path in an existing
> > > VistaCwd instance would confuse RtlGetCurrentDirectory_U() and
> > > probably other Win32 API funct
On Sep 14 10:12, Corinna Vinschen wrote:
> On Sep 13 19:47, John Carey wrote:
> > Anyway, it looks to me as if overwriting the path in an existing
> > VistaCwd instance would confuse RtlGetCurrentDirectory_U() and
> > probably other Win32 API functions. (It may be that the same is
> > true for the
Hi, All.
I've searched quite a lot for the subj and found no solution yet.
I've installed the last cygwin+openssh on Windows XP. I want to
connect from linux and run some native console applications
(non-cygwin CUI, particularly, cdb and cmd) and I need these
applications to correctly handle Ctrt-C
On 9/14/2010 10:40 AM, טל ח wrote:
4 [main] gvim 7236 C:\cygwin\bin\gvim.exe: *** fatal error -
unable to remap
_\\?\C:\cygwin\lib\gtk-2.0\2.10.0\loaders\cygpixbufloader-xpm.dll to
same address as parent: 0x5D != 0x60 Stack trace:
Try installing the 'rebase' package,
reading /usr
Hi,
While trying to run 'gvim', we get the following messages:
**
bash-3.2$ gvim
4 [main] gvim 6964 exception::handle: Exception: STATUS_ACCESS_VIOLATION
1184 [main] gvim 6964 open_stackdumpfile: D
Version 1.4.04-1 of 'maradns' has been uploaded to the Cygwin archive,
superceding 1.4.03-2, which remains available as the previous version.
MaraDNS is a package that implements the Domain Name Service (DNS), an
essential internet service. For full details, see the project website:
http://www.mar
On 9/14/2010 7:18 AM, Corinna Vinschen wrote:
> On Sep 14 18:15, JonY wrote:
>> What do you suggest the fix should be?
>
> I really don't know, but it's certainly not a fix in Cygwin. The fact
> that /usr/bin is a mount point to /bin is nothing which wouldn't be
> allowed under Linux as well. T
New versions 2010.1-2 of
libqhull-devel, libqhull_6, qhull
have been uploaded for cygwin.
libqhull_5 version revert to previous 2009.1.1-1
CHANGES
The previous 2010.1-1 was faulty as a soversion
bump was needed for libqhull. As all the linux distributions
as still on 2009 or 2003 version the b
On Sep 14 18:15, JonY wrote:
> On 9/14/2010 16:03, Corinna Vinschen wrote:
> >On Sep 14 15:30, JonY wrote:
> >>On 9/14/2010 15:29, Charles Wilson wrote:
> >>>I don't know about Andy, but I sure do -- and I can reproduce his
> >>>problem. I suspect there is a "bug" in how the cross tool locates the
On 14 September 2010 11:40, JonY wrote:
> On 9/14/2010 18:46, Andy Koppe wrote:
>>
>> On 14 September 2010 11:15, Marco Atzeri wrote:
>
> Is this to be expected?
>
> $ x86_64-w64-mingw32-gcc hello.c
> [compiles fine]
>
> $ /bin/x86_64-w64-mingw32-gcc hello.c
> /Users
On 9/14/2010 18:46, Andy Koppe wrote:
On 14 September 2010 11:15, Marco Atzeri wrote:
Is this to be expected?
$ x86_64-w64-mingw32-gcc hello.c
[compiles fine]
$ /bin/x86_64-w64-mingw32-gcc hello.c
/Users/Andy/AppData/Local/Temp/cckcwv49.s: Assembler
messages:
/Users/Andy/AppData/Local/Temp/c
On 14 September 2010 11:15, Marco Atzeri wrote:
>> > Is this to be expected?
>> >
>> > $ x86_64-w64-mingw32-gcc hello.c
>> > [compiles fine]
>> >
>> > $ /bin/x86_64-w64-mingw32-gcc hello.c
>> > /Users/Andy/AppData/Local/Temp/cckcwv49.s: Assembler
>> messages:
>> > /Users/Andy/AppData/Local/Temp/cck
On 9/14/2010 16:03, Corinna Vinschen wrote:
On Sep 14 15:30, JonY wrote:
On 9/14/2010 15:29, Charles Wilson wrote:
I don't know about Andy, but I sure do -- and I can reproduce his
problem. I suspect there is a "bug" in how the cross tool locates the
/usr/x86_64-w64-mingw32/bin
directo
--- Mar 14/9/10, ha scritto:
> On 9/14/2010 13:11, Andy Koppe
> wrote:
> > On 14 September 2010 03:13, JonY wrote:
> >> Version 4.5.1-1 of "mingw64-x86_64-gcc" has been
> uploaded.
> >>
> >> mingw64-x86_64-gcc contains GCC sources used by
> the 64bit target toolchain.
> >> See mingw64-x86_64-gcc-
On Sep 13 14:20, Earl Chew wrote:
> I have a Makefile which performs "rm -f -r" as part of a clean target.
> On Win7 with 1.7.5-1 this can fail with:
>
> rm -f -r win32
> rm: cannot remove directory `win32': Directory not empty
>
>
> I tried 1.7.7-1 but the problem still seems to be there.
>
>
On Sep 13 19:47, John Carey wrote:
> On Sep 11 03:30, Corinna Vinschen:
> > Given that, wouldn't it be potentially possible to override the content
> > of curCwd? The problem is probably (just as in my old Cygwin code up to
> > 1.7.5) to make sure that this is thread safe. Probably we would still
On Sep 14 15:30, JonY wrote:
> On 9/14/2010 15:29, Charles Wilson wrote:
> >I don't know about Andy, but I sure do -- and I can reproduce his
> >problem. I suspect there is a "bug" in how the cross tool locates the
> > /usr/x86_64-w64-mingw32/bin
> >directory, given the mount structure:
> >
On 9/14/2010 15:29, Charles Wilson wrote:
On 9/14/2010 2:57 AM, JonY wrote:
That is weird.
Do you have mingw64 binutils installed? Somehow the cygwin binutils was
used.
I don't know about Andy, but I sure do -- and I can reproduce his
problem. I suspect there is a "bug" in how the cross tool
On 9/14/2010 2:57 AM, JonY wrote:
> That is weird.
>
> Do you have mingw64 binutils installed? Somehow the cygwin binutils was
> used.
I don't know about Andy, but I sure do -- and I can reproduce his
problem. I suspect there is a "bug" in how the cross tool locates the
/usr/x86_64-w64-m
On 9/14/2010 13:11, Andy Koppe wrote:
On 14 September 2010 03:13, JonY wrote:
Version 4.5.1-1 of "mingw64-x86_64-gcc" has been uploaded.
mingw64-x86_64-gcc contains GCC sources used by the 64bit target toolchain.
See mingw64-x86_64-gcc-core, mingw64-x86_64-gcc-objc,
mingw64-x86_64-gcc-ada, ming
39 matches
Mail list logo
