Re: cygpath 1.7 wrong
On Jun 9 16:24, Corinna Vinschen wrote: On Jun 3 22:18, Reini Urban wrote: $ mkdir -p t/lib $ cygpath -aw t/lib C:\cygwin-1.7\usr\src\perl\perl-5.10.0\builddebug\t\lib $ cygpath -w t/lib \ib Ouch. I'll look into it in the next couple of days. I've uploaded 1.7.0-17 which contains a fix for that. Please give it a try. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA] subversion-1.4.6-1
On Jun 12 13:05, David Rothenberger wrote: On 5/23/2008 10:23 AM, David Rothenberger wrote: I'd appreciate at least one GTG on this, since the packaging is complicated, at least for me. Ping? So far I've got one GTG from Reini even though he still has problem building with libtool 2. Volker also had troubles building, but did not have libdb4.2-devel installed and hasn't reported back regarding whether the package builds with it installed or not. I've uploaded subversion. Thanks for taking over maintainership. I just saw that subversion depends on apr1/aprutil1 which are also orphaned packages. Would you be interested to take over maintainership for them as well? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: cygpath 1.7 wrong
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Reini Urban on 6/13/2008 7:03 AM: | 1.5 returns in user resp. system /cygdrive, | but 1.7 returns /cygdrive/ | This is annoying. But is it wrong? On the other hand, what happens if the user has / as their cygdrive; does this print //? | 2) multibyte chars in pathnames are not printed with /bin/ls. | bash or coreutils? Probably coreutils, and probably because isprint() is returning false. In 1.5.x, I hacked coreutils to print non-ASCII characters in spite of isprint() returning false, but I think that hack disappeared in my porting to 1.7.0. At any rate, I think that isprint() should be fixed here rather than hacking coreutils - if the console can display something reasonable for characters = 0x80, then isprint() should claim they are printable. But some of this also depends on deciding sane semantics for unibyte vs. multibyte character locale settings. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhScn0ACgkQ84KuGfSFAYCYaQCgpmEs74b7Q5wBVDtdPIyxuQAn 428AoIdyL8mTew5Gvoi5kZW8h1xtA2FA =FIqi -END PGP SIGNATURE-
Re: cygpath 1.7 wrong
On Jun 13 07:13, Eric Blake wrote: According to Reini Urban on 6/13/2008 7:03 AM: | 1.5 returns in user resp. system /cygdrive, | but 1.7 returns /cygdrive/ | This is annoying. But is it wrong? On the other hand, what happens if the user has / as their cygdrive; does this print //? I'll look into that. | 2) multibyte chars in pathnames are not printed with /bin/ls. | bash or coreutils? At any rate, I think that isprint() should be fixed here rather than hacking coreutils - if the console can display something reasonable for characters = 0x80, then isprint() should claim they are printable. But some of this also depends on deciding sane semantics for unibyte vs. multibyte character locale settings. Indeed! However, right now ls will print the correct filename regardless of the codepage used. Right now, because I still hope that Kadzuhiro will come up with the NLS-related changes discussed on cygwin-developers which obsoletes the CYGWIN=codepage setting in favor of LC_CTYPE et al. 1.7$ export CYGWIN=codepage:ansi 1.7$ ls -b \304\353\344 1.7$ ls --show-control-chars Äëä 1.7$ export CYGWIN=codepage:utf8 1.7$ ls -b \303\204\303\253\303\244 1.7$ ls --show-control-chars Äëä Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: cygpath 1.7 wrong
On Jun 13 15:03, Reini Urban wrote: 1.5$ perl -e'print Cygwin::mount_flags(/cygdrive)' binmode,cygdrive,/cygdrive 1.7$ perl -e'print Cygwin::mount_flags(/cygdrive)' binmode,cygdrive,/cygdrive/ Doesn't work for me: 1.7$ perl -e'print Cygwin::mount_flags(/cygdrive)' Undefined subroutine Cygwin::mount_flags called at -e line 1. How does a standalone example look like? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: cygpath 1.7 wrong
On Fri, Jun 13, 2008 at 04:30:51PM +0200, Corinna Vinschen wrote: On Jun 13 15:03, Reini Urban wrote: 1.5$ perl -e'print Cygwin::mount_flags(/cygdrive)' binmode,cygdrive,/cygdrive 1.7$ perl -e'print Cygwin::mount_flags(/cygdrive)' binmode,cygdrive,/cygdrive/ Doesn't work for me: 1.7$ perl -e'print Cygwin::mount_flags(/cygdrive)' Undefined subroutine Cygwin::mount_flags called at -e line 1. How does a standalone example look like? Don't you need a -MCygwin on the perl command line? cgf
Re: cygpath 1.7 wrong
On Jun 13 10:41, Christopher Faylor wrote: On Fri, Jun 13, 2008 at 04:30:51PM +0200, Corinna Vinschen wrote: On Jun 13 15:03, Reini Urban wrote: 1.5$ perl -e'print Cygwin::mount_flags(/cygdrive)' binmode,cygdrive,/cygdrive 1.7$ perl -e'print Cygwin::mount_flags(/cygdrive)' binmode,cygdrive,/cygdrive/ Doesn't work for me: 1.7$ perl -e'print Cygwin::mount_flags(/cygdrive)' Undefined subroutine Cygwin::mount_flags called at -e line 1. How does a standalone example look like? Don't you need a -MCygwin on the perl command line? Doesn't work for me either: Can't locate Cygwin.pm in @INC (@INC contains: /usr/lib/perl5/5.8/cygwin /usr/lib/perl5/5.8 /usr/lib/perl5/site_perl/5.8/cygwin /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_perl/5.8/cygwin /usr/lib/perl5/vendor_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 .). I noticed that Cygwin.pm is in /usr/lib/perl5/5.8/File/Spec. I added this path to the environment variable PERL5LIB, but it didn't help either: Undefined subroutine Cygwin::mount_flags called at -e line 1. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: cygpath 1.7 wrong
Corinna Vinschen schrieb:
On Jun 13 15:03, Reini Urban wrote:
1.5$ perl -e'print Cygwin::mount_flags(/cygdrive)'
binmode,cygdrive,/cygdrive
1.7$ perl -e'print Cygwin::mount_flags(/cygdrive)'
binmode,cygdrive,/cygdrive/
Doesn't work for me:
1.7$ perl -e'print Cygwin::mount_flags(/cygdrive)'
Undefined subroutine Cygwin::mount_flags called at -e line 1.
How does a standalone example look like?
Sorry, this perl is perl5.10.0-4 from [Exp].
Also I recompiled it for cygwin-1.7 with the wchar support. (returning
utf8 converted from wchar)
perl5.8.8 doesn't has this function yet.
Something like:
#include stdlib.h
#include stdio.h
#include sys/cygwin.h
char *Cygwin_mount_flags(char *pathname) {
char flags[260]; /* I know, I know. stack vs heap */
/* TODO: Check for cygdrive registry setting,
* and then use CW_GET_CYGDRIVE_INFO
*/
if (!strcmp(pathname, /cygdrive)) {
char user[260];
char system[260];
char user_flags[260];
char system_flags[260];
cygwin_internal (CW_GET_CYGDRIVE_INFO, user, system, user_flags,
system_flags);
if (strlen(user) 0) {
sprintf(flags, %s,cygdrive,%s, user_flags, user);
} else {
sprintf(flags, %s,cygdrive,%s, system_flags, system);
}
return flags;
} else {
struct mntent *mnt;
setmntent (0, 0);
while ((mnt = getmntent (0))) {
if (!strcmp(pathname, mnt-mnt_dir)) {
strcpy(flags, mnt-mnt_type);
if (strlen(mnt-mnt_opts) 0) {
strcat(flags, ,);
strcat(flags, mnt-mnt_opts);
}
break;
}
}
endmntent (0);
return flags;
}
}
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
Re: cygpath 1.7 wrong
Christopher Faylor schrieb: On Fri, Jun 13, 2008 at 04:30:51PM +0200, Corinna Vinschen wrote: On Jun 13 15:03, Reini Urban wrote: 1.5$ perl -e'print Cygwin::mount_flags(/cygdrive)' binmode,cygdrive,/cygdrive 1.7$ perl -e'print Cygwin::mount_flags(/cygdrive)' binmode,cygdrive,/cygdrive/ Doesn't work for me: 1.7$ perl -e'print Cygwin::mount_flags(/cygdrive)' Undefined subroutine Cygwin::mount_flags called at -e line 1. How does a standalone example look like? Don't you need a -MCygwin on the perl command line? No. cygwin perl has all Cygwin functions always in core. It's no module (yet). For more advanced Cygwin functions like access to cygwin_internal() I thought of an CPAN module sooner or later. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: cygpath 1.7 wrong
On Jun 13 17:01, Reini Urban wrote:
Corinna Vinschen schrieb:
On Jun 13 15:03, Reini Urban wrote:
1.5$ perl -e'print Cygwin::mount_flags(/cygdrive)'
binmode,cygdrive,/cygdrive
1.7$ perl -e'print Cygwin::mount_flags(/cygdrive)'
binmode,cygdrive,/cygdrive/
Doesn't work for me:
1.7$ perl -e'print Cygwin::mount_flags(/cygdrive)'
Undefined subroutine Cygwin::mount_flags called at -e line 1.
How does a standalone example look like?
Sorry, this perl is perl5.10.0-4 from [Exp].
Also I recompiled it for cygwin-1.7 with the wchar support. (returning utf8
converted from wchar)
perl5.8.8 doesn't has this function yet.
Something like:
Thanks. Is that the function implemented in Perl? If so, I'd have
two comments:
#include stdlib.h
#include stdio.h
#include sys/cygwin.h
char *Cygwin_mount_flags(char *pathname) {
char flags[260]; /* I know, I know. stack vs heap */
/* TODO: Check for cygdrive registry setting,
* and then use CW_GET_CYGDRIVE_INFO
*/
Drop that TODO. Never test the registry, not even in 1.5, even less
in 1.7.
if (!strcmp(pathname, /cygdrive)) {
char user[260];
char system[260];
char user_flags[260];
char system_flags[260];
The paths in user and system are potentially PATH_MAX bytes long.
That's 4K in 1.7.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: cygpath 1.7 wrong
On Jun 13 17:14, Corinna Vinschen wrote:
char *Cygwin_mount_flags(char *pathname) {
char flags[260]; /* I know, I know. stack vs heap */
[...]
return flags;
And it's returning the content of a local buffer. Ouch!
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: cygpath 1.7 wrong
On Jun 13 16:18, Corinna Vinschen wrote: On Jun 13 07:13, Eric Blake wrote: According to Reini Urban on 6/13/2008 7:03 AM: | 1.5 returns in user resp. system /cygdrive, | but 1.7 returns /cygdrive/ | This is annoying. But is it wrong? On the other hand, what happens if the user has / as their cygdrive; does this print //? I'll look into that. I've applied a fix. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] libgcrypt-1.4.1-1
Gergely Budai writes: Dear Volker! You should really be subscribed to the main cygwin list where bug reports usually go. I thought that cygwin-apps is the primary list for discussing packaging issues, but thank you for the hint, I will do so. Then again here with a solution and a new .cygport file which splits the package in main, devel and runtime packages: http://cygwin.com/ml/cygwin/2008-05/msg00180.html Thank you so much for that brilliant preparation of all the necessary files! I prepared the packages here again: http://home.arcor.de/thuffir/cygwin/libgcrypt/ I hope they will fullfill your expectations, and that they are bug-free this time. Cheers, Gergely Budai PS: Please do your GTG once again before I do my RFU this time ;) Builds fine from source and setup.hints look good. But is the follwing file really needed ? /usr/lib/libgcrypt.def Otherwise GTG. Ciao Volker
Re: cygpath 1.7 wrong
2008/6/13 Corinna Vinschen:
On Jun 13 17:14, Corinna Vinschen wrote:
char *Cygwin_mount_flags(char *pathname) {
char flags[260]; /* I know, I know. stack vs heap */
[...]
return flags;
And it's returning the content of a local buffer. Ouch!
It was just an example. The real perl function is correct of course.
char user[260];
char system[260];
char user_flags[260];
char system_flags[260];
The paths in user and system are potentially PATH_MAX bytes long.
That's 4K in 1.7.
Thank for the PATH_MAX hint. I almost forgot that.
/* TODO: Check for cygdrive registry setting,
* and then use CW_GET_CYGDRIVE_INFO
*/
Drop that TODO. Never test the registry, not even in 1.5, even less
in 1.7.
To explain:
For now I had the semantic limitation that the magic
Cygwin::mount_flags(/cygdrive)
is required to return the volume mount settings.
But when a user mounted it to somewhere else, say /mnt, then
the result for Cygwin::mount_flags(/mnt) might not be what he/she
expected. So the TODO is to check if /mnt is the current volume
mount point, and return the volume mount point flags then.
Changed to
/* TODO: Check if arg is the current volume moint point if not default,
* and then use CW_GET_CYGDRIVE_INFO also.
*/
The next perl-5.10 version (this time for cygwin 1.7) will have
this TODO actually implemented.
From README.cygwin:
=item CCygwin::mount_flags
Returns the mount type and flags for a specified mount point.
A comma-separated string of mntent-mnt_type (always
system or user), then the mntent-mnt_opts, where
the first is always binmode or textmode.
system|user,binmode|textmode,exec,cygexec,cygdrive,mixed,
notexec,managed,nosuid,devfs,proc,noumount
If the argument is /cygdrive or equal to the current cygdrive mount
prefix, then just the volume mount settings, and the cygdrive mount
prefix are returned.
User mounts override system mounts.
$ perl -e 'print Cygwin::mount_flags /usr/bin'
system,binmode,cygexec
$ perl -e 'print Cygwin::mount_flags /cygdrive'
binmode,cygdrive,/cygdrive
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
Re: [ITA] subversion-1.4.6-1
On 6/13/2008 1:40 AM, Corinna Vinschen wrote: On Jun 12 13:05, David Rothenberger wrote: On 5/23/2008 10:23 AM, David Rothenberger wrote: I'd appreciate at least one GTG on this, since the packaging is complicated, at least for me. Ping? So far I've got one GTG from Reini even though he still has problem building with libtool 2. Volker also had troubles building, but did not have libdb4.2-devel installed and hasn't reported back regarding whether the package builds with it installed or not. I've uploaded subversion. Thanks. I just saw that subversion depends on apr1/aprutil1 which are also orphaned packages. Would you be interested to take over maintainership for them as well? Maybe. I'll have a look at it once I get the upcoming Subversion 1.5.0 release packaged. -- David Rothenberger [EMAIL PROTECTED] My only love sprung from my only hate! Too early seen unknown, and known too late! -- William Shakespeare, Romeo and Juliet
src/winsup/cygwin ChangeLog mount.cc
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2008-06-13 15:22:59 Modified files: winsup/cygwin : ChangeLog mount.cc Log message: * mount.cc (mount_info::get_cygdrive_info): Fix usage of user and system arguments. Strip trailing slash from path for backward compatibility. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4191r2=1.4192 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/mount.cc.diff?cvsroot=srcr1=1.12r2=1.13
cl.exe cannot understand gygwin path format
-- View this message in context: http://www.nabble.com/cl.exe-cannot-understand-gygwin-path-format-tp17815738p17815738.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
cl.exe cannot understand gygwin path format
Hi, I am trying to compile a .c file using cl.exe in cygwin. I am getting following Error. $ cl -Fo/cygdrive/e/cnair/tmp/hai.o /cygdrive/e/cnair/tmp/hai.c Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.00.9466 for 80x86 Copyright (C) Microsoft Corporation 1984-2001. All rights reserved. cl : Command line warning D4002 : ignoring unknown option '/cygdrive/e/cnair/tmp /hai.c' cl : Command line error D2003 : missing source filename If I change the .c file path format to normal windows format then it is working fine. Is there any option/way to compile files using cl.exe with the same cygwin path format? Thanks and regarsd, CN -- View this message in context: http://www.nabble.com/cl.exe-cannot-understand-gygwin-path-format-tp17815775p17815775.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bug in ping? ICMP Sequence Number octets are reversed
Hello, I just had a (short) session with Wireshark: * On Thu, Jun 12, 2008 at 10:39:09PM -0700 Gary Johnson wrote: I've been using Cygwin's ping (/usr/bin/ping, ping-1.0-1) to do some testing of IP over a wireless modem. [...] It looks like someone just wrote a short integer to the sequence number field without calling htons() to perform the possible little-endian to big-endian conversion. I can confirm this for both cygwin ping and for Windows (XP SP2) ping. I would compare it to ping on other systems, but I don't have a convenient way to sniff those packets. Well, Debian/Linux (Etch, v4.0) does it in network byte order, as one (might) expect. Differently to the Windows and Cygwin ping, it starts the sequence number with 1, not with 0. Should it be changed? I don't know, I never had a problem with it, but others might. Regards, Spiro. -- Spiro R. Trikaliotis http://opencbm.sf.net/ http://www.trikaliotis.net/ http://www.viceteam.org/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: XP + cygwin version 1.7: problem with /proc/net/if_inet6 format and if_indextoname
On Jun 10 12:41, Corinna Vinschen wrote: On Jun 9 20:27, Deti Fliegl wrote: Maybe there should be some scope tests (by IN6_IS_ADDR_* macros) in winsup/cygwin/fhandler_procnet.cc to provide a consistent value. I see. Well, I put this on my TODO list. It shouldn't be too tricky to generate the same values as on Linux here. But see below... FYI, I just uploaded 1.7.0-17 to the release-2 area. It's supposed to print scope and flag values as on Linux. I also changed if_indextoname and friends to prefer the IPv6 device index over the v4 index if both exist. That should fix the different index numbers between if_indextoname and /proc/net/if_inet6. Please give it a try. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Ugrent !! Reg. Executing the EXE generated by Cygwin
Hi, We have built an exe in cygwin which calls a .bat file which inturn invokes another cygwin generate exe. When we run exe in Windows 2003 Server, we get the following error. 69750 [main] ? (5536) C:\cygwin\bin\sh.exe: *** fatal error - cygheap base mis match detected - 0x9F88E0/0x611688E0. This problem is probably due to using incompatible versions of the cygwin DLL. Search for cygwin1.dll using the Windows Start-Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. Rebooting is also suggested if you are unable to find another cygwin DLL. We have made sure that we use the same version of cygwin1.dll while building the exe and while running it on the server. What are the possible reasons for this? Are there any other solutions to this? Regards Mani -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Ugrent !! Reg. Executing the EXE generated by Cygwin
Mani kandan writes: This problem is probably due to using incompatible versions of the cygwin DLL. Search for cygwin1.dll using the Windows Start-Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. Rebooting is also suggested if you are unable to find another cygwin DLL. We have made sure that we use the same version of cygwin1.dll while building the exe and while running it on the server. What are the possible reasons for this? Are there any other solutions to this? The most likely reason and the solution for it were already provided to you by Cygwin itself. See above. Have you read and performed those instructions? ..mark -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Ugrent !! Reg. Executing the EXE generated by Cygwin
This problem is probably due to using incompatible versions of the cygwin DLL. Search for cygwin1.dll using the Windows Start-Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. Rebooting is also suggested if you are unable to find another cygwin DLL. We have made sure that we use the same version of cygwin1.dll while building the exe and while running it on the server. What are the possible reasons for this? Are there any other solutions to this? The most likely reason and the solution for it were already provided to you by Cygwin itself. See above. Have you read and performed those instructions? === Yes, we have read and performed those instruction. We have placed the cygwin1.dll in current working folder which is inside the c:\cygwin\bin folder while generating the exe. We have checked the size of the dll also. Both are same size . Then wt are the possible reasons for this problem?? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[PATCH] Bug in /usr/bin/cron-config (needs quotation marks)
A couple of places in /usr/bin/cron-config (cron version 4.1-6) are missing quotation marks around variables in tests, resulting in errors when the username contains spaces. Example errors: Do you want to install the cron daemon as a service? (yes/no) no Running cron_diagnose ... /usr/bin/cron-config: line 456: [: /var/cron/tabs/Will: binary operator expected /usr/bin/cron-config: line 459: [: /var/cron/tabs/Will: binary operator expected /usr/bin/cron-config: line 371: [: /var/cron/tabs/Will: binary operator expected ls: cannot access /var/cron/tabs/Will Palmer: No such file or directory cron table files need to writable only by the owner, readable by the owner and he group, and executable by no one. The permissions of your cron table file are set to: ls: cannot access /var/cron/tabs/Will: No such file or directory ls: cannot access Palmer: No such file or directory -- Will Palmer [EMAIL PROTECTED] (+44) 01303 245 210 cron-config.p Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cl.exe cannot understand gygwin path format
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 CN wrote: | Hi, | | I am trying to compile a .c file using cl.exe in cygwin. | I am getting following Error. | | $ cl -Fo/cygdrive/e/cnair/tmp/hai.o /cygdrive/e/cnair/tmp/hai.c | Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.00.9466 for 80x86 | Copyright (C) Microsoft Corporation 1984-2001. All rights reserved. | | cl : Command line warning D4002 : ignoring unknown option | '/cygdrive/e/cnair/tmp | /hai.c' | cl : Command line error D2003 : missing source filename | | If I change the .c file path format to normal windows format then it is | working fine. | | Is there any option/way to compile files using cl.exe with the same cygwin | path format? No, it is not. CL is native Windows executable and thus does not handle Cygwin paths. At best you could use the cygpath utility to convert the paths. | | Thanks and regarsd, | CN | | -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkhSU/0ACgkQjksRtmO2spdtZQCfdOSdQZjjbtPDX7A5YIyHD8mB HtcAnR9DSOpWD9gE6N2YavLu0xktSCvL =i++9 -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin + Fetchmail + Ssmtp in Exchange
Rod, Please see the following: http://cygwin.com/acronyms/#PPIOSPE On Thu, Jun 12, 2008 at 11:09:03PM +1000, Rod Lopez wrote: I was reading Cygwin mail archives when I came across a few of your posts and you seem to know what you are talking about, so I thought you might be able to point me in the right direction. I normally use Cygwin with Fetchmail on Windows Servers to fetch ISP hosted emails and pass them on to the Exchange server. This is because the Intelli Mail Filter (IMF) does not filters spam on port 110 (using the Exchange POP Connector) only on port 25 (SMTP Connector). So I run Cygwin on the same box that host Exchange and use it as a POP3 to SMTP converter. Then I setup a sheduled task on Windows to invoke fetchmail every 15 minutes, so fetchmail is not even running as a service or invoked by cron - very quick and basic setup, and it works very well. What I would like to do is install Clam AV and SpamAssassin in Cygwin, and add another level of filtering. What is the best way of doing this? I was thinking something like this: Fetchmail = Procmail (invoking ClamAV + SpamAssassin) = ssmtp = Exchange Is this possible, Yes, I believe that this is possible. and what would be the best way of accomplishing this? I would really appreciate your help with this one, as I am not quite sure on how to proceed. It sounds like you just need to invoke ClamAV and SpamAssassin from procmail as filters. However, as the above URL indicates, posting will get you access to more expertise than sending private email. Maybe someone from the Cygwin list can help? Otherwise, I would try other lists like procmail, fetchmail, etc. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bug in ping? ICMP Sequence Number octets are reversed
On Fri, Jun 13, 2008 at 09:24:27AM +0200, Spiro Trikaliotis wrote: Hello, I just had a (short) session with Wireshark: * On Thu, Jun 12, 2008 at 10:39:09PM -0700 Gary Johnson wrote: I've been using Cygwin's ping (/usr/bin/ping, ping-1.0-1) to do some testing of IP over a wireless modem. [...] It looks like someone just wrote a short integer to the sequence number field without calling htons() to perform the possible little-endian to big-endian conversion. I can confirm this for both cygwin ping and for Windows (XP SP2) ping. I would compare it to ping on other systems, but I don't have a convenient way to sniff those packets. Well, Debian/Linux (Etch, v4.0) does it in network byte order, as one (might) expect. Differently to the Windows and Cygwin ping, it starts the sequence number with 1, not with 0. Should it be changed? I don't know, I never had a problem with it, but others might. ping does not have a maintainer currently so, unless someone wants to take over maintainership, it is not likely to be changed and bug reports against ping are not likely to be acted upon. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bug in ping? ICMP Sequence Number octets are reversed
On Jun 13 10:07, Christopher Faylor wrote: ping does not have a maintainer currently so, unless someone wants to take over maintainership, it is not likely to be changed and bug reports against ping are not likely to be acted upon. I'm wondering if we need it at all. It doesn't exactly have more functionality than Window's on-board ping, plus, it uses RAW sockets. Raw socket I/O is restricted to administrative users since Windows XP. So Cygwin's ping can't work for non-admin users on XP and later. I'd rather drop it entirely from the distro. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bug in ping? ICMP Sequence Number octets are reversed
On Fri, Jun 13, 2008 at 04:36:03PM +0200, Corinna Vinschen wrote: On Jun 13 10:07, Christopher Faylor wrote: ping does not have a maintainer currently so, unless someone wants to take over maintainership, it is not likely to be changed and bug reports against ping are not likely to be acted upon. I'm wondering if we need it at all. It doesn't exactly have more functionality than Window's on-board ping, plus, it uses RAW sockets. Raw socket I/O is restricted to administrative users since Windows XP. So Cygwin's ping can't work for non-admin users on XP and later. I'd rather drop it entirely from the distro. The only mildly nice thing about it is that it works sort of like the UNIX version of ping. However, I think it's possible to get equivalent behavior from Windows ping if you give it the right command line parameters. So, maybe a shell wrapper is all that's needed. I'll look into that. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bug in ping? ICMP Sequence Number octets are reversed
If you ditch the Cygwin Ping I hope the Windows version can work better than the Windows version of Finger. If I execute finger from Cygwin I get a loop where the help text is executed about 3 times and no finger results are given. It took a distressingly long time before I realized there isn't a Cygwin finger and it's actually executing the Windows version which it can't do properly. Cygwin does have pinky but it never works for me. Is pinky supposed to need a special server? Our site works for (Windows) finger but not Cygwin pinky and I don't know whose fault that is. -- Lee Maschmeyer Computing Center Services Computing and Information Technology Wayne State University Detroit, Michigan, USA - Original Message - From: Christopher Faylor [EMAIL PROTECTED] To: cygwin@cygwin.com Sent: Friday, June 13, 2008 10:53 Subject: Re: Bug in ping? ICMP Sequence Number octets are reversed On Fri, Jun 13, 2008 at 04:36:03PM +0200, Corinna Vinschen wrote: On Jun 13 10:07, Christopher Faylor wrote: ping does not have a maintainer currently so, unless someone wants to take over maintainership, it is not likely to be changed and bug reports against ping are not likely to be acted upon. I'm wondering if we need it at all. It doesn't exactly have more functionality than Window's on-board ping, plus, it uses RAW sockets. Raw socket I/O is restricted to administrative users since Windows XP. So Cygwin's ping can't work for non-admin users on XP and later. I'd rather drop it entirely from the distro. The only mildly nice thing about it is that it works sort of like the UNIX version of ping. However, I think it's possible to get equivalent behavior from Windows ping if you give it the right command line parameters. So, maybe a shell wrapper is all that's needed. I'll look into that. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cl.exe cannot understand gygwin path format
CN wrote: This list strongly encourages content to be in the body of the message, not the subject. Why would you expect non-Cygwin programs to understand POSIX paths? Did you read What Isn't Cygwin? on www.cygwin.com? -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bug in ping? ICMP Sequence Number octets are reversed
On Jun 13 11:14, Lee Maschmeyer wrote: Cygwin does have pinky but it never works for me. Is pinky supposed to need a special server? Our site works for (Windows) finger but not Cygwin pinky and I don't know whose fault that is. Pinky access the utmp file which is only created for login's through ssh, telnet, rsh, etc. There's no utmp entry for local console shells. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygpath 1.7 wrong
2008/6/13 Corinna Vinschen:
On Jun 13 17:14, Corinna Vinschen wrote:
char *Cygwin_mount_flags(char *pathname) {
char flags[260]; /* I know, I know. stack vs heap */
[...]
return flags;
And it's returning the content of a local buffer. Ouch!
It was just an example. The real perl function is correct of course.
char user[260];
char system[260];
char user_flags[260];
char system_flags[260];
The paths in user and system are potentially PATH_MAX bytes long.
That's 4K in 1.7.
Thank for the PATH_MAX hint. I almost forgot that.
/* TODO: Check for cygdrive registry setting,
* and then use CW_GET_CYGDRIVE_INFO
*/
Drop that TODO. Never test the registry, not even in 1.5, even less
in 1.7.
To explain:
For now I had the semantic limitation that the magic
Cygwin::mount_flags(/cygdrive)
is required to return the volume mount settings.
But when a user mounted it to somewhere else, say /mnt, then
the result for Cygwin::mount_flags(/mnt) might not be what he/she
expected. So the TODO is to check if /mnt is the current volume
mount point, and return the volume mount point flags then.
Changed to
/* TODO: Check if arg is the current volume moint point if not default,
* and then use CW_GET_CYGDRIVE_INFO also.
*/
The next perl-5.10 version (this time for cygwin 1.7) will have
this TODO actually implemented.
From README.cygwin:
=item CCygwin::mount_flags
Returns the mount type and flags for a specified mount point.
A comma-separated string of mntent-mnt_type (always
system or user), then the mntent-mnt_opts, where
the first is always binmode or textmode.
system|user,binmode|textmode,exec,cygexec,cygdrive,mixed,
notexec,managed,nosuid,devfs,proc,noumount
If the argument is /cygdrive or equal to the current cygdrive mount
prefix, then just the volume mount settings, and the cygdrive mount
prefix are returned.
User mounts override system mounts.
$ perl -e 'print Cygwin::mount_flags /usr/bin'
system,binmode,cygexec
$ perl -e 'print Cygwin::mount_flags /cygdrive'
binmode,cygdrive,/cygdrive
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Bug in ping? ICMP Sequence Number octets are reversed
On 2008-06-13, Christopher Faylor wrote: On Fri, Jun 13, 2008 at 04:36:03PM +0200, Corinna Vinschen wrote: On Jun 13 10:07, Christopher Faylor wrote: ping does not have a maintainer currently so, unless someone wants to take over maintainership, it is not likely to be changed and bug reports against ping are not likely to be acted upon. I'm wondering if we need it at all. It doesn't exactly have more functionality than Window's on-board ping, plus, it uses RAW sockets. Raw socket I/O is restricted to administrative users since Windows XP. So Cygwin's ping can't work for non-admin users on XP and later. I'd rather drop it entirely from the distro. The only mildly nice thing about it is that it works sort of like the UNIX version of ping. Exactly. However, I think it's possible to get equivalent behavior from Windows ping if you give it the right command line parameters. The feature of Cygwin's (Unix's) ping that I found particularly useful in my testing was the printing of the sequence numbers. I couldn't find a way to make the Windows version do that. Regards, Gary -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Recommended cygwin-1.7 check
How should one check for the new cygwin 1.7 API, esp. wchar pathnames? So far I've used #include cygwin/version.h #if (CYGWIN_VERSION_USER_API_VERSION_COMBINED = 181) because I needed cygwin_conv_path() But I assume #if CYGWIN_VERSION_DLL_MAJOR = 1007 should be used instead. Or shouldn't some default definition in sys/cygwin.h be used instead? Otherwise one has to add #include cygwin/version.h everywhere. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Passing file descriptors and ssh ControlMaster
After looking through the list archives, I am a little puzzled as to the current state of implementing the necessary functionality that will enable the file descriptor passing between processes (which according to my understanding is required for a functioning ControlMaster behavior of ssh). Are there any plans / updates on this? Thank you in advance, --Stefanos. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bug in ping? ICMP Sequence Number octets are reversed
On 2008-06-13, Corinna Vinschen wrote: On Jun 13 10:07, Christopher Faylor wrote: ping does not have a maintainer currently so, unless someone wants to take over maintainership, it is not likely to be changed and bug reports against ping are not likely to be acted upon. I'm wondering if we need it at all. It doesn't exactly have more functionality than Window's on-board ping, plus, it uses RAW sockets. Raw socket I/O is restricted to administrative users since Windows XP. So Cygwin's ping can't work for non-admin users on XP and later. I'd rather drop it entirely from the distro. I can get admin privileges to do my work. It is more difficult to find proper tools. Cygwin has made is really easy for me to do things that would be difficult or impossible in Windows. I would be strongly in favor of keeping ping and other Cygwin tools with similar permission problems as part of the distribution. Regards, Gary -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: {subversion,subversion-apache2,subversion-devel,subversion-perl,subversion-python,subversion-ruby}-1.4.6-1
A new version the subversion is now available for download. NEWS: = This is a new upstream release. Please see http://svn.collab.net/repos/svn/branches/1.4.x/CHANGES for the changes in this release. This release also includes a patch proposed to upstream to help with transient permission denied errors encountered when other programs have the Subversion temporary files open. See http://sourceware.org/ml/cygwin/2006-09/msg00081.html for a report of such a problem. DESCRIPTION: Subversion is a version control system designed to be a compelling successor to CVS. Please see http://svnbook.red-bean.com/en/1.4/index.html for more details about using SVN. DOWNLOAD: = Note that downloads from sources.redhat.com (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: = To unsubscribe to the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- David Rothenberger [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Ugrent !! Reg. Executing the EXE generated by Cygwin
Mani kandan writes: This problem is probably due to using incompatible versions of the cygwin DLL. Search for cygwin1.dll using the Windows Start-Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. Rebooting is also suggested if you are unable to find another cygwin DLL. We have made sure that we use the same version of cygwin1.dll while building the exe and while running it on the server. What are the possible reasons for this? Are there any other solutions to this? [...] Yes, we have read and performed those instruction. We have placed the cygwin1.dll in current working folder which is inside the c:\cygwin\bin folder while generating the exe. We have checked the size of the dll also. Both are same size . Then wt are the possible reasons for this problem?? I must be missing some critical detail in your description. Are you talking about two different machines, building an EXE on one and then running it on another? What do you mean by placing cygwin1.dll in the current working folder? There can be only one cygwin1.dll on the machine, put where it's supposed to be by using the Cygwin setup.exe. You can't just put another copy of cygwin1.dll somewhere else on that machine. ..mark -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Ugrent !! Reg. Executing the EXE generated by Cygwin
There can be only one cygwin1.dll on the machine, put where it's supposed to be by using the Cygwin setup.exe. You can't just put another copy of cygwin1.dll somewhere else on that machine. Yes, you can. http://msdn.microsoft.com/en-us/library/ms682586.aspx Dynamic-Link library search order A system can contain multiple versions of the same dynamic-link library (DLL). That said .. wasn't there something recently on this list about not being able to find cygwin1.dll using the windows search? Probably either attrib or dir from a command prompt would find it - eg: C:\attrib cygwin1.dll /s C:\Cygwin\bin\cygwin1.dll C:\Cygwin\source\tcptrace\cygwin-libs\win9x\cygwin1.dll C:\Cygwin\source\tcptrace\cygwin-libs\winNT\cygwin1.dll C:\Cygwin\source\tcptrace\cygwin-libs\cygwin1.dll C:\MyProgs\John\run\cygwin1.dll C:\MyProgs\TCPtrace\cygwin1.dll C:\MyProgs\win_xplot\bin\win9x\cygwin1.dll C:\MyProgs\win_xplot\bin\winNT\cygwin1.dll C:\UTIL\cygwin1.dll C:\ Regards, Lee -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Ugrent !! Reg. Executing the EXE generated by Cygwin
Lee wrote: There can be only one cygwin1.dll on the machine, put where it's supposed to be by using the Cygwin setup.exe. You can't just put another copy of cygwin1.dll somewhere else on that machine. Yes, you can. http://msdn.microsoft.com/en-us/library/ms682586.aspx Dynamic-Link library search order A system can contain multiple versions of the same dynamic-link library (DLL). ...if you know what you're doing. If you don't, keep only the one that 'setup.exe' installs and keep it where it installed it. Doing anything else assumes that you know what you're doing and that you don't have to query this list when something goes wrong. That's why we recommend to folks that inquire to keep one copy only. Any other configuration is unsupported by this list due to the complexities it introduces. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Ugrent !! Reg. Executing the EXE generated by Cygwin
On Fri, Jun 13, 2008 at 07:40:25PM +, Lee wrote: There can be only one cygwin1.dll on the machine, put where it's supposed to be by using the Cygwin setup.exe. You can't just put another copy of cygwin1.dll somewhere else on that machine. Yes, you can. http://msdn.microsoft.com/en-us/library/ms682586.aspx Dynamic-Link library search order A system can contain multiple versions of the same dynamic-link library (DLL). Wow! That said .. wasn't there something recently on this list about not being able to find cygwin1.dll using the windows search? Probably either attrib or dir from a command prompt would find it - eg: C:\attrib cygwin1.dll /s C:\Cygwin\bin\cygwin1.dll C:\Cygwin\source\tcptrace\cygwin-libs\win9x\cygwin1.dll C:\Cygwin\source\tcptrace\cygwin-libs\winNT\cygwin1.dll C:\Cygwin\source\tcptrace\cygwin-libs\cygwin1.dll C:\MyProgs\John\run\cygwin1.dll C:\MyProgs\TCPtrace\cygwin1.dll C:\MyProgs\win_xplot\bin\win9x\cygwin1.dll C:\MyProgs\win_xplot\bin\winNT\cygwin1.dll C:\UTIL\cygwin1.dll The fact that you *can* do this doesn't mean that it is a good practice to do this. In fact, the error message that started out this thread clearly showed that there are problems. We tend to offer unequivocal advice to confused end users who don't exactly know what they are doing since it is bad practice to advise them to play with multiple versions of cygwin. Most of the time they have a copy on their system that they don't know about and are better off deleting it. Trying to instruct someone in the rules involved in dll searches is not really a fruitful endeavor in the long run. So, what I'm saying is that go ahead and pat yourself on the back for figuring out how to use multiple versions of cygwin. It is still a bad idea and should not be encouraged for the normal user. -- Christopher Faylor spammer? - [EMAIL PROTECTED] Cygwin Co-Project Leader -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Ugrent !! Reg. Executing the EXE generated by Cygwin
On Fri, June 13, 2008 2:23 am, Mani kandan wrote: This problem is probably due to using incompatible versions of the cygwin DLL. Search for cygwin1.dll using the Windows Start-Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. Rebooting is also suggested if you are unable to find another cygwin DLL. We have made sure that we use the same version of cygwin1.dll while building the exe and while running it on the server. What are the possible reasons for this? Are there any other solutions to this? The most likely reason and the solution for it were already provided to you by Cygwin itself. See above. Have you read and performed those instructions? === Yes, we have read and performed those instruction. We have placed the cygwin1.dll in current working folder which is inside the c:\cygwin\bin folder while generating the exe. We have checked the size of the dll also. Both are same size . Then wt are the possible reasons for this problem?? You have misunderstood the problem. It has nothing to do with incompatibilities between the dll used to build an exe and to run it. The problem is having multiple versions of the dll running on the same machine at the same time. Please re-read cygwin's advice with this in mind. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
