>> mount -u -b --change-cygdrive-prefix "/cygdrive"
>> What do I do to get rid of this user mount, please?
Try
umount -uc
I think -uc will be sufficient for the cygdrive-prefix; the switch -uA would
get rid of _all_ user mounts, and you don't seem to have any left? HTH.
Fergus
--
Uns
Hi,
Am a newbie to cygwin. Am trying to install cygwin as per the
procedure in the web.
http://cplus.about.com/od/compilersandides/l/aa061204a.htm
After installation i observe that the /home directory is missing.
Other that this things are normal. I have logged into my system as a
local user in
One area that I've noticed slowness is in using the 'find' command
to search for old "tmp" files or to rebuild the locate database.
In tracing the Win32 file operations, find seems to perform multiple
file open operations for each file processed. One way to speed up
operations in this area might
On 02/06/05, prashanthu baragur <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Am a newbie to cygwin. Am trying to install cygwin as per the
> procedure in the web.
>
> http://cplus.about.com/od/compilersandides/l/aa061204a.htm
Wow, seven pages of installation instructions. Couldn't he have just
said 'fol
Original Message
>From: prashanthu baragur
>Sent: 02 June 2005 08:06
> Hi,
>
> Am a newbie to cygwin. Am trying to install cygwin as per the
> procedure in the web.
>
> http://cplus.about.com/od/compilersandides/l/aa061204a.htm
>
> After installation i observe that the /home directory i
Original Message
>From: Igor Pechtchanski
>Sent: 31 May 2005 20:34
> On Tue, 31 May 2005, Christopher Faylor wrote:
>
>> On Tue, May 31, 2005 at 02:08:22PM -0400, Igor Pechtchanski wrote:
>>> On Tue, 31 May 2005, Dave Korn wrote:
>>>
Original Message
> From: Igor Pechtch
Dave,
I did not ran
mkpasswd -l -d >/etc/passwd" and "mkgroup -l -d >/etc/group"
Since i did "mkdir /home", /home is just like "/temp" directory.
Any care to be taken during cygwin installation ??
Thanks
Prashanth
On 6/2/05, Dave Korn <[EMAIL PROTECTED]> wrote:
> Original Message
Hi,
here's a little study, allocating / freeing mem in a loop, once with the
C malloc/free, once (-DUSE_CXX_HEAP) using new/delete. It reproduces the
factor ~3 for gcc cygwin.
I've built it with MSVC's cl 7.0, gcc 3.3.3, with and without
-mno-cygwin, using the cygwin-inst snapshot from 20050528,
From: "Dave Korn"
Subject: RE: OLOCA
Date: Thu, 2 Jun 2005 14:19:15 +0100
Original Message
>From: Igor Pechtchanski
>Sent: 31 May 2005 20:34
> On Tue, 31 May 2005, Christopher Faylor wrote:
>
>> On Tue, May 31, 2005 at 02:08:22PM -0400, Igor Pechtchanski wrote:
>>> On Tue, 31 May 2005
bonhard.uklinux.net> writes:
>
> >> mount -u -b --change-cygdrive-prefix "/cygdrive"
> >> What do I do to get rid of this user mount, please?
>
Thanks! I've got rid of all user mount on my Windows Server 2003 but I still
have the same problem of having the services up.
Thanks!
Regards,
Ja
> amusingling enough -- their
> execution times are *slower* than cygwin's... Of
this is a joke right? I found SFU to be at least 2-3
times faster in loading and executing programs in
general. Its too bad their POSIX imple. is less than
half baked and unuseable for building any package
OOTB.
> c
On Thu, 2 Jun 2005 12:27:45 +, Richard Copley wrote:
> On 02/06/05, prashanthu baragur <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> Am a newbie to cygwin. Am trying to install cygwin as per the
>> procedure in the web.
>>
>> http://cplus.about.com/od/compilersandides/l/aa061204a.htm
>
> Wow, seve
On Thu, 2 Jun 2005, Karl M wrote:
> > From: "Dave Korn"
> > Subject: RE: OLOCA
> > Date: Thu, 2 Jun 2005 14:19:15 +0100
> >
> > Original Message
> > >From: Igor Pechtchanski
> > >Sent: 31 May 2005 20:34
> >
> > > On Tue, 31 May 2005, Christopher Faylor wrote:
> > >
> > >> On Tue, May 31, 2
On Thu, 2 Jun 2005, Linda W wrote:
> In tracing the Win32 file operations, find seems to perform multiple
> file open operations for each file processed. One way to speed up
> operations in this area might be to keep a "cache" of the last "N"
> file handles. I suspect it's just the Windows path
On Thu, 2 Jun 2005, Sunil wrote:
> > amusingling enough -- their
> > execution times are *slower* than cygwin's... Of
>
> this is a joke right? I found SFU to be at least 2-3
> times faster in loading and executing programs in
> general. Its too bad their POSIX imple. is less than
> half baked an
On Thu, Jun 02, 2005 at 01:01:22PM -0400, Igor Pechtchanski wrote:
>On Thu, Jun 02, 2005 at 06:57:25AM -0700, Karl M wrote:
>>On Thu, Jun 02, 2005 at 02:19:15PM +0100, Dave Korn wrote:
>>> How about OSCA: Only Specifically Cygwin Acronyms ?
>>
>>And then once each year, we can have a big awards
Original Message
>From: Igor Pechtchanski
>Sent: 02 June 2005 18:08
> On Thu, 2 Jun 2005, Sunil wrote:
>
>>> amusingling enough -- their
>>> execution times are *slower* than cygwin's... Of
>>
>> this is a joke right? I found SFU to be at least 2-3
>> times faster in loading and executi
On Thu, Jun 02, 2005 at 01:02:30PM -0400, Igor Pechtchanski wrote:
>On Thu, 2 Jun 2005, Linda W wrote:
>>In tracing the Win32 file operations, find seems to perform multiple
>>file open operations for each file processed. One way to speed up
>>operations in this area might be to keep a "cache" of
On Wed, 1 Jun 2005 19:09:35 -0400 , Christopher Faylor wrote:
>Please stop doing this. I do read email. I will read your email
>when I have time. Pinging me is not going to help.
You should at least answer "OK. the problem is under investigation" or
something else.
angelo.
--
Unsubscribe
Hi,
The pthread_cleanup_push and pthread_cleanup_pop macros seems to be
broken in the CVS (misplaced brackets). I hope I'm not posting to the
wrong list, but here's the patch...
--- ./winsup/cygwin/include/pthread.h.orig 2005-06-02
20:34:00.0 +0300
+++ ./winsup/cygwin/include/pthread
On Thu, 2 Jun 2005, Christopher Faylor wrote:
> On Thu, Jun 02, 2005 at 01:01:22PM -0400, Igor Pechtchanski wrote:
> >On Thu, Jun 02, 2005 at 06:57:25AM -0700, Karl M wrote:
> >>On Thu, Jun 02, 2005 at 02:19:15PM +0100, Dave Korn wrote:
> >>> How about OSCA: Only Specifically Cygwin Acronyms ?
> Any favorable mention of SFU on this list had better
> be a joke. :-)
:)
but can't deny the truth. Seriously, open source on
windows can't do better than what it does(upto the
limits provided by OS) in terms of efficiency. Its
hardly at fault, the thing below it is so darn closed.
Everything on
On Thu, Jun 02, 2005 at 02:02:07PM -0400, Igor Pechtchanski wrote:
>On Thu, 2 Jun 2005, Christopher Faylor wrote:
>>On Thu, Jun 02, 2005 at 01:01:22PM -0400, Igor Pechtchanski wrote:
>>>On Thu, Jun 02, 2005 at 06:57:25AM -0700, Karl M wrote:
On Thu, Jun 02, 2005 at 02:19:15PM +0100, Dave Korn w
On Thu, 2 Jun 2005, Christopher Faylor wrote:
> On Thu, Jun 02, 2005 at 02:02:07PM -0400, Igor Pechtchanski wrote:
> >On Thu, 2 Jun 2005, Christopher Faylor wrote:
> >>On Thu, Jun 02, 2005 at 01:01:22PM -0400, Igor Pechtchanski wrote:
> >>>On Thu, Jun 02, 2005 at 06:57:25AM -0700, Karl M wrote:
>
Here is a patch to thread.cc that allows _lock to process signals. The
patch is against the 1.178 version of thread.cc found in cvs.
--- thread.cc.orig Thu Jun 2 11:17:39 2005
+++ thread.cc Thu Jun 2 11:20:00 2005
@@ -1543,8 +1543,24 @@
}
else
{
- WaitForSingleObject
On Thu, 2 Jun 2005, Sunil wrote:
> > Any favorable mention of SFU on this list had better
> > be a joke. :-)
>
> :)
>
> but can't deny the truth. Seriously, open source on
> windows can't do better than what it does(upto the
> limits provided by OS) in terms of efficiency. Its
> hardly at fault, t
On Thu, Jun 02, 2005 at 11:04:40AM -0700, Sunil wrote:
>>Any favorable mention of SFU on this list had better be a joke. :-)
>
>:)
>
>but can't deny the truth. Seriously, open source on windows can't do
>better than what it does(upto the limits provided by OS) in terms of
>efficiency. Its hardly
On Thu, Jun 02, 2005 at 02:19:51PM -0400, Igor Pechtchanski wrote:
>P.S. How does the OLOCA entry look? :-)
Poifect.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FA
> OTOH, Corinna is hard at work adding low-level Nt* calls to cygwin so,
> if it wasn't for the requirement that everything has to work
> on Windows
> 9x, the DLL would be smaller and faster. Instead, every system call
> currently needs to have a "do this if it's NT and that if
> it's 9x" test
>
On Thu, 2 Jun 2005, Robb, Sam wrote:
> > OTOH, Corinna is hard at work adding low-level Nt* calls to cygwin so,
> > if it wasn't for the requirement that everything has to work on
> > Windows 9x, the DLL would be smaller and faster. Instead, every
> > system call currently needs to have a "do thi
Sunil wrote:
machine 1: 533Mhz, 10GB 5400rpm disk, 384MB RAM, SFU
on W2K, -> build time for texinfo = 345 seconds.
machine 2: 2400Mhz, 100GB 7200rpm disk, 768MB RAM,
cygwin 1.5.17 on WinXP, -> build time for texinfo =
334 seconds.
-> 345 seconds vs. 334 seconds
So actually, cygwin is faster t
On Thu, Jun 02, 2005 at 02:38:06PM -0400, Robb, Sam wrote:
>>OTOH, Corinna is hard at work adding low-level Nt* calls to cygwin so,
>>if it wasn't for the requirement that everything has to work on Windows
>>9x, the DLL would be smaller and faster. Instead, every system call
>>currently needs to h
Yuval Turgeman wrote:
Hi,
The pthread_cleanup_push and pthread_cleanup_pop macros seems to be
broken in the CVS (misplaced brackets). I hope I'm not posting to the
wrong list, but here's the patch...
I'm pretty sure the braces are placed like that *deliberately*, to force
you to bracket code
On Wed, Jun 01, 2005 at 09:58:24PM -0700, Linda W wrote:
> FYI -- I discovered the cause of a problem I had in manipulating the
> Registry. There is a bug in the Win32 Registry manipulation routines.
> Both TieRegistry and the original Registry interface apparently
> use an older interface -- some
Gerrit P. Haase wrote:
> Sunil wrote:
>
>> machine 1: 533Mhz, 10GB 5400rpm disk, 384MB RAM, SFU
>> on W2K, -> build time for texinfo = 345 seconds.
>> machine 2: 2400Mhz, 100GB 7200rpm disk, 768MB RAM,
>> cygwin 1.5.17 on WinXP, -> build time for texinfo =
>> 334 seconds.
>
>
> -> 345 seconds vs
On Thu, Jun 02, 2005 at 12:52:56PM -0700, Shankar Unni wrote:
>Yuval Turgeman wrote:
>>Hi,
>>The pthread_cleanup_push and pthread_cleanup_pop macros seems to be
>>broken in the CVS (misplaced brackets). I hope I'm not posting to the
>>wrong list, but here's the patch...
>
>I'm pretty sure the brac
Igor Pechtchanski wrote:
On Thu, 2 Jun 2005, Robb, Sam wrote:
Is there any reason why the cygwin DLL couldn't be built
twice: once for Win9x, and once for WinNT-based systems?
Aside from potential installation issues ("install this
version of the DLL under 9x, that version under NT), it
seems
At 01:37 PM 6/2/2005, you wrote:
>On Wed, 1 Jun 2005 19:09:35 -0400 , Christopher Faylor wrote:
>
>>Please stop doing this. I do read email. I will read your email
>>when I have time. Pinging me is not going to help.
>
>You should at least answer "OK. the problem is under investigation" or
>so
I trying to debug an aparrent hang problem in clamav's clamd.
Under my test load, I can usually get clamd to hang rather easily. Today I
got lucky and managed to get an strace of the hang happening (usually the
hang doesn't happen while stracing...). When this app hung, it stopped
consuming
On Thu, 2 Jun 2005, Gerrit P. Haase wrote:
> Igor Pechtchanski wrote:
>
> > On Thu, 2 Jun 2005, Robb, Sam wrote:
> > > Is there any reason why the cygwin DLL couldn't be built
> > > twice: once for Win9x, and once for WinNT-based systems?
> > >
> > > Aside from potential installation issues ("inst
Igor Pechtchanski wrote:
> Dropping it altogether would be unfortunate. Providing Win98 support DLLs
> in a separate package is a possibility. There's still the point that CGF
> raised, about there being many more people with the knowledge of Win32 API
> than those with the knowledge of Nt* API.
Am Donnerstag, 2. Juni 2005 23:43 schrieb Keith Moore:
> Igor Pechtchanski wrote:
>
> > Dropping it altogether would be unfortunate. Providing Win98 support DLLs
> > in a separate package is a possibility. There's still the point that CGF
> > raised, about there being many more people with the k
Gerrit P. Haase wrote:
Alternatively, we could drop Win98 support.
Yes!
The requirement made sense back when WinXP wasn't dominant yet. By now,
the last machines still running Win9x are dying or being replaced at a
fairly high rate. I'm glad Cygwin was available during the years it's
tak
No!
I am supporting applications requiring cygwin on '95 and '98 that are
not going away anytime soon.
Terry
Gerrit P. Haase wrote:
>
> Alternatively, we could drop Win98 support.
Yes!
The requirement made sense back when WinXP wasn't dominant yet. By now,
the last machines still running Wi
Terry Dabbs wrote:
I am supporting applications requiring cygwin on '95 and '98 that are
not going away anytime soon.
That's fine, but do you really need new functionality?
Again, I'm not saying "delete all Cygwin binaries that support Win9x".
I'm saying "stop requiring Win9x compatibility i
Terry Dabbs wrote:
No!
I am supporting applications requiring cygwin on '95 and '98 that are
not going away anytime soon.
I have not seen any Win98/ME PC since about 5 years, we're using NT all
over the place. As I started to work in this business NT4 was current,
then W2K came up, now every
On Fri, 3 Jun 2005, Gerrit P. Haase wrote:
> Terry Dabbs wrote:
>
> > No!
> >
> > I am supporting applications requiring cygwin on '95 and '98 that are
> > not going away anytime soon.
>
> I have not seen any Win98/ME PC since about 5 years, we're using NT all
> over the place. As I started to wo
> From: Dr Ivan D. Reid
>
> Hello David;
> I see you do regular reports on compiling gcc-4 on cygwin.
>
> Would it be possible for you to send me a copy of the
> scripts you
> use? I must be missing something as I get a failure when
> make bootstrap-lean
> processes libiberty -- a
Hi,
On 26 May 2005, Christopher Faylor wrote:
> I've made a new version of the Cygwin DLL and associated utilities
> available for download. As usual, a list of what has changed
> is below.
> [...]
> cgf: Make dlopen search /usr/bin (for Windows compatibility)
> and /usr/lib (for UNIX compati
At 07:33 PM 6/2/2005, you wrote:
>Hi,
>
>On 26 May 2005, Christopher Faylor wrote:
>
>> I've made a new version of the Cygwin DLL and associated utilities
>> available for download. As usual, a list of what has changed
>> is below.
>> [...]
>
>> cgf: Make dlopen search /usr/bin (for Windows compa
Might it be possible to build 2 versions and have the package
dynamically install the correct version?
On the other hand, instead of "if (win98)..." one could have a
cygwin1.dll that chooses a 2nd library to load and all entry points are
either runtime indirect calls into the 2nd library (cygwin_
I know, but truthfully, you are taking my response a bit out of context.
I was responding, specifically to CFG's message:
Christopher Faylor wrote:
> Yep. This is pretty much what I expected. Now we'll see a stream of
> people commenting on slowness and speculating on the cause without
> spen
On Thu, Jun 02, 2005 at 11:57:26PM +0200, Ralf Habacker wrote:
>Am Donnerstag, 2. Juni 2005 23:43 schrieb Keith Moore:
>> Igor Pechtchanski wrote:
>>>Dropping it altogether would be unfortunate. Providing Win98 support
>>>DLLs in a separate package is a possibility. There's still the point
>>>tha
On Fri, Jun 03, 2005 at 12:33:55AM +0100, Adye, TJ (Tim) wrote:
>Hi,
>
>On 26 May 2005, Christopher Faylor wrote:
>
>> I've made a new version of the Cygwin DLL and associated utilities
>> available for download. As usual, a list of what has changed
>> is below.
>> [...]
>
>> cgf: Make dlopen sea
Linda W wrote:
> Not everyone can do all things. I didn't "speculate" on the cause, I
> noticed multiple opens for a program that really only needs stat/lstat I
> believe.
In order to implement stat(), cygwin has to call NtQueryInformationFile
(GetFileInformationByHandle for 9x/me) and
Igor Pechtchanski wrote:
On Fri, 3 Jun 2005, Gerrit P. Haase wrote:
Terry Dabbs wrote:
No!
I am supporting applications requiring cygwin on '95 and '98 that are
not going away anytime soon.
I have not seen any Win98/ME PC since about 5 years, we're using NT all
over the place. As I sta
On Thu, Jun 02, 2005 at 06:32:00PM -0700, Brian Dessent wrote:
>I think you will find that the cygwin DLL (and most of the base system)
>you are using now was probably cross-compiled.
Yup. And, these days, it's cross-compiled on a Debian-based system.
cgf
--
Unsubscribe info: http://cygwin
On Fri, 3 Jun 2005, Billinghurst, David (CALCRTS) wrote:
> > From: Dr Ivan D. Reid
> >
> > Hello David;
> > I see you do regular reports on compiling gcc-4 on cygwin.
> >
> > Would it be possible for you to send me a copy of the
> > scripts you
> > use? I must be missing something as
At 09:40 PM 6/2/2005, Christopher Faylor wrote:
>On Thu, Jun 02, 2005 at 06:32:00PM -0700, Brian Dessent wrote:
>>I think you will find that the cygwin DLL (and most of the base system)
>>you are using now was probably cross-compiled.
>
>Yup. And, these days, it's cross-compiled on a Debian-based
On Thu, Jun 02, 2005 at 11:21:16PM -0400, Larry Hall wrote:
>At 09:40 PM 6/2/2005, Christopher Faylor wrote:
>>On Thu, Jun 02, 2005 at 06:32:00PM -0700, Brian Dessent wrote:
>>>I think you will find that the cygwin DLL (and most of the base system)
>>>you are using now was probably cross-compiled.
On Fri, 3 Jun 2005, Dr Ivan D. Reid wrote:
> On Fri, 3 Jun 2005, Billinghurst, David (CALCRTS) wrote:
> >
> > Ivan,
> >
> > I have a patch of Danny Smith's in my local tree for this
> > http://gcc.gnu.org/ml/gcc-patches/2005-05/msg9.html
> >
> > There are later versions under discussion, in
61 matches
Mail list logo
