Re: sshd: server refused our key
Harig, Mark A. wrote: You might try reading a recent thread of messages in the mailing list archive with the subject line: "Is RSA authentication on SSH still broken?" It started back on 5 November 2002. Thanks to mention this thread, but this can't fix the problem of windows shared home directories: i.e.: You have your home directory on a SGI UNIX host called anyhost. You set permissions of your home directory to 700, you set permissions of your .ssh directory to 700 you hide all files of .ssh (600). Your entry in passwd might be: the_king::1:1:Elvis Presley,U-STILLHERE\elvis,S-1-5-21-1234-5678-9012-1000:://anyhost/the_king:/bin/bash Now you are a windows shared user and permissions of all your shared files and folders give read permission to anyone: permissions of your .ssh on UNIX host anyhost: -rw---1 mk group 545 Nov 20 08:48 authorized_keys -rw---1 mk group 546 Nov 20 08:48 authorized_keys2 -rw---1 mk group 887 Nov 19 13:44 id_rsa -rw---1 mk group 218 Nov 19 13:44 id_rsa.pub -rw---1 mk group 523 Nov 19 13:44 identity -rw---1 mk group 327 Nov 19 13:44 identity.pub -rw---1 mk group1442 Nov 20 11:50 known_hosts -rw---1 mk group 512 Nov 20 11:50 random_seed permissions of your .ssh inside ssh session on Windows host: -rw-r--r--1 mk Domain U 545 Nov 20 08:48 authorized_keys -rw-r--r--1 mk Domain U 546 Nov 20 08:48 authorized_keys2 -rw-r--r--1 mk Domain U 887 Nov 19 13:44 id_rsa -rw-r--r--1 mk Domain U 218 Nov 19 13:44 id_rsa.pub -rw-r--r--1 mk Domain U 523 Nov 19 13:44 identity -rw-r--r--1 mk Domain U 327 Nov 19 13:44 identity.pub -rw-r--r--1 mk Domain U 1442 Nov 20 11:50 known_hosts -rw-r--r--1 mk Domain U 512 Nov 20 11:52 random_seed Thus ssh demon must reject your identity file because it is readable by anyone! I would like to setup CYGWIN to hide all user files all others but to have access to all local files and folders of Windows host according to security settings of the files. Doe's anyone knows? -Original Message- From: Manfred Köhler [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 11:34 AM To: Harig, Mark A. Cc: [EMAIL PROTECTED] Subject: Re: sshd: server refused our key Mark, I think we can't solve the problem, because my home is a windows share. Every windows share is mounted with permission 755! Therefore sshd rejects the files ins ~/.ssh which should be private. So I'm prompted for password. Please refer http://sources.redhat.com/ml/cygwin/2001-10/msg01011.html Manfred Harig, Mark A. wrote: Please keep all replies on the cygwin mailing list. This helps you because more people are able to diagnose your problem. It helps others because they are able to search the mailing list archives for useful information. 1. In your reply below, you list the following for your home directory: drwxr-xr-x 138 mk group 24576 Nov 20 11:48 . Try: chmod 750 ~ chgrp SYSTEM ~ 2. And for your ~/.ssh directory: drwxr-xr-x2 mk group 4096 Nov 19 13:44 .ssh Try: chmod 700 ~/.ssh Please change both ~ and ~/.ssh. It is not enough to only change one. If these changes do not fix your problem, then please include the output of the 'mount' command in your reply. -Original Message- From: Manfred Köhler [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 5:58 AM To: Harig, Mark A. Subject: Re: RE: sshd: server refused our key "Harig, Mark A." <[EMAIL PROTECTED]> schrieb am 19.11.02 17:11:23: As requested at http://cygwin.com/bugs.html: o Please describe how to reproduce the problem, including a test case, if possible. In your case, please list the commands that you ran to set up sshd on your Cygwin machine. ssh-host-config -y ...set cygwin to defaults chmod 755 /var/empty mkgroup -l -d domain>/etc/group mkpasswd -l -d domain>/etc/passwd o Please include at least the version number of the Cygwin release you are using along with the operating system name and its version number, for example, "cygwin v1.3.13 under NT 4.0". Please refer attached file. o Most of the information about your Cygwin environment is listed by running 'cygcheck -s -v -r > cygcheck.txt'. Please include cygcheck.txt *AS AN ATTACHMENT* to your report. It is important that you include it as an attachment so that searches of the mailing-list archives give fewer false matches. Please refer attached file Some things to check (that is, email back to this mailing list): The permissions and ownership of: - your home directory drwxr-xr-x 138 mk group 24576 Nov
Re: pipe performance problem
thomas <[EMAIL PROTECTED]> wrote: > it seems that the pipe code with recent cygwin versions causes a > performance problem when much data (3.6 MB per second in this case) is > transferred from one program to another. > > i use mkisofs to make an iso filesystem from files on the fly and pipe > the output directly to cdrecord which writes the fs to the cd-r. cmd > line looks like this: > > mkisofs -J -R -l * | cdrecord -dev=1,0,0 -v -dummy -speed=24 - Out of interest, does it work if you use a temporary file, instead of a pipe? (Just want to narrow the problem as far as possible). Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: gcc-3.2-3: bootstrap build fails (HAVE_DECL_GETOPT not in config.h?)
> -Original Message- > From: Christopher Faylor [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, November 19, 2002 5:02 PM > To: [EMAIL PROTECTED] > Subject: Re: gcc-3.2-3: bootstrap build fails (HAVE_DECL_GETOPT not in > config.h?) > > > On Wed, Nov 20, 2002 at 10:14:59AM +1100, Nigel Stewart & Fiona > Smith wrote: > >Michael, > > > >I have encountered the same problem on my setup. > > > >Regards, > > I have not encountered the same problem in my setup. You may have something wrong with your setup, i.e. you may have other changes besides what's in gcc-3.2-3. I looked at the gcc/include/getopt.h in CVS at gcc.gnu.org and they have the following change (which is basically what I came up with also): === RCS file: /cvs/gcc/gcc/include/getopt.h,v retrieving revision 1.6 retrieving revision 1.6.30.1 diff -u -r1.6 -r1.6.30.1 --- gcc/include/getopt.h2001/03/14 19:44:38 1.6 +++ gcc/include/getopt.h2002/11/09 18:12:56 1.6.30.1 @@ -111,7 +111,7 @@ errors, only prototype getopt for the GNU C library. */ extern int getopt (int argc, char *const *argv, const char *shortopts); #else /* not __GNU_LIBRARY__ */ -# if !defined (HAVE_DECL_GETOPT) +# if !defined (HAVE_DECL_GETOPT) && !defined (__cplusplus) extern int getopt (); # endif #endif /* __GNU_LIBRARY__ */ === Although there still maybe a more general problem with the way GCC's cpp finds header files. The compile of pure.cc is finding the in /usr/include which includes , but instead of getting the getopt.h in /usr/include, it's grabbing the one in ./gcc/include. I vaguely remember something in the ISO C standard regarding C pre-processing that states all angle-bracket includes strictly search for files in the "standard directories" before searching in the "" include directories. Therefore the ./gcc/include/getopt.h shouldn't come into play. In addition to the change shown above, to make the file more portable, line 102 #if defined (__STDC__) && __STDC__ should be changed to #if (defined (__STDC__) && __STDC__) || defined (__cplusplus) since ISO C++ Appendix C.1.9 Clause 16.8.1 says that "Whether __STDC__ is defined and if so, what its value is, are implementation-defined". G++ defines it, but doesn't have to. If getopt.h was compiled with a C++ compiler that chose not to define/set __STDC__, the build would again break. Mike > > HTH, > cgf > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: bug in cygwin select/socket code(?)
On Fri, Nov 22, 2002 at 01:11:35AM -0500, Wayne Clerke wrote: > The Perl code below creates a non-blocking socket and attempts > to connect it to 127.0.0.1:2 (which should be immediately refused), > The loop shows the socket becomes briefly writable according to > IO::Select. Is there some logic behind this that I'm missing? > It was ok in cygwin v1.3.12-2, but hasn't worked as I expected > in the last two releases (1.3.14-1, 1.3.15-2) . It's ok as it is now. It was incorrect before. The connect doesn't return immediately and FD_ISSET (fd, &writefds) returns true when the connection is refused. See SUSv3: http://www.opengroup.org/onlinepubs/007904975/functions/select.html> If a non-blocking call to the connect() function has been made for a socket, and the connection attempt has either succeeded or failed leaving a pending error, the socket shall be marked as writable. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Any known issues with signal delivery on 2-cpu boxes?
On Thu, Nov 21, 2002 at 11:47:22PM -0500, Christopher Faylor wrote: > I'm regenerating a snapshot right now which may become 1.3.16. > Please try it. Might I ask whether there are any fixes or remaining known problems with signals being lost on multi-processor machines? The much reported 'rsync hangs' bug (search for those words in the mail-archive if interested) I hunted down last month to SIGUSR2 being issued by one half of an rsync fork but not received by the other. The bug is apparently still there - frustratingly intermittent, I can't now reproduce it myself with the latest cygwin release, but a colleague of mine is seeing it about 50% of the time. However we've only ever hit the problem on dual processor boxes. I'm happy to keep exploring, but there have been no responses by any of the cygwin experts to the bug reports, so I'm not clear whether cygwin is simply not expected to handle signals reliably on a dual processor box, or whether simply not enough information has been given. Thanks Anthony This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase & Co., its subsidiaries and affiliates. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: pipe performance problem
Max Bowsher <[EMAIL PROTECTED]> wrote: > thomas <[EMAIL PROTECTED]> wrote: >> it seems that the pipe code with recent cygwin versions causes a >> performance problem when much data (3.6 MB per second in this case) is >> transferred from one program to another. >> >> i use mkisofs to make an iso filesystem from files on the fly and pipe >> the output directly to cdrecord which writes the fs to the cd-r. cmd >> line looks like this: >> >> mkisofs -J -R -l * | cdrecord -dev=1,0,0 -v -dummy -speed=24 - > Out of interest, does it work if you use a temporary file, instead of a > pipe? > (Just want to narrow the problem as far as possible). yes works without any problems. my first bug report was a bit misleading here. i only get problems when i pipe the whole thing. thomas -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
default install, all executables have executable bit on but [ -xscript ] fails..
This probably is a newbie question, I searched the FAQ and the mailinglists but could not find anything. I just installed Cygwin on our Win2000 Terminal Server as Administrator. I then logged as myself, started cygwin, logged in to our CVS server, and downloaded the software I am trying to port to Windows. The package uses autoconf et al, so I have an autogen script that looks like this: #!/bin/sh set -x rm -f config.cache #gettextize --force --copy libtoolize --force --copy aclocal autoheader autoconf automake --copy --add-missing ./configure --enable-debug However, running this script fails with: $ ./autogen.sh + rm -f config.cache + libtoolize --force --copy Can't find /usr/autotool/devel/bin/libtoolize + aclocal Can't find /usr/autotool/devel/bin/aclocal (rest of output cut off here) $ ls -l /usr/autotool/devel/bin/aclocal-1.7 -rwx-- 1 Administ None 9891 Oct 22 09:25 /usr/autotool/devel/bin/libtoolize This is a default cygwin.exe install, shouldn't the binaries have 755 permissions or something? my CYGWIN variable is "tty notitle glob ntsec ntea" Do I need to change all executables in c:\cygwin to 0755, using chmod -R as Administrator? Did I do something wrong in the installer? Thanks for any input, Ron Arts -- Netland Internet Services bedrijfsmatige internetoplossingen http://www.netland.nl Kruislaan 419 1098 VA Amsterdam info: 020-5628282 servicedesk: 020-5628280 fax: 020-5628281 Give me some chocolate and no one gets hurt! smime.p7s Description: S/MIME Cryptographic Signature
Re: 3rd time lucky? Apache startup woes
On Tuesday 19 Nov 2002 9:06 am, Ralf Habacker wrote:
[SNIP]>
> #define ERROR_INVALID_HANDLE 6L
> The rebase could not open the dll. Is this dll still used by any process ?
> Please make sure, this dll isn't used by any process.
>
> > gary@LADVENT ~
> > $ /usr/sbin/apachectl start
> > Syntax error on line 236 of /etc/apache/httpd.conf:
> > Cannot load /usr/lib/apache/libphp4.dll into server: dlopen: Win32 error
> > 31
>
> #define ERROR_GEN_FAILURE 31L
>
>
> Do you have tried ssp. ssp shows you which dll is load onto which address
> (Unfortunally I don't know if ssp works under winMe)
>
> $ ssp -v -d -dll 0x401000 0x44 `cygpath -aw /usr/sbin/httpd.exe `
> verbose messages enabled
[SNIP]
>
> Another possibility is to load apache with gdb and start it. Then you can
[SNIP]
>
> Ralf
Hi Ralf, all
I've finally had a chance to have a go with ssp (work keeps getting in the
way). Below is the output - sorry but I haven't got a clue what it's saying
so I home someone out there can help.
I've no idea how to start httpd via gdb so I can't run/capture that data.
gary@LADVENT /lib/apache
$ ssp -v -d -dll 0x401000 0x44 'cygpath -aw /usr/sbin/httpd.exe'
verbose messages enabled
stepping disabled; enable via OutputDebugString ("ssp on")
stepping disabled; enable via OutputDebugString ("ssp on")
profiling dll usage
profiling dll usage
prun: [00401000,0044] Running `cygpath -aw /usr/sbin/httpd.exe'
load dll bfb7: cmt3.l
load dll 70bd: slaidl
load dll bff4: ue3.l
load dll bfe6: avp3.l
load dll bff1: gi2dl
load dll 7800: mvr.l
load dll 7fbd: sel2dl
load dll bff6: kre3.l
load dll 6100: cgi1dls
create thread ffe71841 at bff92876 kre3.l
ODS: d0/0 "cYg 610CAAF0"
create thread ffe50505 at 61005400 cgi1dls
ODS: d0/0 "cYgstd 73fd00 d 3"
C:\cygwin\usr\sbin\httpd.exe
exit thread ffe71841, code=-1
exit thread ffe50505, code=-1
process ffe4ce2d ffe4cc75 exit 0
total cycles: 1, counted cycles: 0
Main-Thread Other-Thread BaseAddr DLL Name
1 100% 0 0% bff6 kre3.l
gary@LADVENT /lib/apache
$
--
Gary Stainburn
This email does not contain private or confidential material as it
may be snooped on by interested government parties for unknown
and undisclosed purposes - Regulation of Investigatory Powers Act, 2000
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: default install, all executables have executable bit on but [-x script ] fails..
Ron Arts <[EMAIL PROTECTED]> writes: > This probably is a newbie question, I searched the FAQ and the mailinglists > but could not find anything. Looks like an unidentified bug. See: http://sources.redhat.com/ml/cygwin/2002-07/msg02400.html Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: SSHD: error initializing windows sockets if I use ".ssh/authorized_keys"
Tino Lange wrote: Hi! If maybe someone looks at this problem in the next time - I'm on holiday for 3 1/2 weeks. So don't wonder if I don't reply... So I'm not impolite - just not there :-) Have a nice time! Cheers Tino -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ls problem
Carlo, Do you have any anti-virus software running? 'ls -l' has to open each file, and this typically triggers your AV software to scan it. Depending on your AV product, and how you have configured it, this might explain unusual delays. If you do have AV software running, try repeating the tests with it disabled, and report back. Thanks, David -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Redhat "at" daemon initial port
I have an initial port to Cygwin of the Redhat 8.0 "at" daemon. I do not have time at the moment to completely clean it up and get it in packageable form. However, if anyone would like to step forward and take this over, I can send you what I have. Joe Buehler -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: emacs 100% cpu usage bu
Hans Larsen wrote: I found in /bin an emacs, and an emacs.exe. I removed both, downloaded the binaries from: http://68.98.180.124:3000/cygwin/emacs/ and all problems disappeared. Let's make sure I understand. You grabbed the modified emacs binaries I put up, and your problems disappeared. Did you download any new Cygwin dll's also? It has been looking like the problem is in the Cygwin dll, not in emacs, so I don't want to release that new emacs package unless I have to, lest something else break. Joe Buehler -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Please try latest snapshot
On Thursday 21 November 2002 10:47 pm, you wrote: > I'm regenerating a snapshot right now which may become 1.3.16. > Please try it. Please try the later of a 2002-11-21 or 2002-11-22 > snapshot. > The problems earlier reported with TinyFugue persist in the 11/21 snapshot. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Make-Problem Postgres on Cygwin
Manuel, Please post instead of sending private email. However, your timing is impeccable. I just got around (yesterday) to building PostgreSQL under the latest Cygwin gcc2 and gcc packages. On Fri, Nov 22, 2002 at 01:23:48PM +0100, Tarabas wrote: > I read your thread abut problems installing Postgresql on Cygwin as > source-distribution. I got exactly the same problems with that! > > Before you ask: > I HAVE TO use the source-build because I need to patch the maximum arguments > for a function on postgresql for my application, so installing binary is not > an option! > > I first got the Problem that the IPC-lib was not found in the configure > which was solved by configuring with > > $ LDFLAGS=-L/usr/local/lib ./configure > instead of the simple "./configure" ... > > Also the IPC-Daemon is installed an running! (ps -aef|grep ipc show's it!) > > Now i get an error when calling the make: > > <-snip-> > make[4]: Entering directory '/postgresql-7.2.3/src/backend/storage/ipc' > gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include >-I/usr/local/include -DBUILDING_DLL=1 -c -o -ipc.o ipc.c > cc1: warning: changing search order for system directory "/usr/local/include" > cc1: warning: as it has already been specified as a non-system-directory The "-I/usr/local/include" is causing configure to get confused and mis-configure PostgreSQL which causes the following (and other) problems: > ipc.c: In function 'InternalIpcSemaphoreCreate': > ipc.c:271: warning: implicit declaration of function `semget' > ipc.c:271: `IPC_CREAT' undeclared (first use in this function) > ipc.c:271: (Each undeclared identifier is reported only once > ipc.c:271: for each function it appears in.) > <-snip-> > > any ideas how to fix that ?! Yes. To build PostgreSQL 7.2.3 under gcc2, use the following procedure: 1. apply attached postgresql-7.2.3-gcc2.patch $ patch -p1 http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 diff -rup postgresql-7.2.3.orig/src/makefiles/Makefile.win postgresql-7.2.3-gcc2/src/makefiles/Makefile.win --- postgresql-7.2.3.orig/src/makefiles/Makefile.win2001-09-05 22:58:33.0 -0400 +++ postgresql-7.2.3-gcc2/src/makefiles/Makefile.win2002-11-21 12:43:07.0 +-0500 @@ -2,7 +2,7 @@ LDFLAGS+= -g DLLTOOL= dlltool DLLWRAP= dllwrap -DLLLIBS= -lcygipc -lcrypt +DLLLIBS= -L/usr/local/lib -lcygipc -lcrypt BE_DLLLIBS= -L$(top_builddir)/src/backend -lpostgres MK_NO_LORDER=true MAKE_DLL=true diff -rup postgresql-7.2.3.orig/src/makefiles/Makefile.win postgresql-7.2.3-gcc3/src/makefiles/Makefile.win --- postgresql-7.2.3.orig/src/makefiles/Makefile.win2001-09-05 22:58:33.0 -0400 +++ postgresql-7.2.3-gcc3/src/makefiles/Makefile.win2002-11-21 10:52:41.0 +-0500 @@ -2,7 +2,7 @@ LDFLAGS+= -g DLLTOOL= dlltool DLLWRAP= dllwrap -DLLLIBS= -lcygipc -lcrypt +DLLLIBS= -L/usr/local/lib -lcygipc -lcrypt BE_DLLLIBS= -L$(top_builddir)/src/backend -lpostgres MK_NO_LORDER=true MAKE_DLL=true diff -rup postgresql-7.2.3.orig/src/template/win postgresql-7.2.3-gcc3/src/template/win --- postgresql-7.2.3.orig/src/template/win 2000-10-21 18:36:14.0 -0400 +++ postgresql-7.2.3-gcc3/src/template/win 2002-11-21 10:31:22.0 -0500 @@ -1,4 +1,3 @@ CFLAGS=-O2 -SRCH_INC=/usr/local/include SRCH_LIB=/usr/local/lib LIBS=-lcygipc -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
rxvt resizing hang fixed by 11/21 cygwin1.dll snapshot
Like an earlier poster, I had noted some hang conditions when a window in which rxvt was running when resized. This morning I downloaded the 11/21 snapshot of the cygwin1.dll, and the problem appears to have gone away. Note that they changing out of the cygwin1.dll file was the only change that I made. Thank you Chris and all others who kept reciting the mantra "Try the latest snapshot". Wayne Keen -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
high load with rsync
Hello, i have installed the latest cygwin release on a win2000 workstation. On that workstation i have enabled the rsync daemon. Now i want copy files from another host (unix with the same release of rsync) to that workstation. Copying of the first file works but after that the cpu load is 100% and i couldn't connect to the workstation anymore. Thats no special hardware in that machine and there are not much processes running because its a test machine. Are there any hints why rsync produces this very high load? Thanks in advance Wolfgang Wolfgang Leideck (Serversupport) ONSYS GmbH Rheinuferstr. 9 --- D-67061 Ludwigshafen Fon: +49 (0)621/60-44103 Fax: +49 (0)621/60-73744 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: high load with rsync
Check the email archives for rsync issues to come up to speed on this one. Don't be afraid to try snapshots either as a general rule for problems you encounter. ;-) Larry Original Message: - From: Leideck, Wolfgang [EMAIL PROTECTED] Date: Fri, 22 Nov 2002 16:20:30 +0100 To: [EMAIL PROTECTED] Subject: high load with rsync Hello, i have installed the latest cygwin release on a win2000 workstation. On that workstation i have enabled the rsync daemon. Now i want copy files from another host (unix with the same release of rsync) to that workstation. Copying of the first file works but after that the cpu load is 100% and i couldn't connect to the workstation anymore. Thats no special hardware in that machine and there are not much processes running because its a test machine. Are there any hints why rsync produces this very high load? Thanks in advance Wolfgang Wolfgang Leideck (Serversupport) ONSYS GmbH Rheinuferstr. 9 --- D-67061 Ludwigshafen Fon: +49 (0)621/60-44103 Fax: +49 (0)621/60-73744 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ mail2web - Check your email from the web at http://mail2web.com/ . -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Make sure to stop all cygrunsrv services before updating cygwin1.dll
This message applies to both updating cygwin1.dll via setup or copying a snapshot. Make sure you end all services started via cygrunsrv before you upgrade. jim drash -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gcc-3.2-3: bootstrap build fails (HAVE_DECL_GETOPT not in config.h?)
On Fri, Nov 22, 2002 at 01:26:01AM -0700, Michael H. Cox wrote: > > >> -Original Message- >> From: Christopher Faylor [mailto:[EMAIL PROTECTED]] >> Sent: Tuesday, November 19, 2002 5:02 PM >> To: [EMAIL PROTECTED] >> Subject: Re: gcc-3.2-3: bootstrap build fails (HAVE_DECL_GETOPT not in >> config.h?) >> >> >> On Wed, Nov 20, 2002 at 10:14:59AM +1100, Nigel Stewart & Fiona >> Smith wrote: >> >Michael, >> > >> >I have encountered the same problem on my setup. >> > >> >Regards, >> >> I have not encountered the same problem in my setup. > >You may have something wrong with your setup, i.e. you may have other >changes besides what's in gcc-3.2-3. Since I'm the person who produces the source code for gcc-3.2-3, you can take it as a given that I don't have other changes. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Any known issues with signal delivery on 2-cpu boxes?
On Fri, Nov 22, 2002 at 07:34:04PM +0900, Anthony Heading wrote: >On Thu, Nov 21, 2002 at 11:47:22PM -0500, Christopher Faylor wrote: >> I'm regenerating a snapshot right now which may become 1.3.16. >> Please try it. > >Might I ask whether there are any fixes or remaining known problems >with signals being lost on multi-processor machines? No. No known issues. I try to fix known issues in signal delivery. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Please try latest snapshot
FWIW (quite a lot to me, actually), my mysterious UW imapd hanging problem went away with this snapshot of cygwin1.dll (1121). D. Knisely -Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 2002 10:54 PM To: [EMAIL PROTECTED] Subject: Re: Please try latest snapshot On Thu, Nov 21, 2002 at 11:47:22PM -0500, Christopher Faylor wrote: >I'm regenerating a snapshot right now which may become 1.3.16. >Please try it. Please try the later of a 2002-11-21 or 2002-11-22 >snapshot. > >FWIW, I was able to duplicate the "emacs hangs if you resize the screen" >problem twice with the previous version of cygwin. I could not >duplicate it at all with this version. > >Thanks, >cgf Forgot my signature. -- Please do not send me personal email with cygwin questions or observations. Use the resources at http://cygwin.com/ . -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Problem building (linking) tck/tk 8.4.1
I have a tcl/tk application (tclcvs) that requires a more recent version of tcl/tk than currently provided with cygwin. However, I cannot get a clean build of tcl 8.4.1 due to some linker errors. So, I appear to be missing some required libraries or they are not on the default search path. If someone could enlighten me on what library I am missing and where I might find it, I would certainly appreciate it. Here are the linker error messages I am receiving: 25:wagner@HABOOB:/usr/local/src/tcl8.4.1/win> make gcc -shared -O -o tcl84.dll -mwin32 -Wl,--out-implib,libtcl84.a regcomp.o regexec.o regfree.o regerror.o tclAlloc.o tclAsync.o [...] Creating library file: libtcl84.a tclWin32Dll.o(.text+0x103):tclWin32Dll.c: undefined reference to __except_checkstackspace_handler' tclWinChan.o(.text+0x8d5):tclWinChan.c: undefined reference to `__except_makefilechannel_handler' tclWinFCmd.o(.text+0x10d):tclWinFCmd.c: undefined reference to `__except_dorenamefile_handler' tclWinFCmd.o(.text+0x6bd):tclWinFCmd.c: undefined reference to `__except_docopyfile_handler' collect2: ld returned 1 exit status make: *** [tcl84.dll] Error 1 22:wagner@HABOOB:/usr/local/src/tcl8.4.1/win> Larry Wagner, Agricultural Engineer | E-mail: [EMAIL PROTECTED] USDA-ARS Wind Erosion Research Unit | phone: (785) 537-5544 1515 College Ave. | fax:(785) 537-5507 Manhattan, KS 66502 | URL:http://www.weru.ksu.edu Cygwin Win95/NT Configuration Diagnostics Current System Time: Fri Nov 22 10:56:12 2002 Windows XP Professional Ver 5.1 Build 2600 Service Pack 1 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\local\sbin c:\Program Files\Tcl\bin c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\Program Files\Common Files\Adaptec Shared\System c:\LF9557\Bin c:\Program Files\nsr\bin SysDir: C:\WINDOWS\System32 WinDir: C:\WINDOWS HOME = `c:\usr\wagner' MAKE_MODE = `unix' PWD = `/usr/local/src/tcl8.4.1/win' USER = `wagner' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\wagner\Application Data' CLIENTNAME = `Console' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMPUTERNAME = `HABOOB' COMSPEC = `C:\WINDOWS\system32\cmd.exe' CVSROOT = `:pserver:[EMAIL PROTECTED]:/weru/cvs' GROUP = `unknown' HOMEDRIVE = `c:' HOMEPATH = `\usr\wagner' HOST = `HABOOB' HOSTTYPE = `i386' INCLUDE = `C:\LF9557\Include' LIB = `C:\LF9557\Lib' LOGNAME = `wagner' LOGONSERVER = `\\HABOOB' MACHTYPE = `i386' MANPATH = `:/usr/ssl/man' NUMBER_OF_PROCESSORS = `1' OS = `Windows_NT' OSTYPE = `posix' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.tcl' PRINTER = `Lexmark_T520_PS3' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 6 Model 8 Stepping 10, GenuineIntel' PROCESSOR_LEVEL = `6' PROCESSOR_REVISION = `080a' PROGRAMFILES = `C:\Program Files' SESSIONNAME = `Console' SHLVL = `1' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINDOWS' TERM = `cygwin' TZ = `CST6CDT5,M4.1.0/2,M10.5.0/2' USERDOMAIN = `HABOOB' USERNAME = `wagner' USERPROFILE = `C:\Documents and Settings\wagner' VENDOR = `intel' WINDIR = `C:\WINDOWS' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = `/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = `C:\cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = `C:\cygwin/bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = `C:\cygwin/lib' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/X11R6/lib/X11/fonts (default) = `C:\cygwin\usr\X11R6\lib\X11\fonts' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options a: fd N/AN/A c: hd NTFS 19077Mb 72% CP CS UN PA FC Haboob d: cd N/AN/A f: cd N/AN/A h: net NTFS 20159Mb 99% CP CSPA. i: net NTFS 19077Mb 72% CP CS UN PA FC Haboob o: net NTFS 20159Mb 99% CP CSPA. p: net NTFS3007Mb 71% CP CSPA. w: net NTFS 20159Mb 99% CP CSPA. C:\cygwin / system binmode C:\cygwin/bin /usr/bin system binmode C:\cygwin/lib /usr/lib system binmode C:\cygwin\usr\X11R6\lib\X11\fonts /u
Re: ls problem
David, The odd thing is that the delay occurred on a file (in a directory) that, according to Carlo, do not exist. Nor do they exist on my system even though I have all of the Cygwin packages installed (including XFree86/Cygwin). Why would a simple attempt to access a non-existent file trigger a nearly two-second delay in an anti-virus subsystem? Does Windows have some kind of "auto-mount" capability for accessing remote file systems? If it did and it were somehow triggered by the attempt to access that directory it could explain the delay? Could there be a Windows mount (not a Cygwin mount) active for that directory that refers to a network drive letter with an invalid server association? (Is that even possible?) Carlo, you could try one of these commands: mountvol 'F:\cygwin\usr\local\etc' /l mountvol 'F:\cygwin\usr\local\etc\zoneinfo' /l mountvol 'F:\cygwin\usr\local\etc\zoneinfo\posixrules' /l to see if Windows has a mountvol association with the directories involved in the problem. Randall Schulz Mountain View, CA USA At 05:08 2002-11-22, David Starks-Browning wrote: Carlo, Do you have any anti-virus software running? 'ls -l' has to open each file, and this typically triggers your AV software to scan it. Depending on your AV product, and how you have configured it, this might explain unusual delays. If you do have AV software running, try repeating the tests with it disabled, and report back. Thanks, David -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Please try latest snapshot
Spoke too soon; latest snapshot is much better with UW imapd and Outlook/IMAP (i.e., doesn't hang 100%), but still hangs every 10 minutes or so. Seems to be a less likely race condition problem or something. >FWIW (quite a lot to me, actually), my mysterious UW imapd hanging problem >went away with this snapshot of cygwin1.dll (1121). >D. Knisely -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: high load with rsync
Leideck, Wolfgang wrote: Hello, i have installed the latest cygwin release on a win2000 workstation. On that workstation i have enabled the rsync daemon. Now i want copy files from another host (unix with the same release of rsync) to that workstation. Copying of the first file works but after that the cpu load is 100% and i couldn't connect to the workstation anymore. Which rsync release? -- Lapo 'Raist' Luchini [EMAIL PROTECTED] (PGP & X.509 keys available) http://www.lapo.it (ICQ UIN: 529796) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
No bell in bash/rxvt in lastest snapshot
WinXPpro, cygcheck attached. Appeared around 20021119, I can try to narrow that down if it's a concern. Does anybody else see this? Nothing changed config-wise on me AFAIK, "set bell-style audible" is in .inputrc. -- Gary R. Van Sickle Braemar Inc. 11481 Rupp Dr. Burnsville, MN 55337 Cygwin Win95/NT Configuration Diagnostics Current System Time: Fri Nov 22 11:37:42 2002 Windows XP Professional Ver 5.1 Build 2600 Service Pack 1 Path: c:\gs\gs7.04\bin c:\gs\gs7.04\lib c:\unix\home\grvs\bin c:\PROGRA~1\DXP100~2\bin c:\unix\usr\local\bin c:\unix\bin c:\WINNT\system32 c:\WINNT c:\WINNT\system32\WBEM c:\Cadence\PSD_14.2\tools\Capture c:\Cadence\PSD_14.2\tools\bin c:\Cadence\PSD_14.2\tools\jre\bin c:\Cadence\PSD_14.2\tools\fet\bin c:\PROGRA~1\MIFD68~1\Bin\ c:\PROGRA~1\MIFD68~1\Bin\WinNT\ c:\PROGRA~1\MIAF9D~1\Common\Tools\WinNT c:\PROGRA~1\MIAF9D~1\Common\MSDev98\Bin c:\PROGRA~1\MIAF9D~1\Common\Tools c:\PROGRA~1\MIAF9D~1\VC98\bin c:\PROGRA~1\MIAF9D~1\VSS\win32 c:\winddk\tools\chkinf SysDir: C:\WINNT\System32 WinDir: C:\WINNT CYGWIN = `ntsec' HOME = `c:\unix\home\grvs' MAKE_MODE = `unix' PWD = `/home/grvs' USER = `Gary_VS' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\gary_vs.BRAEMARINC\Application Data' BASEMAKE = `C:\Program Files\Microsoft SDK\Include\BKOffice.Mak' BKOFFICE = `C:\Program Files\Microsoft SDK\.' CDSROOT = `C:\Cadence\PSD_14.2' CLASSPATH = `C:\Program Files\InterBase Corp\InterClient\interclient.jar' COLORFGBG = `0;default;15' COLORTERM = `rxvt-xpm' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMPUTERNAME = `NOMAD' COMSPEC = `C:\WINNT\system32\cmd.exe' CVS_RSH = `/bin/ssh' DDKPATH = `c:\winddk' DDKROOT = `c:\winddk' DESKTOP = `/cygdrive/c/DOCUME~1/GARY_V~1.BRA/Desktop' DISPLAY = `:0' EDITOR = `nano' GS_FONTPATH = `c:\gs\fonts' GS_LIB = `c:\gs\gs7.04\lib' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\gary_vs.BRAEMARINC' HOSTNAME = `nomad' INCLUDE = `C:\Program Files\Microsoft SDK\Include\.;C:\Program Files\Microsoft Visual Studio\VC98\atl\include;C:\Program Files\Microsoft Visual Studio\VC98\mfc\include;C:\Program Files\Microsoft Visual Studio\VC98\include' INETSDK = `C:\Program Files\Microsoft SDK\.' LIB = `C:\Program Files\Microsoft SDK\Lib\.;C:\Program Files\Microsoft Visual Studio\VC98\mfc\lib;C:\Program Files\Microsoft Visual Studio\VC98\lib' LM_LICENSE_FILE = `C:\Modeltech_xe\win32xoem\license.dat' LOGONSERVER = `\\NTSERV0' MAIL = `/home/grvs/Mail/inbox' MANPATH = `:/usr/ssl/man' MSDEVDIR = `C:\Program Files\Microsoft Visual Studio\Common\MSDev98' MSSDK = `C:\Program Files\Microsoft SDK\.' MSTOOLS = `C:\Program Files\Microsoft SDK\.' MUPAD_PRO_200 = `C:\PROGRA~1\SciFace\MUPADP~1.0' NUMBER_OF_PROCESSORS = `1' OLDPWD = `/home/grvs' OS = `Windows_NT' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 6 Model 8 Stepping 3, GenuineIntel' PROCESSOR_LEVEL = `6' PROCESSOR_REVISION = `0803' PROGRAMFILES = `C:\Program Files' PS1 = `\[\033]0;\w\007 \033[32m\]\u@\h \[\033[33m\w\033[0m\] $ ' SESSIONNAME = `Console' SHLVL = `1' SIWPATH = `c:\wdmbook' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINNT' TEMP = `c:\DOCUME~1\GARY_V~1.BRA\LOCALS~1\Temp' TERM = `rxvt' TMP = `c:\DOCUME~1\GARY_V~1.BRA\LOCALS~1\Temp' USERDNSDOMAIN = `BRAEMARINC.COM' USERDOMAIN = `BRAEMARINC' USERNAME = `Gary_VS' USERPROFILE = `C:\Documents and Settings\gary_vs.BRAEMARINC' WINDIR = `C:\WINNT' WINDOWID = `168055528' WIN_EDITOR = `/cygdrive/c/progra~1/textpa~1/textpad.exe' _ = `/usr/bin/cygcheck.exe' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 (default) = `/cygdrive' cygdrive flags = 0x0020 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start Menu\Programs\Cygnus Solutions (default) = (unsupported type) HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Installed Components HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Installed Components\c:/unix (default) = `2517' bash = `0002.0004.0001' binutils = `2625' bison = `' byacc = `' bzip = `' clear = `0001.' crypt = `0001.' cygwin = `0001.0001.0002' dejagnu = `' diff = `' expect = `' fileutils = `' findutils = `' flex = `' gawk = `0003..0004' gcc = `0002.0095.0002.0002' gdb = `2610' gperf = `' grep = `' groff = `0001.011a.0001' gzip = `' inetutils = `0001.0003.0002.0004' less = `' libpng = `0001..0006.0001' login = `0001.0003' m = `'
Re: patch(1) (Win32) and path separators
Parish <[EMAIL PROTECTED]> wrote around 19 Nov 2002
[EMAIL PROTECTED]:">news:[EMAIL PROTECTED]:
>> Try 'patch -p0 --dry-run < filename'.
>
> That did it. Thanks Igor :-)
>
> I'd always assumed that without -p patch obeyed the path in the diff and
> that -p was only needed if, for example, the path in the diff was
> absolute and you needed a relative one. I didn't read all of the -p
> section in the manpage because it didn't seem to be what I needed, but
> /now/ I've read the last paragraph.
I don't always use a tool like patch frequently enough to remember such
subtleties, myself. This was a helpful exchange because I was struggling
with this just yesterday.
{snippo}
> Thanks again for the help.
Yes, thanks!
> Regards,
>
> Parish (who's going to make 'patch' an alias for 'patch -p0' ;-) )
Me too ;-)
Soren A
--
Yes, it's really Sören, not Soren.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: emacs 100% cpu usage busy
Hi Joe, guess my cygwin .dll is a recent release. I agree that the problem is in the cygwin .dll, because I also experienced some strange $TERM related behaviour of rxvt recently. With regards to emacs, which worked properly until some weeks ago, I definitely fixed the problem by replacing the binary with the binary I downloaded from http://68.98.180.124:3000/cygwin/emacs/ without changing anything else. -Hans -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
The Black Art of DLL Creation (revisited)
Is it a science, or an art? [The following description pertains to the *July 2002* version of dlltool]. I am wanting to know about something relating to building of DLLs on Cygwin using the GNU Binutils tools. Up until this point I've been happy enough just letting recent GCC (ld) versions work their magick with the -shared switch, but my recent experimentation (described below) led me to re-visit the venerable (and deprecated, and despised?) "dlltool". This message is really a long-delayed re-taking-up of questions I had responded to by (mainly) Charles Wilson in the past two or three years. The scenario is that I am trying to re-create the process of building bleadperl (experimental branch Perl [5.9.0] from the ActiveState-hosted [canonical] host location). But it doesn't really matter that it is perl -- it could be anything. That it is Perl is not of the essence. But anyway, I want the building of Perl to be conducted the way *I* think is rational. Taking apart the current build setup, we see that dlltool (through dllwrap) is invoked for building the shared Perl library (the bulk of the guts of perl on Cygwin and Win32 generally, is placed into a DLL; the executable is only ca. 50KB in size and acts as a mere "invoker"). It is well known that the functionality to directly create a DLL from object modules has been part of GCC(ld) for quite a long time now, but one thing that you can get from using dlltool, that you don't (I think?) get from using 'gcc -shared' is a .DEF file that is basically correct. If you ask 'gcc -shared' for a .DEF output using the appropriate switches, you get included stuff like a .bss[data?] that isn't supposed to be exported. Anyway, some opinions would hold that the current way Perl is built on Cygwin is an anachronism and is begging to be updated. Dllwrap takes much longer on my system to create the DLL than invoking 'gcc -shared' does, for one thing. BUT, I would like (for reasons that may not seem important to others) to have a valid (by which I mean 'containing all symbols [functions and global data] that need to be exported [visible to external exes] by the DLL, and none that do not') .DEF file to work with. (OK, one reason is that I am interested in the internals of Perl, and examining the contents of the .DEF file gives a glimpse into those internals). So I ran some experiments. I used a command (in the Makefile) like this, to generate a .DEF file: dlltool --kill-at -z [mylibbasename].def [objfiles1] [objfiles2] [...] And I then invoked (in the next step) GCC like so: gcc -shared [objfiles1] [objfiles2] [...] [mylibbasename].def Observations on what happened: 1. The .DEF output by dlltool isn't acceptable to ld(1). It dumps core. The problem is the first line of the .DEF file generated by dlltool. This first line is commented and is a record of the invocation used to create the .DEF. 2. Only a handful of symbols were listed under EXPORTS. These symbols were all prefixed "XS_[foo]" and it is possible, based on my examination of the source, that these functions were declared in some way that doesn't involve "__declspec(dllexport)". The dozens of other symbols that one expects and needs to see weren't exported. 3. The -k (--kill-at) switch did nothing. Ordinals were still being postpended to each symbol's entry. Fixing (1) and (3) was accomplished by post-processing the .DEF file using sed(1). The resulting .DEF file was acceptable to ld(1) ['gcc -shared'] but there was still the problem of (2) unresolved. I made sure that the Perl macros "EXT" and "cEXT" (constant) etc. were being properly substituted with "__declspec(dllexport)". The header in the cygwin/ subdir of the Perl src tree causes it NOT to be set, -- Gerrit and others who are knowledgeable about CygwinPerl may note this -- but I found a way to override that. Backing up: in theory TTBOMU, if I've thus marked a symbol for export this way, the Cygwin port of GNU ld(1) *should* export it unconditionally. Furthermore, TTBOMU, this SHOULD only be necessary for global variables (data) in the first place -- all *functions* should be exported anyway(?). In cases where the src package has no provisions for this, we've used the "--export-all" switch (for either dlltool OR 'gcc -shared') to cause eveything but the special Cygwin excluded symbols relating to entry points, etc. to be marked for export in the final DLL. This is what the CygwinPerl build setup does at present, and I don't understand why. The mechanism for marking symbols with "__declspec(dll[ex|in]port" is already part of Perl src. Why can't we use it? Clearly *somebody* does or did -- probably MSVC does. So my primary question is now, is it documented behavior for dlltool(1) to ignore "__declspec(dllexport)" when creating a list of symbols for export (which it writes out to a .DEF file)? If not, is it broken now? If so, WHY? BTW, I ran these tests using the *J
/etc/csh.login problems
There is a problem with the /etc/csh.login included in Cygwin package tcsh-6.11.0-4 (current). Embedded spaces in path elements are not preserved when the path is modified. As a UNIX user I naturally try to avoid spaces in pathnames as bad form, but the inherited Windows path is likely to have spaces (e.g. "program files"). This can be corrected by changing the line to: set path=( /usr/local/bin /usr/bin /bin $path:q ) There is another concern with /etc/csh.login which I am unsure about. It does a "set TERM=linux" which perhaps should be a "set TERM=cygwin" instead? This assumes the cygwin terminal type as defined in terminfo/ termcap describes the cmd-window-like interface (does it?). -Andy Grimm -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: pipe performance problem
well i'm a bit lost here. can someone point me in some direction what to do next? where is the relevant code, i figured it must be pipe.cc and tty.cc or is there some other place? also do i have to recompile the binaries when i build a new cygwin1.dll to test the changes? thomas -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: pipe performance problem
On Fri, Nov 22, 2002 at 10:00:59PM +0100, thomas wrote: >well i'm a bit lost here. can someone point me in some direction what >to do next? where is the relevant code, i figured it must be pipe.cc >and tty.cc or is there some other place? If the relevant code was obvious then it would be trivial to fix. I'm not even convinced that there is a cygwin problem here. It doesn't appear to be doing anything wrong. However, unless you are doing something with ttys I don't see why that's appropriate. >also do i have to recompile the binaries when i build a new cygwin1.dll >to test the changes? If you take this to the logical conclusion it would mean that every time we released a new version of the cygwin DLL we'd have to regenerate every cygwin package. So, no, you don't rebuild binaries to test cygwin DLL changes. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: pipe performance problem
Christopher Faylor <[EMAIL PROTECTED]> wrote: > If the relevant code was obvious then it would be trivial to fix. I'm > not even convinced that there is a cygwin problem here. It doesn't > appear to be doing anything wrong. However, unless you are doing something > with ttys I don't see why that's appropriate. from a quick look i found /dev/piper and things like that in tty.cc and since thats what the strace logs are also showing i thought tty.cc is relevant. now please correct me if i'm wrong, but when it works with 1.1.18 and not with 1.3.x and the only constant that changes is cygwin, wouldn't every fan of logic scream out loud then: it's cygwin! :) anyway i'll try to provide more information and will do some additional testing. and i'll write the cdrecord developer about my new findings and see what he thinks about it. thomas -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: The Black Art of DLL Creation (revisited)
Hallo Soren, > Taking apart the current build setup, we see that dlltool (through dllwrap) > is invoked for building the shared Perl library That is not correct. At first a static lib is created: /bin/ar rcu libperl.a perl.o malloc.o gv.o toke.o perly.o op.o pad.o regcomp.o dump.o util.o mg.o reentr.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o perlio.o perlapi.o numeric.o locale.o pp_pack.o pp_sort.o cygwin.o Second, miniperl.exe is linked withthis static lib: gcc -L/sourcecode/perl/perl59 -g -L/usr/local/lib -o miniperl miniperlmain.o opmini.o -lperl -lm -lc -lcrypt -lutil -lbinmode Last, a shared libperl with importlib is created: gcc -shared -o cygperl5_9_0.dll -Wl,--out-implib=libperl.dll.a -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--stack,8388608 \ -g -L/usr/local/lib perl.o malloc.o gv.o toke.o perly.o op.o pad.o regcomp.o dump.o util.o mg.o reentr.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o perlio.o perlapi.o numeric.o locale.o pp_pack.o pp_sort.o cygwin.o -lm -lc -lcrypt -lutil -lbinmode Creating library file: libperl.dll.a No dlltool or dllwrap is involved here. [...dlltool..deffile...problems...snipped...] Take a look in /cygwin/perlld and see: # if some of extensions are undefined, # no corresponding output will be done. # most probably, you'd like to have an export library # my $DEF_EXT = '@DEF_EXT@'; # my $EXP_EXT = '@EXP_EXT@'; my $LIB_EXT = '@LIB_EXT@'; #my $DEBUG ="perlld.out"; my $DEBUG =undef; you may comment/uncomment the according lines to get a .def, .exp, debug output file. This will be passed to gcc as usual which passes it to ld: $command ="$CC -shared -o $dllname"; # $command .=" --verbose" if $verbose; $command .=" -Wl,--output-def=$libname$DEF_EXT" if $DEF_EXT; $command .=" -Wl,--output-exp=$libname$EXP_EXT" if $EXP_EXT; $command .=" -Wl,--out-implib=$libname.dll$LIB_EXT" if $LIB_EXT; $command .=" -Wl,--export-all-symbols" if $EXPORT_ALL; $command .=" -Wl,--enable-auto-import -Wl,--stack,8388608"; # always There should be correct .def and .exp files then. Gerrit -- =^..^= -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: pipe performance problem
On Fri, Nov 22, 2002 at 11:04:15PM +0100, thomas wrote: >Christopher Faylor <[EMAIL PROTECTED]> wrote: >>If the relevant code was obvious then it would be trivial to fix. I'm >>not even convinced that there is a cygwin problem here. It doesn't >>appear to be doing anything wrong. However, unless you are doing >>something with ttys I don't see why that's appropriate. > >from a quick look i found /dev/piper and things like that in tty.cc and >since thats what the strace logs are also showing i thought tty.cc is >relevant. I was trying to help by cutting down on places to look. If you want to investigate tty code, feel free. >now please correct me if i'm wrong, but when it works with 1.1.18 and >not with 1.3.x and the only constant that changes is cygwin, wouldn't >every fan of logic scream out loud then: it's cygwin! :) Logic fan, are you? Did you see anything in the strace log that indicated cygwin was operating improperly? "It's slower" is not necessarily a sign of improper behavior. There are often reasons for decreasing performance, such as "improving compliance". If a program is so finely tuned that it falls over when timings change then it is possible that it is just not going to work. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: pipe performance problem
Thomas, At 14:04 2002-11-22, you wrote: ... now please correct me if i'm wrong, but when it works with 1.1.18 and not with 1.3.x and the only constant that changes is cygwin, wouldn't every fan of logic scream out loud then: it's cygwin! :) Don't bite my head off, Tuvok, but your "logic" is flawed. Unfortunately (?), at the moment I don't really feel like giving another lecture on computing system performance analysis. However, I am mildly interested in this and also have a certain interest in having command-line alternatives to Nero for burning CDs, so I'm willing to at least add a data point by trying to run this software on my system. I don't know what sort of system you're using, but as desktops go, mine's pretty high-performance: 2.4 GHz processor, PC 3100 RAM; dual-channel Ultra-160 SCSI controller with fast disks segregated from slow ones; CD recorder on SCSI. I have two Ultra 160 hard drives and one slow one (I think it runs at 40 MB/sec, but it could be 20). So, where do I get this CD recording software you're using? I don't know if you built it yourself or got a pre-built binary, but I think I'd like to configure and build it myself. Is that an option? anyway i'll try to provide more information and will do some additional testing. and i'll write the cdrecord developer about my new findings and see what he thinks about it. thomas [ See what you can do about that broken shift key, OK? ] Thanks. Randall Schulz Mountain View, CA USA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Cygwin DLL 1.3.14-1 "cygdrive flags" registry entry
Hello. I am trying to prepare a series of cygwin dependant applications for distribution. The available documentation says all that is required is to distribute the cygwin1.dll with the apps. However when I tried this I had corrupted data returned from a read call. After much experimenting I determined that when cygwin is installed there are some registry settings that effect the behavior of the library. I determined that the following registry entry will make my problem 'go away' Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions] [HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin] [HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2] "cygdrive flags"=dword:0022 Can anybody point me to some documentation which explains the "cygdrive flags" entry: What flags are available? What effect they have on application behavior? Can they be set programmatically? etc... Any help would be appreciated. Thanks Randy Holmes [EMAIL PROTECTED] (512) 340-6893 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin DLL 1.3.14-1 "cygdrive flags" registry entry
On Fri, Nov 22, 2002 at 04:51:11PM -0600, Holmes, Randy wrote:
>I am trying to prepare a series of cygwin dependant applications for
>distribution. The available documentation says all that is required is
>to distribute the cygwin1.dll with the apps. However when I tried this
>I had corrupted data returned from a read call.
>
>After much experimenting I determined that when cygwin is installed
>there are some registry settings that effect the behavior of the
>library. I determined that the following registry entry will make my
>problem 'go away'
>
>
> Windows Registry Editor Version 5.00
>
> [HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions]
>
> [HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin]
>
> [HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2]
> "cygdrive flags"=dword:0022
>
>
>
>Can anybody point me to some documentation which explains the "cygdrive
>flags" entry: What flags are available? What effect they have on
>application behavior? Can they be set programmatically? etc...
We do not advertise the contents of the registry. You shouldn't even
be worrying about them. They are subject to change without notice.
If you are getting corrupted data it is undoubtedly a binmode/textmode
issue. You need to modify your program to properly open files in the
correct mode, i.e., if you are opening a file which is binary, use:
FILE *fp = fopen ("foo", "rb");
or
int fd = open ("foo", O_RDONLY | O_BINARY);
Btw, I'm sure you know this, but if you are preparing something for
distribution then your distribution will be open source. That's a
stipulation of the cygwin license. Either that or you need to
purchase a cygwin license from Red Hat.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
-DDATE start giving error with gcc-3.2.3
Hi,
If I compiled following code with -DDATE="Wed Nov 22", it compiled fine
using gcc-2.95, but when I updated my cygwin recently, it gives parse
errors using gcc-3.2.3 (which, I think it should)
#include
#include
typedef double DATE;
main(){
printf ("Hello World!\n");
}
Looks like wtypes.h also has DATE defined. But, it should have given me
error earlier also, as wtypes had this definition earlier also.
Was this a gcc bug that got fixed in gcc-3.2.3? or is there anything else
Thanks,
Nitin
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: pipe performance problem
> Randall R Schulz <[EMAIL PROTECTED]> wrote: > I don't know what sort of system you're using, but as desktops go, mine's > pretty high-performance: 2.4 GHz processor, PC 3100 RAM; dual-channel > Ultra-160 SCSI controller with fast disks segregated from slow ones; CD > recorder on SCSI. I have two Ultra 160 hard drives and one slow one (I > think it runs at 40 MB/sec, but it could be 20). I've got a XP2000+, PC 2100 RAM and a single IDE 7200rpm drive. Writer is Plextor 241040A IDE, they don't make SCSI anymore unfortunately :( Both devices are master on their own channel with no slaves. I'd pretty much rule out a performance problem here. > So, where do I get this CD recording software you're using? I don't know if > you built it yourself or got a pre-built binary, but I think I'd like to > configure and build it myself. Is that an option? I tried binaries and also built myself. You can get binaries and sources at: http://www.geoshock.com/cdrtools/ But the official location for sources is (ignore the alpha): ftp://ftp.fokus.gmd.de/pub/unix/cdrecord/alpha/ Note that the developer recommends to make them with smake under cygwin. You can get smake sources from here: ftp://ftp.fokus.gmd.de/pub/unix/smake/alpha/smake-1.2a18.tar.gz > [ See what you can do about that broken shift key, OK? ] Sorry :) thomas -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
ld not configured right???
greeting: I try to write a boot loader in cygwin. this code worked in linux. but I try to assembled and linked it in cygwin, it assembled ok. first question is what kind of file format that as generated?? then, I tried link it into plain binary format, I got following error: ld: PE operations on non PE file. as -o boot.o boot.S ld -Ttext 0x0 -s --oformat binary -e _start -o boot.bin boot.o ld: PE operations on non PE file. make: *** [boot.bin] Error 1 Is it posibble that I can get work around this problem? thanks Bizhong Hu __ Do you Yahoo!? Yahoo! Mail Plus Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: -DDATE start giving error with gcc-3.2.3
What's gcc 3.2.3? Do you mean gcc 3.2.1? That's the latest gcc.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
Of Nitin Gupta
Sent: Friday, November 22, 2002 5:23 PM
To: [EMAIL PROTECTED]
Subject: -DDATE start giving error with gcc-3.2.3
Hi,
If I compiled following code with -DDATE="Wed Nov 22", it compiled fine
using gcc-2.95, but when I updated my cygwin recently, it gives parse
errors using gcc-3.2.3 (which, I think it should)
#include
#include
typedef double DATE;
main(){
printf ("Hello World!\n");
}
Looks like wtypes.h also has DATE defined. But, it should have given me
error earlier also, as wtypes had this definition earlier also.
Was this a gcc bug that got fixed in gcc-3.2.3? or is there anything else
Thanks,
Nitin
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
DOS shortname and cygwin I/O
Hello, I just noticed that cygwin seems to get confused when we do a cd to dos-short-pathname. It is easy to reproduce: a) Install cygwin to c:/Programme/cygwin b) make sure you mount / in binary mode c) mkdir c:/Programme/cygwin/tst c) cd c:/Programme/cygwin/tst d) echo "XXX" > file1 e) od -c file1 # this should show file1 with '\n' line termination f) cd c:/Progra~2/cygwin/tst# C:/Progra~2 is the shortname of c:/Programme g) echo "XXX" > file2 h) od -c file2 # this should show file2 with a \r\n line termination I would expect the "echo" command to behave the same way, regardless of how I cd there. Is there a reason for doing otherwise ? Thanks Andrew Chang -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: -DDATE start giving error with gcc-3.2.3
I'll be very surprised if your program compiles under any C compiler on
Earth.
-Vijay
> -Original Message-
> From: Nitin Gupta [mailto:[EMAIL PROTECTED]]
> Sent: Friday, November 22, 2002 3:23 PM
> To: [EMAIL PROTECTED]
> Subject: -DDATE start giving error with gcc-3.2.3
>
>
> Hi,
>
> If I compiled following code with -DDATE="Wed Nov 22", it
> compiled fine
> using gcc-2.95, but when I updated my cygwin recently, it gives parse
> errors using gcc-3.2.3 (which, I think it should)
>
> #include
> #include
> typedef double DATE;
> main(){
>
> printf ("Hello World!\n");
> }
>
> Looks like wtypes.h also has DATE defined. But, it should
> have given me
> error earlier also, as wtypes had this definition earlier also.
>
> Was this a gcc bug that got fixed in gcc-3.2.3? or is there
> anything else
>
> Thanks,
> Nitin
>
>
>
> --
> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting: http://cygwin.com/bugs.html
> Documentation: http://cygwin.com/docs.html
> FAQ: http://cygwin.com/faq/
>
>
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: -DDATE start giving error with gcc-3.2.3
This is the gcc which came with latest cygwin
gcc version 3.2 20020927 (prerelease)
Sorry not 3.2.3 but 3.2-3
Robert McNulty Junior wrote:
What's gcc 3.2.3? Do you mean gcc 3.2.1? That's the latest gcc.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
Of Nitin Gupta
Sent: Friday, November 22, 2002 5:23 PM
To: [EMAIL PROTECTED]
Subject: -DDATE start giving error with gcc-3.2.3
Hi,
If I compiled following code with -DDATE="Wed Nov 22", it compiled fine
using gcc-2.95, but when I updated my cygwin recently, it gives parse
errors using gcc-3.2.3 (which, I think it should)
#include
#include
typedef double DATE;
main(){
printf ("Hello World!\n");
}
Looks like wtypes.h also has DATE defined. But, it should have given me
error earlier also, as wtypes had this definition earlier also.
Was this a gcc bug that got fixed in gcc-3.2.3? or is there anything else
Thanks,
Nitin
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: DOS shortname and cygwin I/O
On Fri, 22 Nov 2002, Andrew Chang wrote: > Hello, > > I just noticed that cygwin seems to get confused when we do a > cd to dos-short-pathname. It is easy to reproduce: > > a) Install cygwin to c:/Programme/cygwin > b) make sure you mount / in binary mode > c) mkdir c:/Programme/cygwin/tst > c) cd c:/Programme/cygwin/tst > d) echo "XXX" > file1 > e) od -c file1 # this should show file1 with '\n' line termination > f) cd c:/Progra~2/cygwin/tst# C:/Progra~2 is the shortname of c:/Programme > g) echo "XXX" > file2 > h) od -c file2 # this should show file2 with a \r\n line termination > > I would expect the "echo" command to behave the same way, regardless of how > I cd there. Is there a reason for doing otherwise ? > > Thanks > Andrew Chang I don't know if it's a bug, but I believe I can explain what's happening: When a file is opened in Cygwin, and the mode (binary or text) is not specified, the mount table is consulted, and the first matching entry determines the type of mount (binary or text), and thus the mode. If the directory is not found in the mount table, it is assumed to be mounted through /cygdrive. What's happening in your case is that Cygwin doesn't match c:/Progra~2 with the c:/Programme in the mount table, and thus assumes that it is a text mount (because /cygdrive is text). The fact that you end up in the same directory is really irrelevant (that's Windows' doing). Cygwin isn't aware of DOS short names being equivalent to Windows long names. So, to answer your question, echo *does* behave the same way - it only outputs a newline. Writing the file to disk, however, *does not* behave the same way, and depends on the type of mount, which, in turn, depends on which entry in the mount table the directory matches. Hope this helps, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Water molecules expand as they grow warmer" (C) Popular Science, Oct'02, p.51 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: DOS shortname and cygwin I/O
On Friday 22 November 2002 04:10 pm, Igor Pechtchanski wrote: > On Fri, 22 Nov 2002, Andrew Chang wrote: > > Hello, > > > > I just noticed that cygwin seems to get confused when we do a > > cd to dos-short-pathname. It is easy to reproduce: > > > > a) Install cygwin to c:/Programme/cygwin > > b) make sure you mount / in binary mode > > c) mkdir c:/Programme/cygwin/tst > > c) cd c:/Programme/cygwin/tst > > d) echo "XXX" > file1 > > e) od -c file1 # this should show file1 with '\n' line termination > > f) cd c:/Progra~2/cygwin/tst# C:/Progra~2 is the shortname of > > c:/Programme g) echo "XXX" > file2 > > h) od -c file2 # this should show file2 with a \r\n line termination > > > > I would expect the "echo" command to behave the same way, regardless of > > how I cd there. Is there a reason for doing otherwise ? > > > > Thanks > > Andrew Chang > > I don't know if it's a bug, but I believe I can explain what's happening: > > When a file is opened in Cygwin, and the mode (binary or text) is not > specified, the mount table is consulted, and the first matching entry > determines the type of mount (binary or text), and thus the mode. > If the directory is not found in the mount table, it is assumed to be > mounted through /cygdrive. > > What's happening in your case is that Cygwin doesn't match c:/Progra~2 > with the c:/Programme in the mount table, and thus assumes that it is a > text mount (because /cygdrive is text). The fact that you end up in the > same directory is really irrelevant (that's Windows' doing). Cygwin isn't > aware of DOS short names being equivalent to Windows long names. Thanks for your response, Right, that is my guess too. I am thinking that the mount table could store both the long name and the short name. This should gives cygwin enough infomation to do the "right thing". > > So, to answer your question, echo *does* behave the same way - it only > outputs a newline. Writing the file to disk, however, *does not* behave > the same way, and depends on the type of mount, which, in turn, depends on > which entry in the mount table the directory matches. > > Hope this helps, > Igor -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: -DDATE start giving error with gcc-3.2.3
Yeah, I will change the code. My idea was that some one will see the
difference in preprocessed file using
gcc -E -dD foo.c -DDATE="Wed Nov"
Vijay Sampath wrote:
This isn't the original program you posted to the list.
-Original Message-
From: Nitin Gupta [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 22, 2002 4:13 PM
To: Vijay Sampath
Cc: [EMAIL PROTECTED]
Subject: Re: -DDATE start giving error with gcc-3.2.3
Try on latest cygwin.
gcc-2.exe foo.c -DDATE="Wed Nov"
(gcc-2 is gcc 2.95)
and
gcc.exe foo.c -DDATE="Wed Nov"
(gcc is gcc 3.2)
where foo.c is
#include
#include
main(){
printf ("Hello World!\n");
}
Vijay Sampath wrote:
I'll be very surprised if your program compiles under any C compiler on
Earth.
-Vijay
-Original Message-
From: Nitin Gupta [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 22, 2002 3:23 PM
To: [EMAIL PROTECTED]
Subject: -DDATE start giving error with gcc-3.2.3
Hi,
If I compiled following code with -DDATE="Wed Nov 22", it
compiled fine
using gcc-2.95, but when I updated my cygwin recently, it gives parse
errors using gcc-3.2.3 (which, I think it should)
#include
#include
typedef double DATE;
main(){
printf ("Hello World!\n");
}
Looks like wtypes.h also has DATE defined. But, it should
have given me
error earlier also, as wtypes had this definition earlier also.
Was this a gcc bug that got fixed in gcc-3.2.3? or is there
anything else
Thanks,
Nitin
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: -DDATE start giving error with gcc-3.2.3
Nitin Gupta <[EMAIL PROTECTED]> wrote:
>> If I compiled following code with -DDATE="Wed Nov 22", it compiled
>> fine using gcc-2.95, but when I updated my cygwin recently, it gives
>> parse errors using gcc-3.2.3 (which, I think it should)
>>
>> #include
>> #include
>> typedef double DATE;
>> main(){
>>
>> printf ("Hello World!\n");
>> }
>>
>> Looks like wtypes.h also has DATE defined. But, it should have given
>> me error earlier also, as wtypes had this definition earlier also.
For me, it does.
Max.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: -DDATE start giving error with gcc-3.2.3
OK. I see.
-Original Message-
From: Nitin Gupta [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 22, 2002 6:09 PM
To: Robert McNulty Junior
Cc: [EMAIL PROTECTED]
Subject: Re: -DDATE start giving error with gcc-3.2.3
This is the gcc which came with latest cygwin
gcc version 3.2 20020927 (prerelease)
Sorry not 3.2.3 but 3.2-3
Robert McNulty Junior wrote:
>What's gcc 3.2.3? Do you mean gcc 3.2.1? That's the latest gcc.
>
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
>Of Nitin Gupta
>Sent: Friday, November 22, 2002 5:23 PM
>To: [EMAIL PROTECTED]
>Subject: -DDATE start giving error with gcc-3.2.3
>
>
>Hi,
>
>If I compiled following code with -DDATE="Wed Nov 22", it compiled fine
>using gcc-2.95, but when I updated my cygwin recently, it gives parse
>errors using gcc-3.2.3 (which, I think it should)
>
>#include
>#include
>typedef double DATE;
>main(){
>
>printf ("Hello World!\n");
>}
>
>Looks like wtypes.h also has DATE defined. But, it should have given me
>error earlier also, as wtypes had this definition earlier also.
>
>Was this a gcc bug that got fixed in gcc-3.2.3? or is there anything else
>
>Thanks,
>Nitin
>
>
>
>--
>Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
>Bug reporting: http://cygwin.com/bugs.html
>Documentation: http://cygwin.com/docs.html
>FAQ: http://cygwin.com/faq/
>
>
>
>
>
>
>
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
impure_ptr/Mingw and Cygwin
I wish to use -mno-cygwin to produce an executable that can work without
Cygwin installed. I have successfully done this before. Now I'm adding
some functionality to my program and it is no longer working! I've
worked it out such that it will compile and link but when my program
runs it simply stops returning an exit code of 5. Running this under gdb
produces a SIGSIGV Segmentation fault then you attempt to run it.
I've whittled it down to the bare minimum to reproduce the problem.
Seems to me the problem is somewhere between newer versions of gcc 3.X
and Mingw.
File: foo.c:
#include
int main (void) {
printf ("Hello World\n");
fprintf (stderr, "%s\n", "Hello World 2");
}
$ gcc -g foo.c -mno-cygwin -I/usr/include -o foo -liberty -lcrtdll -lg
$ foo
$
Note that if I do not put -lg then I get:
/tmp/ccKAyr4S.o(.text+0x4b): In function `main':
/dview/defaria_2.0/salira/neopon/build/maketools/foo.c:4: undefined
reference to `_impure_ptr'
Any ideas?
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: impure_ptr/Mingw and cygwin
On Fri, Nov 22, 2002 at 05:08:33PM -0800, Andrew DeFaria wrote:
>I wish to use -mno-cygwin to produce an executable that can work without
>Cygwin installed. I have successfully done this before. Now I'm adding
>some functionality to my program and it is no longer working! I've
>worked it out such that it will compile and link but when my program
>runs it simply stops returning an exit code of 5. Running this under gdb
>produces a SIGSIGV Segmentation fault then you attempt to run it.
>
>I've whittled it down to the bare minimum to reproduce the problem.
>Seems to me the problem is somewhere between newer versions of gcc 3.X
>and Mingw.
>
>File: foo.c:
>
>#include
>int main (void) {
> printf ("Hello World\n");
> fprintf (stderr, "%s\n", "Hello World 2");
>}
>
>$ gcc -g foo.c -mno-cygwin -I/usr/include -o foo -liberty -lcrtdll -lg
>$ foo
>$
>
>Note that if I do not put -lg then I get:
>
>/tmp/ccKAyr4S.o(.text+0x4b): In function `main':
>/dview/defaria_2.0/salira/neopon/build/maketools/foo.c:4: undefined
>reference to `_impure_ptr'
>
>Any ideas?
Undoubtedly neither -liberty nor -lg are compiled using -mno-cygwin.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: impure_ptr/Mingw and cygwin
On Fri, Nov 22, 2002 at 08:34:27PM -0500, Christopher Faylor wrote: >Undoubtedly neither -liberty nor -lg are compiled using -mno-cygwin. Sorry. That should read "one of or both of -liberty or -lg". cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: impure_ptr/Mingw and Cygwin
On Fri, 22 Nov 2002, Andrew DeFaria wrote:
> I wish to use -mno-cygwin to produce an executable that can work without
> Cygwin installed. I have successfully done this before. Now I'm adding
> some functionality to my program and it is no longer working! I've
> worked it out such that it will compile and link but when my program
> runs it simply stops returning an exit code of 5. Running this under gdb
> produces a SIGSIGV Segmentation fault then you attempt to run it.
>
> I've whittled it down to the bare minimum to reproduce the problem.
> Seems to me the problem is somewhere between newer versions of gcc 3.X
> and Mingw.
>
> File: foo.c:
>
> #include
> int main (void) {
> printf ("Hello World\n");
> fprintf (stderr, "%s\n", "Hello World 2");
> }
>
> $ gcc -g foo.c -mno-cygwin -I/usr/include -o foo -liberty -lcrtdll -lg
> $ foo
> $
>
> Note that if I do not put -lg then I get:
>
> /tmp/ccKAyr4S.o(.text+0x4b): In function `main':
> /dview/defaria_2.0/salira/neopon/build/maketools/foo.c:4: undefined
> reference to `_impure_ptr'
>
> Any ideas?
Well, for one thing, linking with -lg will pull in cygwin.dll since
/lib/libg.a is a symlink to libcygwin.a. So your program won't be
Cygwin-free, if that's your goal. However, I got it to work with the
following command:
$ gcc -g foo.c -mno-cygwin -mwindows -o foo -liberty -lmingw32
$ ./foo.exe > x
$ cat x
Hello World
If you change 'stderr' to 'stdout' you get "Hello World 2" in the output
too. You'll have to play with carriage control a bit, but basically it
works. Windows doesn't really have the concept of a stderr file handle,
so this behaviour makes sense to me. I ran the resulting executable
through Visual C++'s DUMPBIN program and verified foo.exe only imports
msvcrt.dll and kernel32.dll, so it's Cygwin-free.
--
Peter A. Castro <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]>
"Cats are just autistic Dogs" -- Dr. Tony Attwood
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
lsearch / search.h
In the actual cygwin GCC (gcc-3.2-3) I did not find the header search.h containing lsearch. I am not sure whether function lsearch is part of ANSI C, but it is available under Linux GCC and MS VC. Did I make something wrong with the installation? Can I find it on some other place? Thank, you Helmut -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
openafs on cygwin
Has anyone configured and compiled an openafs client for cygwin? -Leland H. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
USER environment variable mystery
Hi All, I've recently spent some time configuring cygwin, and it's mostly gone as expected. I say mostly because I've noticed a strange behavior with the USER environment variable, and possibly others. I've set this in both ~/.bashrc and in /etc/profile to be the user name that our UNIX machines expect (the surname). The windows 2000 machine I'm using thinks that the USER is "firstname lastname". Now after setting these variables in ~/.bashrc, echo shows that they have been properly set, however both my bash prompt and applications such as ssh and xemacs continue to use "firstname lastname" (xemacs get's this from "(getenv USER)", making me suspect some strangeness in the getenv function). Does anyone know how to *really* change the environment variables? Is this set somewhere deeper in the cygwin structure? I've also tried setting this from the cygwin.bat file, but with no success. I'm using a recent version of cygwin, downloaded via setup.exe about a week or so ago. TIA, - Steve Nunez -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
dos2unix/d2u does nothing
Cygwin DLL version info: DLL version: 1.3.15 DLL epoch: 19 Hello, I'm finding that dos2unix and d2u doesn't change a file in-place, even with -U (the timestamp doesn't even change). It works find for stdin-to-stdout, though. Just thought I'd share my feelings on that (that is, I feel it doesn't work in-place, but thank goodness it works). Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: No bell in bash/rxvt in lastest snapshot
> WinXPpro, cygcheck attached. Appeared around 20021119, I can try to narrow > that down if it's a concern. Does anybody else see this? Nothing changed > config-wise on me AFAIK, "set bell-style audible" is in .inputrc. Hmmm, works fine on XPhome. Nevermind, something must be SNAFU at work. -- Gary R. Van Sickle Brewer. Patriot. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: dos2unix/d2u does nothing
Fred, It works OK for me. You may be experiencing an interaction with a text mode mount (though from the looks of it, "conv.c" was ported for cygwin to open files in binary mode, so this shouldn't happen). As to the mod time, perhaps you wrote the file and then converted it within the same minute, so "ls -l" doesn't show a change in the modification time (even though the difference is there at the finer time resolution that the OS and / or file system uses to record file modification times). By the way, dos2unix and d2u are identical (byte-for-byte). The other thing I can think of is that you're not running the dos2unix from the "cygutils" package, that the version you're running was not ported to Cygwin to be immune to the mount type and (conceivably) that it resets the file's modification time after reformatting it. Randall Schulz Mountain View, CA USA At 20:36 2002-11-22, Shing-Fat Fred Ma wrote: Hello, I'm finding that dos2unix and d2u doesn't change a file in-place, even with -U (the timestamp doesn't even change). It works find for stdin-to-stdout, though. Just thought I'd share my feelings on that (that is, I feel it doesn't work in-place, but thank goodness it works). Fred -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
