Igor Pechtchanski schrieb:
On Sat, 2 Jul 2005, Eric Blake wrote:
When I'm at my home computer, my email is configured properly. rantBut
when I'm elsewhere and have to use the piece-of-trash webmail interface
from my ISP, there is no way for me to control it. I have already tried
contacting
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Changes from 3.0-3:
- - compiled against cygwin-1.5.18 (because of the new strtoimax, this bash
will not work with cygwin-1.5.17)
- - added preremove script that nukes /bin/sh if it is a version of bash
Corinna wrote:
I'm ready when you're ready.
On Jul 5 07:33, Eric Blake wrote:
Corinna wrote:
I'm ready when you're ready. Do I need to add a postinstall script
or will your postinstall script care for everything?
You should be able to use my postinstall script unchanged -
/etc/postinstall/00bash.sh is a one-liner, although you
On Jul 5 16:03, Corinna Vinschen wrote:
00ash.sh:
#!/bin/ash
link /bin/bash.exe /bin/sh.exe || link /bin/ash.exe /bin/sh.exe
00bash.sh:
#!/bin/bash
link /bin/bash.exe /bin/sh.exe || link /bin/ash.exe /bin/sh.exe
Erm... make that
00ash.sh:
#!/bin/ash
ln
On Tue, 5 Jul 2005, Corinna Vinschen wrote:
This would also mean, you can get rid of your preremove script again.
It seems somewhat dangerous to me anyway. I'd rather have a dangling
/bin/sh.exe than none at all.
One possible problem, BTW, is that if a process that uses /bin/sh is
running
On Jul 5 16:05, Eric Blake wrote:
At any rate, you are probably right that a postinstall script may be
all that is needed (no preremove script) if it ensures that /bin/sh
always exists, and that if it is missing, is ash, or is an older version
of bash, that it gets upgraded. But I would
On Jul 5 18:22, Corinna Vinschen wrote:
Cool with me (and thanks for preparing the ash script). If you want to
release another test release using the above 00bash.sh script, please do.
If you want to move bash out of test (this week or in August), just ping
me and I'll release a new ash
On Tue, 5 Jul 2005, Eric Blake wrote:
In theory. I'm just wondering if your script is safe enough.
test -x /bin/sh.exe || link /bin/bash.exe /bin/sh.exe
The point is, if somebody wants to upgrade bash but not ash for
whatever reason (Gee, *nobody* needs ash, right?), this person
On Tue, 5 Jul 2005, Corinna Vinschen wrote:
Hang on, what about /usr/share/man/man1/sh.1 ?
Right now it's a fixed symlink to ash.1. THe postinstall scripts should
better symlink it to the shell's man page which really is sh after the
script did its job, right?
Speaking of files/symlinks
On Tue, 5 Jul 2005, Eric Blake wrote:
#!/bin/bash
# If /bin/sh is missing, ash, or bash, upgrade it to the current bash.
case `/bin/sh.exe --version 21
FYI, this is missing a closing backtick and the in.
Yep, you caught me typing on the fly instead of pasting a tested script.
Should
On Tue, 5 Jul 2005, Eric Blake wrote:
On Tue, 5 Jul 2005, Eric Blake wrote:
#!/bin/bash
# If /bin/sh is missing, ash, or bash, upgrade it to the current bash.
case `/bin/sh.exe --version 21
FYI, this is missing a closing backtick and the in.
Yep, you caught me typing on the fly
On Jul 5 12:33, Igor Pechtchanski wrote:
This isn't good enough -- I think you do need a preremove script. I've
been trying to figure out why the no-preremove solution seems wrong, and
came up with the following scenario: suppose bash is linked against an
older libreadline, and the user
On Jul 5 13:32, Igor Pechtchanski wrote:
How about using a dummy executable that doesn't depend on anything and
does nothing but print out some pre-defined message, and copying that to
/bin/sh in the preremove script? That way, there will always be a
(non-working, but who cares) /bin/sh...
On Tue, 5 Jul 2005, Corinna Vinschen wrote:
On Jul 5 13:32, Igor Pechtchanski wrote:
How about using a dummy executable that doesn't depend on anything and
does nothing but print out some pre-defined message, and copying that to
/bin/sh in the preremove script? That way, there will
This isn't good enough -- I think you do need a preremove script. I've
been trying to figure out why the no-preremove solution seems wrong, and
came up with the following scenario: suppose bash is linked against an
older libreadline, and the user upgrades both bash and libreadline to
What message gets printed by bash when trying to invoke an executable
whose dependent library can't be found? Even if the user does get
the popup box, the bash script can still be made to treat that the same
as /bin/sh not being installed, as its trigger to update to the current
version of
On Tue, 5 Jul 2005, Eric Blake wrote:
This isn't good enough -- I think you do need a preremove script.
I've been trying to figure out why the no-preremove solution seems
wrong, and came up with the following scenario: suppose bash is
linked against an older libreadline, and the
On Jul 5 18:23, Eric Blake wrote:
Or, I could first do cygcheck /bin/sh.exe, and see if Error: could
not find libname.dll appears in the output [...]
Or even just test -f...
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader
James R. Phillips wrote:
Trial Cygwin packages are now available for octave-2.1.71. These packages are
dependent on the lapack-3.0 package now awaiting upload.
Looks good. A very nice contribution to the cygwin packages.
octave starts and seems to work, though I can't judge
that very well
Or, I could first do cygcheck /bin/sh.exe, and see if Error: could
not find libname.dll appears in the output [...]
Or even just test -f...
test -f /bin/sh.exe checks whether /bin/sh exists. From there,
cygcheck /bin/sh.exe and parsing the output for Error: could not find
checks whether
--- Teun Burgers wrote:
I overrode the PATH in my .bash_login, so the /usr/lib/lapack
was not in the PATH, leading to cygblas.dll and cyglapack.dll not
being found. Maybe an idea to put a remark on the importance
of /usr/lib/lapack being in the PATH in octave-2.1.71.README.
OK. I'll fix
On Tue, 5 Jul 2005, Igor Pechtchanski wrote:
On Tue, 5 Jul 2005, Eric Blake wrote:
OK, then, does anyone else have ideas on how to determine if /bin/sh
is ash with resorting to running it, and without resorting to packing
an ever-increasing list of known md5sums of all prior versions in
Speaking of files/symlinks created in postinstall scripts -- perhaps we
should come up with some unified mechanism for listing them. Some
postinstall scripts use /etc/preremove/PKGNAME-manifest.lst.
The reason it may be useful to have a common mechanism is that cygcheck
-c could then use
CVSROOT:/cvs/uberbaum
Module name:winsup
Changes by: [EMAIL PROTECTED] 2005-07-05 15:11:49
Modified files:
cygwin : ChangeLog malloc.cc
Log message:
* malloc.cc: Update to version 2.8.2.
Patches:
CVSROOT:/cvs/uberbaum
Module name:winsup
Branch: vendor
Changes by: [EMAIL PROTECTED] 2005-07-05 15:21:27
Modified files:
cygwin : malloc.cc
Log message:
Check in base 2.8.2.
Patches:
CVSROOT:/cvs/uberbaum
Module name:winsup
Changes by: [EMAIL PROTECTED] 2005-07-05 20:20:49
Modified files:
cygwin : ChangeLog dcrt0.cc sigproc.cc
Log message:
* dcrt0.cc (cygwin_exit): Mark as noreturn.
* sigproc.cc (child_info::ready):
CVSROOT:/cvs/uberbaum
Module name:winsup
Changes by: [EMAIL PROTECTED] 2005-07-05 21:41:38
Modified files:
utils : ChangeLog cygcheck.cc
Log message:
* cygcheck.cc (track_down, cygcheck): Return true on success.
(main): Reflect cygcheck
As mentioned on cygwin (hopefully I'm not falling afoul of trivial patch size,
since I don't have assignment; and hopefully gmane didn't kill this):
2005-07-05 Eric Blake [EMAIL PROTECTED]
* cygcheck.cc (track_down, cygcheck): Return true on success.
(main): Reflect cygcheck
On Tue, Jul 05, 2005 at 08:49:06PM +, Eric Blake wrote:
@@ -1677,7 +1681,7 @@ main (int argc, char **argv)
{
if (i)
puts ();
- cygcheck (argv[i]);
+ ok = cygcheck (argv[i]);
Why are you anding the result here? Why not just set ok = cygcheck (...)?
cgf
Christopher Faylor cgf-no-personal-reply-please at cygwin.com writes:
On Tue, Jul 05, 2005 at 08:49:06PM +, Eric Blake wrote:
at at -1677,7 +1681,7 at at main (int argc, char **argv)
{
if (i)
puts ();
- cygcheck (argv[i]);
+ ok = cygcheck
Hi, Larry,
While I install NS2.28, it tells no gcc, but I
actually installed gcc, and during the installation,
it said my gcc is not a cross compile, I don't know if
this is matter. And if it is, which gcc version shall
I install? I ran the strace.exe command, get the
following lines, Thank you
Hi, Larry Hall,
I run installation again for NS2.28. It stopped with
errors:
C:\CYGWIN\bin\gcc.exe (62636): *** thread handle not
set - 0x00x0, Win32 error
1450
gcc: Internal error: Hangup (program as)
Please submit a full bug report.
See URL:http://gcc.gnu.org/bugs.html for
instructions.
make:
Hi, Larry,
I reinstall NS2.28 again, it stopped at a different
place this time, that is, not at TK installation but
at TCLCL installation,
* Build Tclcl-1.16
No .configure
Hi, Larry,
I reinstall NS2.28 again, it stopped at a different
place this time, that is, not at TK installation but
at TCLCL installation,
* Build Tclcl-1.16
No .configure
I'll risk wasting some more precious time (ypurs or mine) adding a Perl
stackdump I found in the Mozilla directory where the build failed:
===begin stackdump
Exception: STATUS_ACCESS_VIOLATION at eip=610AA95A
eax=2F632F65 ebx=0800 ecx=871C9010 edx=871C9000 esi=2F632F65
edi=871C26C8
On Mon, 4 Jul 2005, FischRon.external wrote:
After upgrading cygwin to the most recent version, I found that man
pages aren't displayed anymore; for example
$ man man
Warning: cannot open configuration file /usr/share/misc/man.conf
That's not good...
[snip]
Now it does
Michael Bax bax3.NO at SPAM.bigfoot.com writes:
I discovered that my .history file was 53 MB in size! This is with
history 1024
savehist(1024 merge)
in my .login.
wc .history
0 3316299 53060768 .history
I've got the same problem with the same symptoms (the
Hi,
Using even more of your precious time I re-run the Mozilla suite
compilation. This is the final part of the output:
make[4]: Entering directory
`/cygdrive/d/mozilla_source/mozilla/netwerk/resources'
+++ making chrome
/cygdrive/d/mozilla_source/mozilla/netwerk/resources =
On Mon, Jun 06, 2005 at 10:26:26AM -0400, Igor Pechtchanski wrote:
On Mon, 6 Jun 2005, Thomas Baker wrote:
Just wanted to report that I was seeing error messages such as the
following in Korn shell scripts:
/home/tbaker/u/bin/urlists[50]: internal error: alloc: freeing
memory
Chris,
It is really strange.
It should start immediately when running the script and the whole
process lasts about 5 seconds.
Using
system $systemcall;
instead of
open (DDF, $systemcall) ...
works fine.
This also works:
$systemcall='\\/c/WINDOWS/system32/makecab.exe /V3 /F ...
And this too:
Hi,
More test results:
I added -d to the Mozilla rule file that runs make-jars.pl (yes, it is
definitely this script, see
http://lxr.mozilla.org/seamonkey/source/config/make-jars.pl for a copy).
This is the output I got
main::(/cygdrive/d/mozilla_source/mozilla/config/make-jars.pl:5):
5:
Original Message
From: Peter J. Acklam
Sent: 30 June 2005 13:13
Dave Korn [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
^^
Peter, please do http://cygwin.com/acronyms#PCYMTNQREAIYR before you get
me
Original Message
From: Jacek Piskozub
Sent: 05 July 2005 10:19
Hi,
More test results:
I added -d to the Mozilla rule file that runs make-jars.pl (yes, it is
definitely this script, see
http://lxr.mozilla.org/seamonkey/source/config/make-jars.pl for a copy).
[EMAIL PROTECTED]
Hi,
More random ramblings:
I tried to debug the script using the ancient print inserting
technique. The result was interesting. I can stop the crash from
happening by adding a lot of print commands. Does it show it is a timing
(race) problem?
To make it even more interesting, by adding
Ignore my previous post. I attached the HTMLized version downloaded as a
test of wget :-(
This is the real script.
J.
#!/perl
# make-jars [-f] [-v] [-l] [-x] [-a] [-e] [-d chromeDir] [-s srcdir] [-t
topsrcdir] [-c localedir] [-z zipprog] [-o operating-system] jar.mn
my $cygwin_mountprefix
Original Message
From: Jacek Piskozub
Sent: 05 July 2005 12:09
Ignore my previous post. I attached the HTMLized version downloaded as a
test of wget :-(
This is the real script.
J.
[EMAIL PROTECTED] /test/perl ./make-jars.pl
: bad interpreter: No such file or directory
[EMAIL
Dave,
Can't locate mozLock.pm in @INC (@INC contains: /usr/lib/perl5/5.8/cygwin
Find it attached.
Chris will probably kill me when he wakes up :-(
J.
#
# * BEGIN LICENSE BLOCK *
# Version: MPL 1.1/GPL 2.0/LGPL 2.1
#
# The contents of this file are subject to the Mozilla Public
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to FischRon.external AT infineon DOT com on 7/4/2005 6:19 AM:
And who knows, doing the update may even resolve your issue
with chmod
Unfortunately, it doesn't. chmod behaves still as before :-(
I have enclosed an updated cygcheck
This code produces an access violation. Commenting out the arr[] it works
fine. Leaving the arr[] and commenting out the strcat works too.
Anyway on a Linux with GCC 3.4.2 it works as it is presented here without
problems
#include stdarg.h
#include stdio.h
#include stdlib.h
#include string.h
Hi,
I'm having problems installing cygwin onto my PC. This is not the
first time I've installed cygwin on this machine, but I wanted to do
a clean install, so I deleted my C:\Cygwin directory, removed the
icons, and deleted the registry entries, as suggested in the FAQ.
I then downloaded the full
On Jul 5 10:11, Ivan Mari wrote:
This code produces an access violation.
Yep, no wonder.
Commenting out the arr[] it works
fine. Leaving the arr[] and commenting out the strcat works too.
Anyway on a Linux with GCC 3.4.2 it works as it is presented here without
problems
Only
Original Message
From: Paul Moore
Sent: 05 July 2005 14:25
Hi,
I'm having problems installing cygwin onto my PC. This is not the
first time I've installed cygwin on this machine, but I wanted to do
a clean install, so I deleted my C:\Cygwin directory, removed the
icons, and deleted
On Mon, Jul 04, 2005 at 07:39:39PM -0400, Volker Quetschke wrote:
It is a standalone testcase, unfortunately it depends on the absolute path
it resides in. To reproduce unpack perlfreeze.zip to d: and then
do:
$ cd /cygdrive/d/perlfreeze
$ ./perltest.pl
and see it hang. (In rxvt/bash)
I've
On Tue, Jul 05, 2005 at 08:52:25AM +0200, Jacek Piskozub wrote:
I'll risk wasting some more precious time (ypurs or mine) adding a Perl
stackdump I found in the Mozilla directory where the build failed:
===begin stackdump
Exception: STATUS_ACCESS_VIOLATION at eip=610AA95A
eax=2F632F65
Ron,
Please make sure your mailer respects the Reply-To: header -- I set it for
a reason. There's no need to Cc: me on the messages, as I read the list.
On Tue, 5 Jul 2005, FischRon.external wrote:
On Mon, 4 Jul 2005, FischRon.external wrote:
Now I checked /usr/share/misc and found that
I've downloaded this and it does just sit there but I don't know how long
I'm
supposed to wait. Is it supposed to print a lot of stuff right away?
Yes, it's supposed to produce a cab file while reporting what it is doing.
I realized that if you press CTRL-c it really starts to build the cab
On Tue, 5 Jul 2005, Dave Korn wrote:
Original Message
From: Paul Moore
Sent: 05 July 2005 14:25
Hi,
I'm having problems installing cygwin onto my PC. This is not the
first time I've installed cygwin on this machine, but I wanted to do
a clean install, so I deleted my C:\Cygwin
On Tue, Jul 05, 2005 at 10:17:28AM -0400, Christopher Faylor wrote:
The malloc implementation in perl was updated to the latest version of
Doug Lea's malloc so there is a possibility that this is a malloc bug.
However, given that the perl on my linux system routinely trips a
double free error
Yitzchak Scott-Thoennes sthoenna at efn dot org wrote:
What perl version (on linux)? Do you have a test case?
No, it works fine on Linux. Same script, same Mozilla build, same Perl
version (5.8.6).
I would bet my money that the fault is on cygwin side, especially as
with cygwin 1.5.17,
On Tue, 5 Jul 2005, Jacek Piskozub wrote:
Yitzchak Scott-Thoennes sthoenna at efn dot org wrote:
What perl version (on linux)? Do you have a test case?
No, it works fine on Linux. Same script, same Mozilla build, same Perl
version (5.8.6).
I would bet my money that the fault is on
[EMAIL PROTECTED] wrote:
On Sat, 2 Jul 2005, Nick Kirchner wrote:
I just installed Cygwin on my Windows 98 computer and tried playing
around with Emacs. Having toyed with it a little in the past, I know
that C-x C-c is supposed to exit the program. As you may have
guessed, C-x C-c did
On Tue, 5 Jul 2005, David Masterson wrote:
[EMAIL PROTECTED] wrote:
http://cygwin.com/acronyms/#PCYMTNQREAIYR. Thanks.
On Sat, 2 Jul 2005, Nick Kirchner wrote:
I just installed Cygwin on my Windows 98 computer and tried playing
around with Emacs. Having toyed with it a little in the
On Tue, Jul 05, 2005 at 07:59:32AM -0700, Yitzchak Scott-Thoennes wrote:
On Tue, Jul 05, 2005 at 10:17:28AM -0400, Christopher Faylor wrote:
The malloc implementation in perl was updated to the latest version of
Doug Lea's malloc so there is a possibility that this is a malloc bug.
However, given
On Tue, Jul 05, 2005 at 12:52:49PM -0400, Christopher Faylor wrote:
On Tue, Jul 05, 2005 at 07:59:32AM -0700, Yitzchak Scott-Thoennes wrote:
On Tue, Jul 05, 2005 at 10:17:28AM -0400, Christopher Faylor wrote:
The malloc implementation in perl was updated to the latest version of
Doug Lea's malloc
At 04:02 AM 7/5/2005, you wrote:
Michael Bax bax3.NO at SPAM.bigfoot.com writes:
I discovered that my .history file was 53 MB in size! This is with
history 1024
savehist(1024 merge)
in my .login.
wc .history
0 3316299 53060768 .history
I've got the same problem with the
Mikael Eriksson wrote:
Not sure if this is the right list, I do hope so.
Please also cc me since I'm not subscribed.
When installing subversion via setup.exe, crypt is not installed.
Therefore the message cygcrypt-0.dll could not be found is displayed
when I run svn.exe
Actually subversion
I am trying to test KDE 3.4 (and Qt 3.3) on Cygwin.
I have installed the additional packages needed for KDE 3.4 and I even did a
complete re-install of all packages to ensure that I have a clean system.
when I start bash and enter 'echo $path'. This is the path statement returned.
Jacek Piskozub wrote:
Dave,
Can't locate mozLock.pm in @INC (@INC contains: /usr/lib/perl5/5.8/cygwin
Find it attached.
Chris will probably kill me when he wakes up :-(
Lol.
Gerrit
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports:
Hi,
main.c below is for loading the shared library module.dll
/* command to create main.exe
cl -c main.c
link main.obj
*/
#include stdio.h
#include windows.h
int main(){
void *handle;
int (*fp)();
char *modname = ./module.dll;
HMODULE h;
void (*init)();
It is annoying that cygcheck exits with status 0, even if it could not find a
file:
$ cygcheck /bin/lilypond.exe
C:/cygwin/bin/lilypond.exe
C:/cygwin/bin\cygwin1.dll
C:\WINNT\system32\ADVAPI32.DLL
C:\WINNT\system32\NTDLL.DLL
C:\WINNT\system32\KERNEL32.DLL
Igor Pechtchanski [EMAIL PROTECTED] writes:
On Tue, 5 Jul 2005, Dave Korn wrote:
[...]
Found: C:\Cygwin\bin\cp.exe
Found: C:\Utils\GnuWin32\bin\cp.exe
Warning: C:\Cygwin\bin\cp.exe hides C:\Utils\GnuWin32\bin\cp.exe
[snip more of the same]
Not Found: sh
!
Ross MacGillivray wrote:
I am trying to test KDE 3.4 (and Qt 3.3) on Cygwin.
I have installed the additional packages needed for KDE 3.4
and I even did a complete re-install of all packages to
ensure that I have a clean system.
when I start bash and enter 'echo $path'. This is the path
The release notes for 1.5.18 state that strtoimax was added. But compare
the output of the following:
$ uname -a
CYGWIN_NT-5.0 eblake 1.5.18(0.132/4/2) 2005-07-02 20:30 i686 unknown unknown
Cygwin
$ cat foo.c
#include stdio.h
#include inttypes.h
int main(int argc, char**argv)
{
when I start bash and enter 'echo $path'. This is the path statement
returned.
Not sure how you've got things setup, but `echo $path` should result in
an empty return statement. the variable is PATH not path, case
sensitive.
Or maybe you are thinking of tcsh syntax, where $path
On Tue, Jul 05, 2005 at 07:25:04PM +, Eric Blake wrote:
It is annoying that cygcheck exits with status 0, even if it could not find a
file:
$ cygcheck /bin/lilypond.exe
C:/cygwin/bin/lilypond.exe
C:/cygwin/bin\cygwin1.dll
C:\WINNT\system32\ADVAPI32.DLL
C:\WINNT\system32\NTDLL.DLL
On Tue, Jul 05, 2005 at 08:26:26PM +, Eric Blake wrote:
The release notes for 1.5.18 state that strtoimax was added. But compare
the output of the following:
$ uname -a
CYGWIN_NT-5.0 eblake 1.5.18(0.132/4/2) 2005-07-02 20:30 i686 unknown unknown
Cygwin
$ cat foo.c
#include stdio.h
#include
On 05/07/05, FischRon wrote:
Actually I wasn't able to use -d with mkpasswd, because this command
hung, so I did a mkpasswd -l /etc/passwd instead. Maybe I should
rerun mkgroup -l (without -d option)?
Really hung, or just taking a very very long time (it will, if it is a
large domain)?
If the
Ross MacGillivray ross_macgillivray at yahoo.ca writes:
I am trying to test KDE 3.4 (and Qt 3.3) on Cygwin.
I have installed the additional packages needed for
KDE 3.4 and I even did a
complete re-install of all packages to ensure that I have a clean system.
when I start bash and
On Tue, Jul 05, 2005 at 08:26:26PM +, Eric Blake wrote:
$ gcc -o foo foo.c
/cygdrive/c/DOCUME~1/eblake/LOCALS~1/Temp/ccQLtRpQ.o:foo.c:(.text+0x42):
undefined reference to `_strtoimax'
collect2: ld returned 1 exit status
WJFFM. It seems like you have an outdated libcygwin.a.
Weird:
$
$ cat foo.c
#include stdio.h
#include inttypes.h
int main(int argc, char**argv)
{
printf(%llx\n, strtoll(1, NULL, 10));
return 0;
}
$ gcc -o foo foo.c
$ ./foo
a0001
This, I can confirm. PTC.
No patch necessary (PEBCAK). strtoimax is in inttypes.h, but strtoll
is in
Yu-Cheng Chou wrote:
int main(){
void *handle;
int (*fp)();
char *modname = ./module.dll;
HMODULE h;
void (*init)();
printf(hello1\n);
h = LoadLibrary(cygwin1.dll);
printf(hello1 h = %p\n, h);
init = ( void (*)())GetProcAddress(h, cygwin_dll_init);
printf(init =
Hi all
Dave Korn dave.korn at artimi.com writes:
Anyway, break __assert works for catching the assertions. Dunno what's
up with the SEGVs.
well, it turns out Dave's suggestion doesn't work anymore on latest cygwin
(tested this only with C++ programs):
GNU gdb
(If this is not the right place for this, please direct me.)
I have recently updated an old Windows setup, including a new cygwing
installation. We use this machine for nightly builds, using a shell
script that connects to multiple machines and runs the builds
(DevStudio in the Windows case).
Hi Chris,
I've done a clean install of cygwin with dll 1.5.18 and also tried
snapshots from 2nd, 4th and 5th. Unfortunetly issues relating to
threading and memory leaks as described in the following post - still
exists:
http://sources.redhat.com/ml/cygwin/2005-06/msg00186.html
Regards
At 08:45 PM 7/5/2005, you wrote:
(If this is not the right place for this, please direct me.)
I have recently updated an old Windows setup, including a new cygwing
installation. We use this machine for nightly builds, using a shell
script that connects to multiple machines and runs the builds
At 02:05 AM 7/5/2005, Question NS wrote:
While I install NS2.28, it tells no gcc, but I
actually installed gcc, and during the installation,
it said my gcc is not a cross compile, I don't know if
this is matter. And if it is, which gcc version shall
I install? I ran the strace.exe command, get the
On Jul 5, Larry Hall wrote:
At 08:45 PM 7/5/2005, you wrote:
(If this is not the right place for this, please direct me.)
I have recently updated an old Windows setup, including a new cygwing
installation. We use this machine for nightly builds, using a shell
script that connects to
Hi Chris,
Actually things are getting slightly worse, basically same test scenario
(not the full blown app you keep on mentioning), but this time mutex
locks are failing + the ye-olde massive memory leaks.
I have the mutex set to default mode, and after a few seconds of the
test running mutexes
On Wed, Jul 06, 2005 at 04:17:34AM +, Arash Partow wrote:
I have the mutex set to default mode, and after a few seconds of the
test running mutexes locking unlocking, all of a sudden the mutexes
stop locking, and basically report back EBUSY from pthread_mutex_lock.
The message that you are
Arash Partow wrote:
I've done a clean install of cygwin with dll 1.5.18 and also tried
snapshots from 2nd, 4th and 5th. Unfortunetly issues relating to
threading and memory leaks as described in the following post - still
exists:
http://sources.redhat.com/ml/cygwin/2005-06/msg00186.html
I
90 matches
Mail list logo
