RE: resolving _glgetstr...@4 by linking to _glGetString

  > Not so much of an issue any more (still a bit curious about it, but). I soon   > found that providing a '-lopengl32' link instead of   > '/cygdrive/c/Windows/System32/opengl32.dll' fixed the problem. Linking to /cygdrive/c/windows/system32/whatever is "never" right. It is not easy to e

Re: 1.7.5 cannot bg mintty

On 30 May 2010 07:00, Christopher Faylor wrote: > On Sat, May 29, 2010 at 11:32:23PM +0100, Andy Koppe wrote: >>There's also another issue with the ^Z not taking effect immediately >>due to signal handling being disabled while mintty waits for Windows >>events, but that would require some fairly ma

Re: seteuid problem Win2003

On Jul 9 17:17, Vikentsy Lapa wrote: > Hello, all. > > I run simple seteuid programm which switch user context form user admin > to user UserDom1. > > Programm output is > $ ./t_seteuid.exe > Process EUID: 11133 > seteuid failed:: Permission denied That's a Windows limitation. http://cy

[ANNOUNCEMENT] Updated: cppcheck-1.44-1

Version 1.44-1 of cppcheck has been uploaded, following the upstream release. cppcheck is a tool for static C/C++ code analysis. It tries to detect bugs that your C/C++ compiler don't see. The goal is no false positives. cppcheck is versatile. You can check non-standard code that includes variou

Re: XWin seg fault on Vista (cygwin 1.7)

Xwin doesn't work with Windows XP as well. But when I update all X11 libraries (libxcb) from version 1.6-1 to 1.5-1, Xwin works. --- On Fri, 7/9/10, Larry Hall (Cygwin) wrote: > From: Larry Hall (Cygwin) > Subject: Re: XWin seg fault on Vista (cygwin 1.7) > To: cygwin@cygwin.com > Date: Frid

Re: Cygwin extremely slow after updating from 1.5.1 to 1.7.5

Huang Bambo gmail.com> writes: > > Use "strace ls" and "strace -t ls" and attach the output first. > strace ls: http://pastie.org/1041010 strace -t ls: http://pastie.org/1041018 It is just on the first invocation ls is slow. Bash starts up slow every time, and my Cucumber test takes 6 minute

Re: Cygwin extremely slow after updating from 1.5.1 to 1.7.5

