Larry Hall cygwin.com> writes:
I've rolled back to cygwin-1.5.16-1.tar.bz2 and everything resumes working now.
Thanks.
Jason
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/do
Larry Hall cygwin.com> writes:
>
> Unless you installed these services with a particular user specified (see
> the '-u' flag of 'cygrunsrv'), none of the services should be using any
> user mount. All services started by 'cygrunsrv', by default, run as
> SYSTEM. If you did install the servic
There is no reason to expect any improvement in mingw programs from my
change.
Yeah i figured that one out. ;)
I was just trying to rationalize the change that I did show in the original
report. My timings don't show great improvement, and a 1 second margin of
error due to windows caching doe
On Mon, May 30, 2005 at 10:15:56PM -0500, Gary R. Van Sickle wrote:
>Can we get a gold star here for Chris' first-ever apology for his
>anti-social behavior?
Once again, my reply will be in cygwin-talk.
Gary, I will once again (is this the third time now?) direct you there.
FYI, I won't keep prov
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Faylor
> Sent: Saturday, May 28, 2005 12:46 PM
> To: cygwin@cygwin.com
> Subject: Re: Serious performance problems (malloc related?)
>
> On Sat, May 28, 2005 at 10:19:26AM -0700, Andy Ross
"Christopher Faylor" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
> On Sun, May 29, 2005 at 09:22:56PM -0400, Beman Dawes wrote:
>>usr/include/stdint.h beginning at line 177 reads:
>>
>>/* Macros for greatest-width integer constant expressions */
>>
>>#define INTMAX_C(x) x
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Charles D. Russell
> Sent: Saturday, May 28, 2005 11:23 AM
> To: cygwin cygwin
> Subject: Re: slow windows foreground operation after
> installing cygwin-1.5.17-1
>
> The new cygwin1.dll (1.5.17-1) n
At 11:51 AM 5/30/2005, you wrote:
>Reini Urban x-ray.at> writes:
>
>>
>> Jason FU schrieb:
>> > As described in
>> >
>> > http://cygwin.com/ml/cygwin/2004-06/msg00347.html
>> >
>> > I also have the same problem.
>> >
>
>>
>> Run
>>umount -U
>> now to remove all user mounts.
>>
>
>But aft
On Mon, May 30, 2005 at 08:00:35PM -0400, Tacvek wrote:
>>Interesting, why is it faster when running a binary that doesn't depend
>>on cygwin1.dll after swapping the DLL? Some Win caching mechanism?
>
>Repeating many times should minimize any caching:
>
>#New DLL
>$ /bin/time -f "%E %S %U" cygspd-
Interesting, why is it faster when running a binary that doesn't
depend on cygwin1.dll after swapping the DLL? Some Win caching mechanism?
Repeating many times should minimize any caching:
#New DLL
$ /bin/time -f "%E %S %U" cygspd-mingw-ne-o7 cygspd.dat
0:04.48 0.01 0.02
0:01.40 0.00 0.02
0:
Am Montag, 30. Mai 2005 22:33 schrieb Gerrit P. Haase:
> Anonymous wrote:
>
> > My System:
> > #Set-up:
> >
> > $ g++ cygspd.cc -o cygspd-basic
> > $ g++ -O7 cygspd.cc -o cygspd-o7
> > $ g++ -fno-exceptions cygspd.cc -o cygspd-ne
> > $ g++ -O7 -fno-exceptions cygspd.cc -o cygspd-ne-o7
> > $ g++ -
Anonymous wrote:
My System:
#Set-up:
$ g++ cygspd.cc -o cygspd-basic
$ g++ -O7 cygspd.cc -o cygspd-o7
$ g++ -fno-exceptions cygspd.cc -o cygspd-ne
$ g++ -O7 -fno-exceptions cygspd.cc -o cygspd-ne-o7
$ g++ -mno-cygwin cygspd.cc -o cygspd-mingw
$ g++ -O7 -mno-cygwin cygspd.cc -o cygspd-mingw-o7
$
-- Forwarded message --
Date: Mon, 30 May 2005 19:07:56 +0200 (MET DST)
From: Angelo Graziosi <[EMAIL PROTECTED]>
To: cygwin-xfree@cygwin.com
Subject: Re: Emacs problem with Cygwin 1.5.17-1 (CGF please comment)
I pointed out a problem between Emacs (21.2-13, i.e. curr.) and Cygw
My System:
#Set-up:
$ g++ cygspd.cc -o cygspd-basic
$ g++ -O7 cygspd.cc -o cygspd-o7
$ g++ -fno-exceptions cygspd.cc -o cygspd-ne
$ g++ -O7 -fno-exceptions cygspd.cc -o cygspd-ne-o7
$ g++ -mno-cygwin cygspd.cc -o cygspd-mingw
$ g++ -O7 -mno-cygwin cygspd.cc -o cygspd-mingw-o7
$ g++ -fno-exception
On Sun, May 29, 2005 at 09:22:56PM -0400, Beman Dawes wrote:
>usr/include/stdint.h beginning at line 177 reads:
>
>/* Macros for greatest-width integer constant expressions */
>
>#define INTMAX_C(x) x ## L
>#define UINTMAX_C(x) x ## UL
>
>That should be:
>
>/* Macros for greatest-wi
Charles D. Russell wrote:
The new cygwin1.dll (1.5.17-1) now lets me run fortran programs with large
static arrays that occupy most of the available memory, but it is no longer
possible to run Windows programs (MSWord or even Windows Explorer)
in the foreground while a big math problem is chuggin
Reini Urban x-ray.at> writes:
>
> Jason FU schrieb:
> > As described in
> >
> > http://cygwin.com/ml/cygwin/2004-06/msg00347.html
> >
> > I also have the same problem.
> >
>
> Run
>umount -U
> now to remove all user mounts.
>
But after this command, how do I restart those services aga
usr/include/stdint.h beginning at line 177 reads:
/* Macros for greatest-width integer constant expressions */
#define INTMAX_C(x) x ## L
#define UINTMAX_C(x) x ## UL
That should be:
/* Macros for greatest-width integer constant expressions */
#define INTMAX_C(x) x ## LL
this issue is still un-resolved. Contrary to what
cgf says, dlopen doesn't care about LD_LIBRARY_PATH
while opening dependent DLLs of its argument. It opens
the DLL if the depedent DLLs are found in the $PATH.
Your keyword is dependent.
When one dll depends on another in windows, it uses window
Reini Urban x-ray.at> writes:
>
>
> Run
>umount -U
> now to remove all user mounts.
>
Does it mean that I'll have all of my services up after this umount and reboot?
Thanks.
Jason
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.c
Reini Urban x-ray.at> writes:
>
> Jason FU schrieb:
>
> Run
>umount -U
> now to remove all user mounts.
>
Does it mean that I'll have all the services up after this command and rebooting
the machine?
Thanks.
Jason
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Pr
On Sun, May 29, 2005 at 07:09:50PM -0700, Sunil wrote:
>So, this issue is still un-resolved. Contrary to what
>cgf say, dlopen doesn't care about LD_LIBRARY_PATH
>while opening dependent DLLs of its argument. It opens
>the DLL if the depedent DLLs are found in the $PATH.
dlopen is a cygwin inventi
I am not sure why the last email didn't reach the
list, but here goes again.
this issue is still un-resolved. Contrary to what
cgf says, dlopen doesn't care about LD_LIBRARY_PATH
while opening dependent DLLs of its argument. It opens
the DLL if the depedent DLLs are found in the $PATH.
I think cg
So, this issue is still un-resolved. Contrary to what
cgf say, dlopen doesn't care about LD_LIBRARY_PATH
while opening dependent DLLs of its argument. It opens
the DLL if the depedent DLLs are found in the $PATH.
I think you meant if I do dlopen("c.dll",..) it will
try to find it in LD_LIBRARY_PAT
I've just updated the version of sharutils to 4.3.80-1.
This is an official upstream release. The Cygwin version has just a
tiny configure tweak. sharutils pass all (three) tests in the testsuite.
NEWS relative to the previous 4.2.1 release:
Version 4.3.80 - April 2005, by Bruce Korb
* Buglet
25 matches
Mail list logo