Larry Hall (Cygwin cygwin.com> writes: > > On 7/11/2010 9:00 PM, Jet Thompson wrote: > > It is now taking over 30 seconds for bash to come up, > > whereas in 1.5 it would take 1-2 seconds. > > This is typically the result of . > Only program I had installed

Re: Cygwin extremely slow after updating from 1.5.1 to 1.7.5

Am 12.07.2010 03:00, schrieb Jet Thompson: > It is now taking over 30 seconds for bash to come up, > whereas in 1.5 it would take 1-2 seconds. > > Doing an ls of my ~ directory takes 5 seconds. > > Running a cucumber test takes 5-6 minutes. > > Any idea what could be causing this? Virus, Spywar

Re: Cygwin extremely slow after updating from 1.5.1 to 1.7.5

Matthias Andree gmx.de> writes: > If bash is slow to start, see if uninstalling bash-completion fixes it. > For me it helped quite a bit. Matthias, I uninstalled bash-completion and it did indeed make a very substantial improvement. Thank you. Jet -- Problem reports: http://cygwin

Sending SIGUSR1 to thread in nanosleep causes segfault

Hello, I've been trying to get the FreeRTOS Posix simulator to run on Cygwin and have run into a few bugs in the signal handling/pthread libraries and have isolated test cases Essentially sending a SIGUSR1 to a pthread causes a segfault if that thread is in sleep/nanosleep/select. This behavior c

pthread_mutex_lock doesn't interrupt

Hello, I've been trying to get the FreeRTOS Posix simulator to run on Cygwin and have run into a few bugs in the signal handling/pthread libraries and have isolated test cases I believe when pthread_mutex_lock receives an interrupt it should run it then resume trying to get a lock, the signal hand

Re: pthread_mutex_lock doesn't interrupt

On 7/12/2010 12:56 PM, James Cotton wrote: Hello, I've been trying to get the FreeRTOS Posix simulator to run on Cygwin and have run into a few bugs in the signal handling/pthread libraries and have isolated test cases I believe when pthread_mutex_lock receives an interrupt it should run it then

[ANNOUNCEMENT] Updated: vorbis-tools-1.4.0-1

A new version of the vorbis-tools package is now available for download. NEWS: = This is a new upstream release. Please see the Changes attachment below for more details. DESCRIPTION: vorbis-tools contains oggenc (an encoder) and ogg123 (a playback tool). It also has vorbiscommen

[ANNOUNCEMENT] New: libtheora-1.1.1-2

New packages providing Xiph.Org's Theora video codec are now available for download. DESCRIPTION: Theora is Xiph.Org's first publicly released video codec, intended for use within the Ogg's project's Ogg multimedia streaming system. Theora is derived directly from On2's VP3 codec; Cur

Re: License violation: gpsd4win

On Jul 11 22:56, Yaakov S wrote: > http://code.google.com/p/gpsd-4-win/ > > This project provides an installer containing cygwin1.dll and at least a > Base installation. The project's SVN repo also contains the same > binaries. Nowhere are sources to Cygwin or any other package provided. Thank

Re: Tab Completion Problem

On 7/9/2010 2:16 PM, Jacob Jacobson wrote: On 7/8/2010 9:08 AM, Jacob Jacobson wrote: I recently updated my Cygwin installation and now I get, [~$:501] cd /c/home/bash: exclude: unbound variable [~$:501] when I hit TAB. I have seen Eric's announcement & followed that. >> A new release of bas

Re: Sending SIGUSR1 to thread in nanosleep causes segfault

FYI Just to update some details. I am working with James Cotton on the OpenPilot project. We are trying to port the POSIX simulation port of FreeRTOS to cygwin. We run into issues with signal handling in cygwin 1.7.5 that are currently blocking our development, since every method to suspend a ru

Cygwin / Windows 7 Heap Problems

Hey, I'm wondering if there are any cygwin gurus who can shed some light on crashes that look to be Windows7 64bit compatibility-related. When running a perl script through cygwin/bash on a fresh windows 7 64-bit install, I encounter errors similar to what others have corrected using "rebaseall".

Re: Cygwin / Windows 7 Heap Problems

On 7/12/2010 5:40 PM, m2c wrote: Hey, I'm wondering if there are any cygwin gurus who can shed some light on crashes that look to be Windows7 64bit compatibility-related. When running a perl script through cygwin/bash on a fresh windows 7 64-bit install, I encounter errors similar to what other

Re: Cygwin / Windows 7 Heap Problems

On 12 July 2010 22:40, m2c wrote: > > Hey, I'm wondering if there are any cygwin gurus who can shed some light on > crashes that look to be Windows7 64bit compatibility-related.  When running > a perl script through cygwin/bash on a fresh windows 7 64-bit install, I > encounter errors similar to wh

Re: pthread_mutex_lock doesn't interrupt

On 12 July 2010 17:56, James Cotton wrote: > Hello, I've been trying to get the FreeRTOS Posix simulator to run on > Cygwin and have run into a few bugs in the signal handling/pthread > libraries and have isolated test cases > > I believe when pthread_mutex_lock receives an interrupt it should run

Re: Cygwin / Windows 7 Heap Problems

When I try, I get the error: find: '/usr/lib/perl15/site_perl/5.10/i686-cygwin/auto/': No such file or directory, and then the rebaseimage error (with no clues from google). Larry Hall (Cygwin) wrote: > > On 7/12/2010 5:40 PM, m2c wrote: >> >> Hey, I'm wondering if there are any cygwin gurus wh

Re: Cygwin / Windows 7 Heap Problems

Yes, I've checked that list - I'm certain we have none of that installed. Andy Koppe wrote: > > On 12 July 2010 22:40, m2c wrote: >> >> Hey, I'm wondering if there are any cygwin gurus who can shed some light >> on >> crashes that look to be Windows7 64bit compatibility-related.  When >> running

Re: Cygwin extremely slow after updating from 1.5.1 to 1.7.5

Jet Thompson whidbey.com> writes: > > It is now taking over 30 seconds for bash to come up, > whereas in 1.5 it would take 1-2 seconds. Above fixed by removing bash-completion > Doing an ls of my ~ directory takes 5 seconds. Above fixed by removing bash-completion > Running a cucumber test

Re: pthread_mutex_lock doesn't interrupt

Sorry, I don't have access to the actual POSIX standard, but my interpretation is based on man pages: https://computing.llnl.gov/tutorials/pthreads/man/pthread_mutex_lock.txt And certainly nowhere have I see "pthread_mutex_lock blocks signals". The signal we are using is SIGUSR1. I don't see why

Re: Cygwin extremely slow after updating from 1.5.1 to 1.7.5

On 12 July 2010 23:48, Jet Thompson wrote: >> Running a cucumber test takes 5-6 minutes. >> >> Any idea what could be causing this? > > I have installed spork. > > Time is now 45.2 seconds running Cucumber from > within e text editor. > > Time is 32 seconds running Cucumber from the command > line

Re: pthread_mutex_lock doesn't interrupt

On 13 July 2010 01:08, James Cotton wrote: > Sorry, I don't have access to the actual POSIX standard It's at http://www.opengroup.org/onlinepubs/9699919799. > but my > interpretation is based on man pages: > > https://computing.llnl.gov/tutorials/pthreads/man/pthread_mutex_lock.txt > > And certai

Re: Sending SIGUSR1 to thread in nanosleep causes segfault

On 12 July 2010 22:05, Corvus Corax wrote: > Just to update some details. > > I am working with James Cotton on the OpenPilot project. > We are trying to port the POSIX simulation port of FreeRTOS to cygwin. > > We run into issues with signal handling in cygwin 1.7.5 that are > currently blocking o