Re: Update: perl-Win32-GUI, perl-libwin32
Reini Urban schrieb: The two setup.hints are attached. Oops. This is the correct one for perl-libwin32. Win32CORE is in perl core now. Sorry. Win32::GUI was removed. @ perl-libwin32 sdesc: Perl extensions for using the Win32 API category: System Libs requires: perl cygwin ldesc: Perl extensions for using the Win32 API. Included modules: Win32API::File, Win32API::Net, Win32API::Registry, ChangeNotify, Clipboard, Console, Event, EventLog, File, FileSecurity, IPC, Internet, Job, Mutex, NetAdmin, NetResource, ODBC, OLE, PerfLib, Pipe, Process, Registry, Semaphore, Service, Shortcut, Sound, TieRegistry and WinError.
Re: Linking with additional libraries...
Hey again... Can't find XWINW32 anywhere, or winprocargs's EnumDisplayMonitors, using version 6.7.1 src so that might be why. I added -lmsimg32 to XWINSYSLIBS in Xserver/Imakefile and then 'make Makefile make Makefiles' and when I 'make XWin.exe' I can see that it links with -lmsimg32 but it still complains about undefined references.. Any ideas //Sebastian
Re: XWindows Errors running ddd under Cygwin
On Tue, 8 Feb 2005, Matthew Johnson wrote: Warning: Name ItemsList Class: XmList Parent refused resize request. Second XtMakeGeometryRequest() failed. ... And: Warning: XtRemoveGrab asked to remove a widget not on the list. So the most fundamental question is: do any of these warnings indicate that my installation of X is incomplete? I could NOT find packages listed by Cygwin's setup.exe to correspond to all the X features/packages listed by ddd --config. But it does behave much better after dowloading and installing LessTiff. No. These are messages which seem to be caused by using lesstif instead of motif and can be switched off somewhere in the ddd configuration. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: Linking with additional libraries...
On Wed, 9 Feb 2005, Sebastian Haby wrote: Hey again... Can't find XWINW32 anywhere, or winprocargs's EnumDisplayMonitors, using version 6.7.1 src so that might be why. EnumDisplayMonitors was introduced somewhere after version 6.8.1. Older versions included dynamic resolving of TrackMouseEvent and DirectDrawCreate. Search for GetProcAddress in hw/xwin I added -lmsimg32 to XWINSYSLIBS in Xserver/Imakefile and then 'make Makefile make Makefiles' and when I 'make XWin.exe' I can see that it links with -lmsimg32 but it still complains about undefined references.. Any ideas strange. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
problem with xterm
Hi, First, I've been running cygwin for a couple years on my XP machine with no problems.I have startxwin.bat startup with windows. Then a couple weeks ago, my xterm window stops opening (though X is still starting fine). I can open xterm from the command line fine. So I start looking into the startxwin.bat file. By editing the run xterm command I can get it to open up an xtermit turns out that one of the switches is causing a problem...-sb. So I keep the same default run xterm command, as long as I take out the sb switch. If I put that switch in, then the xterm window won't ever appear. Again let me say that one day after a couple years it just stopped working. I made no changes that I remember but obviously something must have changed. I tried reinstalling cygwin with no luck. Any suggestions? Much appreciated, matt
Re: XWindows Errors running ddd under Cygwin
--- Alexander Gottwald [EMAIL PROTECTED] wrote: On Tue, 8 Feb 2005, Matthew Johnson wrote: [snip] So the most fundamental question is: do any of these warnings indicate that my installation of X is incomplete? No. These are messages which seem to be caused by using lesstif instead of motif and can be switched off somewhere in the ddd configuration. I guess you are referring to Edit:Preferences:General:Suppress X Warnings. Now that you have reassured me of the insignificance of the warnings, I will do that. Thanks! = --- Matthew Johnson [EMAIL PROTECTED] __ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo
Re: Is it somehow possible to start Windows applications from xterm so that they remain in X-Server area?
Hmm. I have got it compiled ok, and installed ok, but it does not seem to have any effect. If I run the 'withdll -d:peacehook.dll winmine' from a remote linux session (with the env vars setup), withdll just sits there. No seg fault, nothing. I just have to end up hitting Ctrl-C. On Tue, 08 Feb 2005 13:57:11 +0200, David Fraser [EMAIL PROTECTED] wrote: Alexander Gottwald wrote: On Tue, 8 Feb 2005, Karl Bowden wrote: Has any body made any more progress on compiling and getting the CygPeace project working? This seems like a very worthwile project if somebody could supply binaries. The only other application I have seen to offer this feature of exporting applications, is the Citrix product. Not compiling is the big issue but running. It constantly crashed with cygwin 1.5.* but was reported to run with cygwin 1.3.* Afair there were some definitions which needed to be changed in order to get cygpeace to work, but these were quite simple changes. Below is error I get to do with inttypes.h that is included by a lot of files. $ make gcc -g -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 -I../common -I./include -DDLLMAIN -D__aconst= -DEXTERN_C= -c -o ../common/handle.o ../common/handle.c g++ -g -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 -I../common -I./include -DDLLMAIN -D__aconst= -DEXTERN_C=extern \C\ -c -o ../ui.so/BitmapBlock.o ../ui.so/BitmapBlock.cc In file included from ../ui.so/BitmapBlock.h:33, from ../ui.so/BitmapBlock.cc:29: include/sys/inttypes.h:6: error: conflicting types for `typedef unsigned int uint32_t' /usr/include/stdint.h:28: error: previous declaration as `typedef long unsigned int uint32_t' make: *** [../ui.so/BitmapBlock.o] Error 1 Maybe removing #inlude sys/inttypes.h helps Confirmed that I got it running fine on cygwin 1.3.x If you do make any progress on 1.5.x please report back to the list! David
Re: Is it somehow possible to start Windows applications from xterm so that they remain in X-Server area?
Probably best to test it using a local cygwin X server and a local application. Other than that I don't really understand cygpeace so I probably can't help, but you could always try contact the author though I'm not sure he intends to maintain it Karl Bowden wrote: Hmm. I have got it compiled ok, and installed ok, but it does not seem to have any effect. If I run the 'withdll -d:peacehook.dll winmine' from a remote linux session (with the env vars setup), withdll just sits there. No seg fault, nothing. I just have to end up hitting Ctrl-C. On Tue, 08 Feb 2005 13:57:11 +0200, David Fraser [EMAIL PROTECTED] wrote: Alexander Gottwald wrote: On Tue, 8 Feb 2005, Karl Bowden wrote: Has any body made any more progress on compiling and getting the CygPeace project working? This seems like a very worthwile project if somebody could supply binaries. The only other application I have seen to offer this feature of exporting applications, is the Citrix product. Not compiling is the big issue but running. It constantly crashed with cygwin 1.5.* but was reported to run with cygwin 1.3.* Afair there were some definitions which needed to be changed in order to get cygpeace to work, but these were quite simple changes. Below is error I get to do with inttypes.h that is included by a lot of files. $ make gcc -g -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 -I../common -I./include -DDLLMAIN -D__aconst= -DEXTERN_C= -c -o ../common/handle.o ../common/handle.c g++ -g -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 -I../common -I./include -DDLLMAIN -D__aconst= -DEXTERN_C=extern \C\ -c -o ../ui.so/BitmapBlock.o ../ui.so/BitmapBlock.cc In file included from ../ui.so/BitmapBlock.h:33, from ../ui.so/BitmapBlock.cc:29: include/sys/inttypes.h:6: error: conflicting types for `typedef unsigned int uint32_t' /usr/include/stdint.h:28: error: previous declaration as `typedef long unsigned int uint32_t' make: *** [../ui.so/BitmapBlock.o] Error 1 Maybe removing #inlude sys/inttypes.h helps Confirmed that I got it running fine on cygwin 1.3.x If you do make any progress on 1.5.x please report back to the list! David
src/winsup/cygwin ChangeLog fhandler_disk_file.cc
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2005-02-09 19:28:06 Modified files: winsup/cygwin : ChangeLog fhandler_disk_file.cc Log message: * fhandler_disk_file.cc (fhandler_disk_file::ftruncate): Fix checking lseek return code. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.2707r2=1.2708 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_disk_file.cc.diff?cvsroot=srcr1=1.99r2=1.100
src/winsup/w32api ChangeLog lib/directx/dinput ...
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2005-02-10 01:19:44 Modified files: winsup/w32api : ChangeLog winsup/w32api/lib/directx: dinput_joy.c dinput_joy2.c dinput_kbd.c dinput_mouse.c dinput_mouse2.c dinput_private.h Log message: 2005-02-10 Jiri Malak [EMAIL PROTECTED] Danny Smith [EMAIL PROTECTED] * lib/directx/dinput_private.h (ATTRIBUTE_TEXT_SECTION): New define for Open Watcom portability. * lib/directx/(dinput_joy.c, dinput_joy2.c, dinput_kbd.c, dinput_mouse.c, dinput_mouse2.c): Use new macro in definition of local c_rgodfDI* objects. Replace .rdata section attribute with 'const' keyword in definition of global c_dfDI* objects. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/ChangeLog.diff?cvsroot=srcr1=1.648r2=1.649 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/lib/directx/dinput_joy.c.diff?cvsroot=srcr1=1.1r2=1.2 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/lib/directx/dinput_joy2.c.diff?cvsroot=srcr1=1.1r2=1.2 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/lib/directx/dinput_kbd.c.diff?cvsroot=srcr1=1.1r2=1.2 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/lib/directx/dinput_mouse.c.diff?cvsroot=srcr1=1.1r2=1.2 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/lib/directx/dinput_mouse2.c.diff?cvsroot=srcr1=1.1r2=1.2 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/lib/directx/dinput_private.h.diff?cvsroot=srcr1=1.1r2=1.2
Re: patch to allow touch to work on HPFS (and others, maybe??)
On Feb 8 14:38, Mark Paulus wrote:
Well, all I can say, is That's Uuuugggllleeey.
When I print fsname on the HPFS mounted volume,
I get back '??SS'. What the heck is that??? Somehow,
I'm guessing that's not something I want to be doing a
string comparison on, for any kind of stability purpose.
Guess I'll live with not being able to 'touch' on mounted
HPFS volumes, and not do builds on that remote volume.
Sheesh, what a pain. Thanks for the pointers, tho.
Hey, why do you give up so quickly? If it's not the one way, it might
be another one. For us unknowing folks which have no OS/2 box with
HPFS to mount, would you mind to run the below application on your NT
box and paste the output into the reply? I'm curious to see the result.
On NTFS, it looks like this:
$ ./getvolinfo `pwd`
rootdir: C:\
Volume Name:
Serial Number : 813830114
Max Filenamelength : 255
Filesystemname : NTFS
Flags:
FILE_CASE_SENSITIVE_SEARCH : TRUE
FILE_CASE_PRESERVED_NAMES : TRUE
FILE_UNICODE_ON_DISK: TRUE
FILE_PERSISTENT_ACLS: TRUE
FILE_FILE_COMPRESSION : TRUE
FILE_VOLUME_QUOTAS : TRUE
FILE_SUPPORTS_SPARSE_FILES : TRUE
FILE_SUPPORTS_REPARSE_POINTS: TRUE
FILE_SUPPORTS_REMOTE_STORAGE: FALSE
FILE_VOLUME_IS_COMPRESSED : FALSE
FILE_SUPPORTS_OBJECT_IDS: TRUE
FILE_SUPPORTS_ENCRYPTION: TRUE
FILE_NAMED_STREAMS : TRUE
FILE_READ_ONLY_VOLUME : FALSE
Corinna
=== SNIP ===
#include stdio.h
#include string.h
#define _WIN32_WINNT 0x0500
#include windows.h
#ifndef FILE_NAMED_STREAMS
#define FILE_NAMED_STREAMS 0x4
#endif
#ifndef FILE_READ_ONLY_VOLUME
#define FILE_READ_ONLY_VOLUME 0x8
#endif
int
main (int argc, char **argv)
{
char winpath[256];
char rootdir[256];
char volname[256];
char fsname[256];
DWORD sernum = 0;
DWORD maxlen = 0;
DWORD flags = 0;
if (argc 2)
{
fprintf (stderr, Doofi!\n);
return 1;
}
cygwin_conv_to_full_win32_path (argv[1], winpath);
if (!GetVolumePathName(winpath, rootdir, 256))
{
fprintf (stderr, GetVolumePathName: %d\n, GetLastError ());
return 1;
}
printf (rootdir: %s\n, rootdir);
if (!GetVolumeInformation (rootdir, volname, 256, sernum,
maxlen, flags, fsname, 256))
{
fprintf (stderr, GetVolumeInformation: %d\n, GetLastError ());
return 1;
}
printf (Volume Name: %s\n, volname);
printf (Serial Number : %lu\n, sernum);
printf (Max Filenamelength : %lu\n, maxlen);
printf (Filesystemname : %s\n, fsname);
printf (Flags:\n);
printf ( FILE_CASE_SENSITIVE_SEARCH : %s\n,
(flags FILE_CASE_SENSITIVE_SEARCH) ? TRUE : FALSE);
printf ( FILE_CASE_PRESERVED_NAMES : %s\n,
(flags FILE_CASE_PRESERVED_NAMES) ? TRUE : FALSE);
printf ( FILE_UNICODE_ON_DISK: %s\n,
(flags FILE_UNICODE_ON_DISK) ? TRUE : FALSE);
printf ( FILE_PERSISTENT_ACLS: %s\n,
(flags FILE_PERSISTENT_ACLS) ? TRUE : FALSE);
printf ( FILE_FILE_COMPRESSION : %s\n,
(flags FILE_FILE_COMPRESSION) ? TRUE : FALSE);
printf ( FILE_VOLUME_QUOTAS : %s\n,
(flags FILE_VOLUME_QUOTAS) ? TRUE : FALSE);
printf ( FILE_SUPPORTS_SPARSE_FILES : %s\n,
(flags FILE_SUPPORTS_SPARSE_FILES) ? TRUE : FALSE);
printf ( FILE_SUPPORTS_REPARSE_POINTS: %s\n,
(flags FILE_SUPPORTS_REPARSE_POINTS) ? TRUE : FALSE);
printf ( FILE_SUPPORTS_REMOTE_STORAGE: %s\n,
(flags FILE_SUPPORTS_REMOTE_STORAGE) ? TRUE : FALSE);
printf ( FILE_VOLUME_IS_COMPRESSED : %s\n,
(flags FILE_VOLUME_IS_COMPRESSED) ? TRUE : FALSE);
printf ( FILE_SUPPORTS_OBJECT_IDS: %s\n,
(flags FILE_SUPPORTS_OBJECT_IDS) ? TRUE : FALSE);
printf ( FILE_SUPPORTS_ENCRYPTION: %s\n,
(flags FILE_SUPPORTS_ENCRYPTION) ? TRUE : FALSE);
printf ( FILE_NAMED_STREAMS : %s\n,
(flags FILE_NAMED_STREAMS) ? TRUE : FALSE);
printf ( FILE_READ_ONLY_VOLUME : %s\n,
(flags FILE_READ_ONLY_VOLUME) ? TRUE : FALSE);
return 0;
}
=== SNAP ===
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader mailto:cygwin@cygwin.com
Red Hat, Inc.
Re: patch to allow touch to work on HPFS (and others, maybe??)
On Feb 8 13:49, Yitzchak Scott-Thoennes wrote: On Tue, Feb 08, 2005 at 10:10:29AM +0100, Corinna Vinschen wrote: Have a look into path.cc, fs_info::update (). Test the filesystem name in fs_info::update and add a flag to fs_info which tells us that FILE_WRITE_ATTRIBUTES is supported (which is valid for NTFS and FAT, btw.). How should the flag default for things other than NTFS, HPFS, and FAT? I'm all for negative confinement. FILE_WRITE_ATTRIBUTES unless proved otherwise. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc.
Re: RXVT copy/paste behavior
On Feb 8 21:47, Gary R. Van Sickle wrote: [mailto:[EMAIL PROTECTED] On Behalf Of Dave Korn From: cygwin-owner On Behalf Of Phil Betts The selection model used by rxvt is standard throughout the X11 world. It's insane. I'm with you 1000% on this one Korny, [etc] May I throw in a TITTTL here? UI models is as such Cygwin specific as is, for example, the stone-age old discussion about the right editor. Reply-To set to cygwin-talk. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- 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: bash: tab completion failure from (but not at) /
On Feb 8 19:58, Ronald Landheer-Cieslak wrote: Corinna Vinschen wrote: On Feb 8 07:19, [EMAIL PROTECTED] wrote: Recent remarks (I have an idea about how to fix the race but it would introduce a destabilizing change that I'd rather not chance before 1.5.13 is released) suggest that an updated cygwin1.dll might be imminent. Please could I mention a minor but annoying glitch described along with Corinna's immediate and effective fix at http://www.cygwin.com/ml/cygwin/2004-05/msg00449.html but which has re-emerged in recent snapshots, at least since http://www.cygwin.com/ml/cygwin/2004-12/msg00838.html, in which Corinna records her perplexity (weird) at this re-emergence. Things worked properly in snapshot 20041222 but fail from 20041223. Nevertheless, that's a bash problem. Is our bash maintainer still around? Yep, still here.. I'll have a look at what your patch in Bash is up to tomorrow (still don't have a Windows machine at home) but it should be compiled in - there's no reason why it wouldn't be: the only thing I haven't changed is a fix for http://cygwin.com/ml/cygwin/2004-09/msg01517.html. I'll report back when I've checked (ping me if that doesn't happen in 24 hours - I'm rather busy lately...) As I already wrote in http://www.cygwin.com/ml/cygwin/2004-12/msg00838.html, it seems that the patch is missing in the binary but not in the source. A self-build version with the patch behaves correctly, the -17 version does not. If you have not much time anymore (and not even a Windows machine at home), are you still willing to be bash maintainer for Cygwin? I'm curious if there's a chance to upgrade us to 3.0 at one point. It seems rather stable to me, though it needs the same fix to bash_directory_completion_hook as the 2.05 version :-} Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- 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 setup.exe?
On Feb 8 18:18, Igor Pechtchanski wrote: Eric, Please make sure your mailer honors the Reply-To: field. I set it for a reason. Thanks. I've also reformatted your top-posted message. Top-posting is rather annoying -- if you can possibly avoid it, please do. [...] and then there's the full quote, Igor, which is even more annoying than the top posting. http://cygwin.com/acronyms/#TOFU I would also appreciate, if you could add the http://www.dtcc.edu/cs/rfc1855.html link to the OLOCA entry. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- 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: RXVT copy/paste behavior
On Tuesday, February 08, 2005 7:25 PM Dave Korn wrote: It's insane. Unless you have the precision muscular control skills of a world-class gymnast, a mouse always moves at least a little bit when you press down on the button. Which is one reason why I prefer a trackball - moving and clicking are independent operations. They take a bit of getting used to, but after the first day or so, you stop trying to shove it around your desk. Once you've got used to it, the mouse seems very clumsy. I also found that my RSI and back problems disappeared, but YMMV. This makes it very tricky to select a new window without unintentionally erasing the contents of the clipboard that you were hoping to paste there because the mouse moved just enough as you clicked it to select a single character and the auto-copy destroyed your clipboard contents without asking. I use focus-follows-mouse (aka X-mouse) so no clicking is required. Destroying user data without any kind of confirmation, are-you-sure, or requiring a difficult-to-type-accidentally key-combination (such as ctrl-c) is an appallingly incompetent piece of UI design. It's like having a pistol without a safety catch, or an ICBM without a dual-key control. A fair point. FWIW, it's not just X programs that do this. TeraTerm (a 'doze terminal emulator) One reason I use it ;-) And don't tell me... I wouldn't dream of telling the great Dave K anything! ksh saved my sanity back in the days when it was just csh or sh. ...that I'm only ever allowed to select windows by clicking on the menu bar and that I get what I deserve if I click in the main part of the window. If you have lots of windows open, the menu bars of many of them are often obscured. Why should 99% of the window's surface area be verboten for selecting that window? Again, focus-follows-mouse (and auto-raise if you like that sort of thing - I don't) WFM. The entire model is screwy. It wastes lots of my time and interrupts my workflow. The 'doze way works smoothly and is much closer to fail-safe: it's very hard to accidentally press Ctrl+C and lose data in the same way. Equally, I waste lots of time going back to the original window because I forgot to press ctrl-C. Real experts... avoid using the pointer altogether? ...operate a computer with one hand on the mouse and one on the keyboard *at the same time* anyway. OK, now you're just showing off! I guess it all boils down to personal preference in the end. Until the telepathic HCI comes along (RSN), we'll all struggle to communicate our intentions computers from time to time. Even then, I'm not sure that I would really appreciate a computer that obligingly uninstalled all Microsoft programs every 5 minutes! Phil -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.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: cygwin1.dll crash
-Original Message- From: cygwin-owner On Behalf Of Lannoye Xavier Sent: 09 February 2005 07:54 hi again the problem is solved (blushing...) I rebooted my computer, and now everything works fine again thanks for your time;-/ Heh, that was going to be my next suggestion anyway! There must still have been a copy of the .dll loaded into memory. Glad to hear it's all fixed now. :) cheers, DaveK -- Can't think of a witty .sigline today -- 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: strange cp behavior with (coreutils 5.2.1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jane Doe on 2/8/2005 8:15 PM: $ net use shiva /u:shiva\\administrator $ cp //shiva/c\$/cvsmq/eqgame.h . cp: cannot open `//shiva/c$/cvsmq/eqgame.h.exe' for reading: No such file or directory I think this used to work when cp was part of fileutils. The file itself has owner (develop\dkaa) read permissions but Everyone has no explicit permissions. Giving Everyone read permissions makes it work. Could you please try the test release of coreutils-5.3.0-2 and see if the issue is still there? Are you complaining because the file should have been accessible with your first approach, or because it should have been inaccessible but the error message added '.exe'? - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCChXq84KuGfSFAYARAo/pAJ4rLv7SHFiue7ByRnioAGFHiMEL4ACgrwKg aDxLtoZA0pux8R0OWV/dNew= =dbh0 -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: Can't cd into directory
[ !! Please do not email me directly !! ] acidblue wrote: - Original Message - From: Jonathan Arnold [EMAIL PROTECTED] acidblue wrote: acidblue wrote on Tuesday, February 08, 2005 9:18 AM: I'm using the following syntax: cd '/cygdrive/c/Documents and Settings' I get a No such file or directory message. cygwin on WinXP installed to C:/ I get this message no matter which directory I try to cd into. Driving me nuts Please help. [EMAIL PROTECTED] To: cygwin@cygwin.com Sent: Tuesday, February 08, 2005 12:26 AM Subject: RE: Can't cd into directory Please post output of mount -p Sure thing: [EMAIL PROTECTED] ~ $ mount -p Prefix Type Flags /cygdrive system binmode [EMAIL PROTECTED] ~ $ You should probably double check the pages found here: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames in the Using Cygwin document. Probably you have a problem with the mount table. -- Jonathan Arnold (mailto:[EMAIL PROTECTED]) Amazing Developments http://www.buddydog.org I feel like a fugitive from the law of averages. - William H. Mauldin oh, oh i get this error: [EMAIL PROTECTED] ~ $ mount -s c:\\ /c mount: warning - /c does not exist. That looks fine - it is a warning that /c didn't exist, but mount will automatically create it. Again, see the man page for mount, as well as the page in the User's Guide: http://cygwin.com/cygwin-ug-net/using-utils.html#mount Note especially the -f option, which will force mount to be silent when creating mount directories. -- Jonathan Arnold (mailto:[EMAIL PROTECTED]) Amazing Developments http://www.buddydog.org I feel like a fugitive from the law of averages. - William H. Mauldin -- 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 digest format
-Original Message- From: cygwin-owner On Behalf Of Gorden Jemwa Sent: 09 February 2005 07:54 To: cygwin [ X-post to -talk list; I think we should TITTTL if the discussion becomes any prolonged. ] Could the digest format be changed into a single message format containing all the messages instead of a single message with other messages embeddded as attachments? I don't know what others think but IMO its easier to read browse through a single message than opening individual attachment, unless (of course) there are strong reasons for the current digest format. I can think of a couple of immediate advantages: 1) If you reply to a digest, the References or In-Reply-To headers will point to the digest, rather than the item you're actually replying to, which breaks the threading. Sending the posts as individual items means people will reply to the one they actually want to reply to. And the Subject line will be set correctly too. 2) We never get idiots sending 1 line top-posted replies with quoted copies of the entire preceding day's traffic below. Item 1) may be important to some people, but it's 2) that particularly matters to me! cheers, DaveK -- Can't think of a witty .sigline today -- 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: Couldn't create signal pipe - User permission problem? (IIS6/Win2003)
-Original Message- From: cygwin-owner On Behalf Of andy Sent: 08 February 2005 16:01 Subject: Couldn't create signal pipe - User permission problem? (IIS6/Win2003) When I try to execute the binary it exists with the error message shown below: 3 [main] ? 1148 cygheap_user::init: OpenProcessToken(), Win32 error 5 D:\cgi-bin\cdrtools-2.01-win32-bin\mkisofs.exe (1148): *** couldn't create signal pipe, Win32 error 0 I have identified Win32 error 5 as an access denied error. Well, yes, but it was the OpenProcessToken call that failed with error 5. It's probably a knock-on effect of that failure that stops the pipe from being opened, but the actual failure is in cygheap init. W2k3 does have some locked down privs that cause problems for cygwin apps. I am not executing mkisofs.exe from a command prompt or shell, but rather as a CGI application from a PHP script running under the IIS6 web server. I found this thread: http://cygwin.com/ml/cygwin/2003-10/msg00447.html I granted the user the application pool is running under create global objects permission as suggested. Additionally I have granted the user adjust memory quotas for a process and replace a process at token level as Microsoft suggests is necessary for CGI applications. But still the process exits with the same error message. :-O Yeessh! There are VERY VERY VERY good reasons why IWAM_USER should NEVER UNDER ANY CIRCUMSTANCES BE ALLOWED TO ALTER IT'S OWN PRIVILEGE LEVEL! Still, it's probably OK if the server isn't externally accessible in any way. Still, it's your machine, it's your funeral. And so my question is, does anyone have any idea which permission might be missing and be causing this error to occur? Well if OpenProcessToken fails, that would suggest that replace a process level token (it's the token that is being replaced, not the process, as you wrote earlier) might be missing, so verify you set it correctly. Failing that, it may well be that IIS6 simply will not allow application pool processes to get elevated privileges. Not too sure. cheers, DaveK -- Can't think of a witty .sigline today -- 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: Help with deleting Cygwin shortcuts
On Wed, 9 Feb 2005, Gerrit P. Haase wrote: Ivan Lenev wrote: I'm pretty sure that I have full access since I'm the only user, and I don't see a Security/Permissions Tab in the properties of any of my files. I'm running WinXP Home, and no file sharing. XP Home sucks, get a book about XP where is described how to tweak security settings anyway. getfacl/setfacl? chown? I -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT -- 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/
20050208 snapshot = yay! (Was: Re: hyperthreading fix, try #1)
Rolf Campbell wrote: This test does fail (in the same way) on non-hyperthreaded machines (Win2000Pro on a PIII). But, this is a regression from 1.5.12 (that test runs fine on the non-HT machine with 1.5.12. There was (maybe still is) a problem with running make -j without the max task counter, but make -j2 has always worked very well on non-ht machines. I will try out some other snapshots and see if I can narrow down the time when this showed up later today. -Rolf I've tried yesterday's snapshot with my test-case, and with my real build system. So far, things look very good. -Rolf -- 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/
Building Perl modules
Hello, Sorry if this has already been asked in the list, but search is temp. disabled. Has anyone been able to build Perl modules (in this case HTML::Parser) under cygwin? gcc is handing back failed header file references, but the include path correct. I am a bit puzzled. A snippet of the errors: gcc -c -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -I/usr/local/include -DUSEIMPORTLIB -O3 -DVERSION=\3.45\ -DXS_VERSION=\3.45\ -I/usr/lib/perl5/5.8/cygwin/CORE -DMARKED_SECTION Parser.c Parser.xs:18:20: EXTERN.h: No such file or directory Parser.xs:19:18: perl.h: No such file or directory Parser.xs:20:18: XSUB.h: No such file or directory Parser.xs:30:24: patchlevel.h: No such file or directory Any help is appreciated! Thanks, Alejandro -- 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/
Bug in python's tempfile : returning wrong object type
With cygwin distributed python (2.4, dec 4 2004), there's a bug in tempfile. import tempfile fo = tempfile.TemporaryFile() type(fo) This should return type 'file', but is currently returning type 'instance' This also seems broken on python 2.3.4 Thanks Nick -- 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/
snapshots are breaking shred
With coreutils 5.3.0-2 and various snapshots, I am seeing regressions in shred(1)caused by cygwin changes: 1.5.12: $ echo a a $ shred --remove a $ echo $? 0 $ ls $ 20050131: $ echo a a $ shred --remove a shred: .: fsync failed: Permission denied shred: .: fsync failed: Permission denied $ echo $? 1 $ ls $ 20050206 and 20050208: $ echo a a $ shred --remove a shred: a: error truncating $ echo $? 1 $ ls a $ uname -a CYGWIN_NT-5.0 eblake 1.5.13s(0.118/4/2) 20050208 14:21:58 i686 unknown unknown Cygwin $ 20050206 introduced Corinna's changes to ftruncate, which might explain the current failure. I don't know when fsync regressed between 1.5.12 and 20050131, and it is probably still broken in 20050208 since shred bypasses the final fsync on . after detecting the earlier error on ftruncate. The following strace chunk shows that fd 3 (assigned to ./a) was open for writing as evidenced by the successful writev, so ftruncate should have succeeded instead of dying with EBADF: 71 127064 [main] shred 13776 writev: 1024 = write (3, 0x22A2F0, 1), errno 0 417 127481 [main] shred 13776 fhandler_base::lseek: lseek (/tmp/shred.test/a, 0, 1) 70 127551 [main] shred 13776 fhandler_base::lseek: setting file pointer to 0 (high), 0 (low) 68 127619 [main] shred 13776 fhandler_base::lseek: lseek (/tmp/shred.test/a, 0, 0) 63 127682 [main] shred 13776 fhandler_base::lseek: setting file pointer to 0 (high), 0 (low) 65 127747 [main] shred 13776 ftruncate64: -1 = ftruncate (3, 0) 612 128359 [main] shred 13776 fhandler_base::write: binary write shred: 573 128932 [main] shred 13776 fhandler_base::write: binary write a: error truncating I am also seeing the ftruncate errors when running automake, but since that invokes a perl script with many forks() before the ftruncate(), compared to the single process of shred, it was easier to use shred as the example of reproducibility during debugging. $ automake Makefile autom4te: cannot truncate autom4te.cache/requests at 0: Bad file descriptor automake: autoconf failed with exit status: 1 -- Eric Blake -- 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: [PATCH] Re: perl winpid?
Yitzchak Scott-Thoennes schrieb: How does this look? patch looks ok to me. Or as seperate Proc::Cygwin package, which could be maintained at CPAN and go to vendor_perl within gerrit's perl package? Proc::Cygwin::Win32ProcessID($pid) Proc::Cygwin::CygwinProcessID($winpid) I'd rather not create a separate module for this. If p5p will accept it :) -- Reini Urban -- 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: ATT ksh93
Glenn, On Feb 7 13:36, Glenn Fowler wrote: Rather than waste time arguing about cygwin correctness, we added section 2 system call intercepts to our base library to get cygwin to act like unix. The library intercepts keep windows from contaminating our mainline source and scripts. For details see http://www.research.att.com/sw/download/win32/ Since the last cygwin round ATT ksh93, ast libraries, and UWIN source and binaries have been released uder the OSI approved CPL 1.0 (Common Public License 1.0.) I packaged the 2005-02-02 standalone ksh for cygwin and posted setup.hint, tarballs and md5 sums at http://www.research.att.com/sw/download/beta/ The packages under this URL are password protected. See http://www.research.att.com/sw/download/faq.license.html for the rationale and name and password to use (the same name and password for every user.) I believe previous ksh93 vs. cygwin issues mentioned on this list have been addressed in this release. I won't be the cygwin ksh93 maintainer, but I can supply cygwin packages at the above URL to the maintainer, including any changes required in the package files. All of our packages, including the cygwin ones, are generated by table driven scripts, so any cygwin specific package changes will be rolled back into those tables and scripts. I don't understand your problem with being Cygwin maintainer for this package if you patch and build it anyway. The maintenance effort besides building and packing looks pretty small to me. Package specific questions on the Cygwin ML are not going into the millions or so. Well, except for coreutils, perhaps :-) I had a look into the description on http://www.research.att.com/sw/download/win32/ and I don't exactly like what I see. If you think that you know bugs in Cygwin, why don't you talk to us, instead of just creating a web page in which you describe what's wrong in Cygwin from your point of view? There's a cygwin-patches mailing list for ages. This web page helps nobody and it's also sort of insulting since it implies that we would be unreasonable when it comes to talking about changing Cygwin. Especially since a lot of stuff is definitely not in the right or wrong category, but in the how to get it similar category and when talking about how to get it similar, there's no such thing as ultimate correctness. But of course it's your choice. I don't have to like it. I would rather appreciate an open discussion on cygwin-patches (including patches, maybe) or even on cygwin-developers, though. For a start, I have one problem with your implementation. I don't think it's appropriate for the shell to rename files on the fly, just because the .exe suffix is missing, see your descriptions of chmod(2) and creat(2). Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- 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: Building Perl modules
On Wed, Feb 09, 2005 at 12:30:37PM -0500, Alejandro Calbazana wrote: Hello, Sorry if this has already been asked in the list, but search is temp. disabled. Has anyone been able to build Perl modules (in this case HTML::Parser) under cygwin? gcc is handing back failed header file references, but the include path correct. I am a bit puzzled. A snippet of the errors: gcc -c -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -I/usr/local/include -DUSEIMPORTLIB -O3 -DVERSION=\3.45\ -DXS_VERSION=\3.45\ -I/usr/lib/perl5/5.8/cygwin/CORE -DMARKED_SECTION Parser.c Parser.xs:18:20: EXTERN.h: No such file or directory Parser.xs:19:18: perl.h: No such file or directory Parser.xs:20:18: XSUB.h: No such file or directory Parser.xs:30:24: patchlevel.h: No such file or directory Any help is appreciated! Builds here with cpan without problems. I've never tried to build it separately. Gruss Olaf Föllinger -- Olaf Föllinger Senior Consultant IT S.E.S.A. Software und Systeme AG Alt-Moabit 91a D-10559 Berlin Germany Tel: +49 30 390722 -291 Fax: +49 30 390722 -222 Mobil: +49 173 6227080 http://www.sesa.de/ mailto: [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: Building Perl modules
Hmm... Unfortunately, my attempt to build w/ CPAN returns similar results. But, it looks like there might be some hope if you are able to build ok. Thanks, Al Olaf Föllinger wrote: On Wed, Feb 09, 2005 at 12:30:37PM -0500, Alejandro Calbazana wrote: Hello, Sorry if this has already been asked in the list, but search is temp. disabled. Has anyone been able to build Perl modules (in this case HTML::Parser) under cygwin? gcc is handing back failed header file references, but the include path correct. I am a bit puzzled. A snippet of the errors: gcc -c -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -I/usr/local/include -DUSEIMPORTLIB -O3 -DVERSION=\3.45\ -DXS_VERSION=\3.45\ -I/usr/lib/perl5/5.8/cygwin/CORE -DMARKED_SECTION Parser.c Parser.xs:18:20: EXTERN.h: No such file or directory Parser.xs:19:18: perl.h: No such file or directory Parser.xs:20:18: XSUB.h: No such file or directory Parser.xs:30:24: patchlevel.h: No such file or directory Any help is appreciated! Builds here with cpan without problems. I've never tried to build it separately. Gruss Olaf Föllinger -- 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: RXVT copy/paste behavior
-Original Message- From: cygwin-owner On Behalf Of Phil Betts Sent: 09 February 2005 10:43 [ Um, I know this thread is supposed to be TITTTL'd, so I'm not going to discuss the subject of the thread, but I do need to correct a minor misrepresentation: ] And don't tell me... I wouldn't dream of telling the great Dave K anything! ksh saved my sanity back in the days when it was just csh or sh. I'm not that guy. No relation whatsoever. (Boy, did he ever ruin the experience of googling one's own name for _me_ !) Any further discussion of the topic - bock bock b'gwk. You know the rest. cheers, DaveK -- Can't think of a witty .sigline today -- 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: RXVT copy/paste behavior
Dave I do not speak for ATT! Korn wrote: I wouldn't dream of telling the great Dave K anything! ksh saved my sanity back in the days when it was just csh or sh. I'm not that guy. No relation whatsoever. (Boy, did he ever ruin the experience of googling one's own name for _me_ !) The only solution would be to change your name Dave! :-) -- Does fuzzy logic tickle? -- 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: 20050208 snapshot = yay! (Was: Re: hyperthreading fix, try #1)
On Wed, Feb 09, 2005 at 12:27:34PM -0500, Rolf Campbell wrote: Rolf Campbell wrote: This test does fail (in the same way) on non-hyperthreaded machines (Win2000Pro on a PIII). But, this is a regression from 1.5.12 (that test runs fine on the non-HT machine with 1.5.12. There was (maybe still is) a problem with running make -j without the max task counter, but make -j2 has always worked very well on non-ht machines. I will try out some other snapshots and see if I can narrow down the time when this showed up later today. -Rolf I've tried yesterday's snapshot with my test-case, and with my real build system. So far, things look very good. If that's the case, then you can thank Corinna. She found a bug in my code. In my defense, however, causing the problem required her to go to the tremdous effort of running something that she called a cygwin test suite. Duh. 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: snapshots are breaking shred
On Feb 9 17:45, [EMAIL PROTECTED] wrote: With coreutils 5.3.0-2 and various snapshots, I am seeing regressions in shred(1)caused by cygwin changes: [...] $ echo a a $ shred --remove a shred: a: error truncating [...] 20050206 introduced Corinna's changes to ftruncate, which might explain the current failure. I don't know when fsync regressed between 1.5.12 and 20050131, and it is probably still broken in 20050208 since shred bypasses the final fsync on . after detecting the earlier error on ftruncate. The following strace chunk shows that fd 3 (assigned to ./a) was open for writing as evidenced by the successful writev, so ftruncate should have succeeded instead of dying with EBADF: Ouch, ouch, ouch! I see the problem. I'm testing for 0 where I should have tested for = 0. This brakes ftruncate when length is set to 0. As far as fsync is affected, I don't see how that could ever fail, except the Windows call fails for some reason. The fsync code hasn't changed for quite some time. Thanks for the report, I've checked in a patch, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- 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: Re: Building Perl modules
On Wed, Feb 09, 2005 at 01:17:00PM -0500, Alejandro Calbazana wrote: Hmm... Unfortunately, my attempt to build w/ CPAN returns similar results. But, it looks like there might be some hope if you are able to build ok. Thanks, Al Olaf Föllinger wrote: On Wed, Feb 09, 2005 at 12:30:37PM -0500, Alejandro Calbazana wrote: Hello, Sorry if this has already been asked in the list, but search is temp. disabled. Has anyone been able to build Perl modules (in this case HTML::Parser) under cygwin? gcc is handing back failed header file references, but the include path correct. I am a bit puzzled. A snippet of the errors: gcc -c -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -I/usr/local/include -DUSEIMPORTLIB -O3 -DVERSION=\3.45\ -DXS_VERSION=\3.45\ -I/usr/lib/perl5/5.8/cygwin/CORE -DMARKED_SECTION Parser.c Parser.xs:18:20: EXTERN.h: No such file or directory Parser.xs:19:18: perl.h: No such file or directory Parser.xs:20:18: XSUB.h: No such file or directory Parser.xs:30:24: patchlevel.h: No such file or directory All the missing files reside here in /usr/lib/perl5/5.8.5/cygwin-thread-multi-64int/CORE. Maybe this path is the right one for your inlcude section. The path mentioned above doesn't exist here. Gruss Olaf Föllinger -- Olaf Föllinger Senior Consultant IT S.E.S.A. Software und Systeme AG -- 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 python's tempfile : returning wrong object type
Nick Burch wrote: With cygwin distributed python (2.4, dec 4 2004), there's a bug in tempfile. import tempfile fo = tempfile.TemporaryFile() type(fo) This should return type 'file', but is currently returning type 'instance' This also seems broken on python 2.3.4 This isn't a Cygwin problem or feature. The Windows-native Python 2.4 (Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32) gives the same result. I suspect the tempfile module's docs are misleading... it you look at the code, the returned object is an instance of tempfile._TemporaryFileWrapper. -- Chris Herborth ([EMAIL PROTECTED]) Never send a monster to do the work of an evil scientist. -- 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/
20050208 hyperthreading bug is back ?
Summary: I reported before that the 20050206 snapshot appeared to fix the hyperthreading bug for me. Now it seems that the next snapshot 20050208 broke it again. Test Case: -- Command: find z | while read f; do chown username $f; done; and a longer version of the test case command, (same results): export i=1; find z | while read f; do printf %8i: %s\n $i $f; \ chown username $f; ((i++)); done; Note: z is a directory tree under /cygdrive/c with 4000 odd files in it. Result: --- after 700 to 1000 files bash hangs with the following error message: 2 [exiting thread] bash 3328 cygthread::stub: erroneous thread activation, name is NULL The first number varies (2, 4, 8) as well as the number after bash which I take it is the pid. NOTE: The error only occurs when I run this from the command prompt. I put the same command in a file (preceded by a #!/bin/bash -line) and called it chownz.bash ./chownz.bash completes as expected . ./chownz.bash also completes as expected The same test runs without problems on the 20050206 snapshot. My system: -- HP Pavilion, P4HT3.2G, 1G memory, 200G SCSI HD $ uname -a CYGWIN_NT-5.1 nodename 1.5.13s(0.118/4/2) 20050208 14:21:58 i686 unknown unknown Cygwin I tried to include the output from 'cygcheck -s -v -r | tee cygcheck.out' but the interface will not accept lines longer than 80 chars. I can mail it across, just let me know. Regards CV -- 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: 20050208 hyperthreading bug is back ?
CV wrote: Summary: I reported before that the 20050206 snapshot appeared to fix the hyperthreading bug for me. Now it seems that the next snapshot 20050208 broke it again. Result: --- after 700 to 1000 files bash hangs with the following error message: 2 [exiting thread] bash 3328 cygthread::stub: erroneous thread activation, name is NULL And it appears I spoke too early before. I too, still see a problem: 1424 [exiting thread] make 2052 cygthread::stub: erroneous thread activation, name is NULL. None of my simple test cases seems to fail, but in the guts of a 2-hour build, I get that error message and things grind to a halt. -Rolf -- 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: Building Perl modules
That's what puzzles me... All the files gcc claims are missing exist in my include path '/usr/lib/perl5/5.8/cygwin/CORE'. This path does exist on my install. $ pwd /usr/lib/perl5/5.8/cygwin/CORE $ ls -lrt | grep EXTERN.h -rwxrwxrwx 1 acalbaza mkgroup-l-d1751 Jan 27 06:46 EXTERN.h* -rwxrwxrwx 1 acalbaza mkgroup-l-d 129835 Jan 27 06:46 perl.h* -rwxrwxrwx 1 acalbaza mkgroup-l-d 17922 Jan 27 06:46 XSUB.h* -rwxrwxrwx 1 acalbaza mkgroup-l-d4641 Jan 27 06:46 patchlevel.h* ... Here is my perl: $ perl -V Summary of my perl5 (revision 5 version 8 subversion 6) configuration: Platform: osname=cygwin, osvers=1.5.12(0.11642), archname=cygwin-thread-multi-64int uname='cygwin_nt-4.0 loreley 1.5.12(0.11642) 2004-11-10 08:34 i686 unknown unknown cygwin ' config_args='-de -Dmksymlinks -Duse64bitint -Dusethreads -Doptimize=-O3 -Dman3ext=3pm' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=define use64bitall=undef uselongdouble=undef usemymalloc=y, bincompat5005=undef Compiler: cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -I/usr/local/include', optimize='-O3', cppflags='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -I/usr/local/include' ccversion='', gccversion='3.4.1 (cygming special)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='ld2', ldflags =' -s -L/usr/local/lib' libpth=/usr/local/lib /usr/lib /lib libs=-lgdbm -ldb -lcrypt -lgdbm_compat perllibs=-lcrypt -lgdbm_compat libc=/usr/lib/libc.a, so=dll, useshrplib=true, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' -s' cccdlflags=' ', lddlflags=' -s -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS USE_64_BIT_INT USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Built under cygwin Compiled at Jan 27 2005 11:10:54 %ENV: CYGWIN=ntsec tty @INC: /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 . Thanks, Alejandro Olaf Föllinger wrote: On Wed, Feb 09, 2005 at 01:17:00PM -0500, Alejandro Calbazana wrote: Hmm... Unfortunately, my attempt to build w/ CPAN returns similar results. But, it looks like there might be some hope if you are able to build ok. Thanks, Al Olaf Föllinger wrote: On Wed, Feb 09, 2005 at 12:30:37PM -0500, Alejandro Calbazana wrote: Hello, Sorry if this has already been asked in the list, but search is temp. disabled. Has anyone been able to build Perl modules (in this case HTML::Parser) under cygwin? gcc is handing back failed header file references, but the include path correct. I am a bit puzzled. A snippet of the errors: gcc -c -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -I/usr/local/include -DUSEIMPORTLIB -O3 -DVERSION=\3.45\ -DXS_VERSION=\3.45\ -I/usr/lib/perl5/5.8/cygwin/CORE -DMARKED_SECTION Parser.c Parser.xs:18:20: EXTERN.h: No such file or directory Parser.xs:19:18: perl.h: No such file or directory Parser.xs:20:18: XSUB.h: No such file or directory Parser.xs:30:24: patchlevel.h: No such file or directory All the missing files reside here in /usr/lib/perl5/5.8.5/cygwin-thread-multi-64int/CORE. Maybe this path is the right one for your inlcude section. The path mentioned above doesn't exist here. Gruss Olaf Föllinger -- 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: ATT ksh93
On Wed, 9 Feb 2005 19:01:58 +0100 Corinna Vinschen wrote: Glenn, On Feb 7 13:36, Glenn Fowler wrote: I believe previous ksh93 vs. cygwin issues mentioned on this list have been addressed in this release. I won't be the cygwin ksh93 maintainer, but I can supply cygwin packages at the above URL to the maintainer, including any changes required in the package files. All of our packages, including the cygwin ones, are generated by table driven scripts, so any cygwin specific package changes will be rolled back into those tables and scripts. I don't understand your problem with being Cygwin maintainer for this package if you patch and build it anyway. The maintenance effort besides building and packing looks pretty small to me. Package specific questions on the Cygwin ML are not going into the millions or so. Well, except for coreutils, perhaps :-) From past experience I don't want to be a point of contact for the cygwin mailing lists. I had a look into the description on http://www.research.att.com/sw/download/win32/ and I don't exactly like what I see. If you think that you know bugs in Cygwin, why don't you talk to us, instead of just creating a web page in which you describe what's wrong in Cygwin from your point of view? There's a cygwin-patches mailing list for ages. This web page helps nobody and it's also sort of insulting since it implies that we would be unreasonable when it comes to talking about changing Cygwin. Especially since a lot of stuff is definitely not in the right or wrong category, but in the how to get it similar category and when talking about how to get it similar, there's no such thing as ultimate correctness. I went a few rounds with the cygwin lists a while back. Karsten Fleischer volunteered to run some interference too (thanks Karsten.) We got to the point of Karsten offering to patch cygwin, and then questions arose about whether the patches would even be accepted, given mine and Karsten's relationship to UWIN. At that point I had already coded the cygwin system call intercepts and ksh93 and all of the other ast section 1 commands and scripts were running. So we decided to move on to other (non-cygwin) stuff. http://www.research.att.com/sw/download/win32/ As far as the win32 url being insulting to cygwin: if there is anything technically wrong please point it out and I'll correct it. Otherwise its pretty much a statement of fact. cygwin and UWIN make choices about how far they go in emulating the unix API. Like you point out, there is no right or wrong in some of these choices. However, there are definitely consequences for the choices made. It is my opinion that any unix-like porting target should, modulo C source configure style tweaks, accept the unix paradigms that work on all of the other unix-like targets. In some instances cygwin goes counter to that opinion. I worked around those differences by modifying a library used by all ast applications, along with cygwin specific additions to the ast nmake compiler probe. Finally, I documented the workarounds in case anyone might have interest. But of course it's your choice. I don't have to like it. I would rather appreciate an open discussion on cygwin-patches (including patches, maybe) or even on cygwin-developers, though. I stay on the user side of OS API's to maintain hacking sanity. I'll be happy to discuss details of the workarounds cited in the win32 url above. For a start, I have one problem with your implementation. I don't think it's appropriate for the shell to rename files on the fly, just because the .exe suffix is missing, see your descriptions of chmod(2) and creat(2). One hack deserves another. How appropriate is it for cc -o t t.o to create t.exe instead of t? By not handling this at the system call level every script and application must be patched to handle .exe or not .exe. Doing it in one spot allows ksh93 users to forget they're on a windows system -- that's my measure of ultimate correctness. -- Glenn -- 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/
OPENGL package maintainer?
Hi, I have tried unsuccessfully to reach André Bleau who is/was the OpenGL package maintainer. Does anybody know how I can reach him or whom I should send my problems with the OpenGL package? Thanks, Denis -- 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: Building Perl modules
If the current cygwin version of perl is 5.8.6, will the 5.8.5 directory
be used?
If I print out @INC from my cygwin perl, I don't see 5.8.5 or 5.8.6 in
the include path:
perl -v
This is perl, v5.8.6 built for cygwin-thread-multi-64int
perl -e 'for(@INC) {print $_; print \n;}'
/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
.
---
BTW - why are some of the include dir's included twice?
Olaf Fllinger wrote:
All the missing files reside here in
/usr/lib/perl5/5.8.5/cygwin-thread-multi-64int/CORE. Maybe this path is
the right one for your inlcude section. The path mentioned above doesn't
exist here.
--
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/
Stable and Unstable Install Trees
Has anyone experimented with methods for creating more than one useable installation of cygwin on a single workstation? I'm thinking of one install tree that is regarded as stable or production; another as unstable, where software development is happening. Sorry if this has been discussed before, but the mailing list search fuction is currently not available. It seems conceptually that this should work all right, as long as the installs are using a single shared copy of the cygwin dll . True, or not true? Thanks, James R. Phillips -- 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: Stable and Unstable Install Trees
On Wed, Feb 09, 2005 at 02:58:27PM -0700, Phillips, James R wrote: Has anyone experimented with methods for creating more than one useable installation of cygwin on a single workstation? I'm thinking of one install tree that is regarded as stable or production; another as unstable, where software development is happening. Sorry if this has been discussed before, but the mailing list search fuction is currently not available. Please use google in that case. Adding a site:cygwin.com to your search terms will help limit the search. Yes, this has been discussed countless times before. 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: 20050208 hyperthreading bug is back ?
Rolf Campbell thats.unpossible at gmail.com writes: CV wrote: after 700 to 1000 files bash hangs with the following error message: 2 [exiting thread] bash 3328 cygthread::stub: erroneous thread activation, name is NULL And it appears I spoke too early before. I too, still see a problem: 1424 [exiting thread] make 2052 cygthread::stub: erroneous thread activation, name is NULL. None of my simple test cases seems to fail, but in the guts of a 2-hour build, I get that error message and things grind to a halt. OK, but then it would perhaps be interesting to know if the 20050206 snapshot works for you there - or, in case it fails, whether the error is the same or different ? Cheers CV -- 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: 20050208 hyperthreading bug is back ?
CV wrote: Rolf Campbell thats.unpossible at gmail.com writes: CV wrote: after 700 to 1000 files bash hangs with the following error message: 2 [exiting thread] bash 3328 cygthread::stub: erroneous thread activation, name is NULL And it appears I spoke too early before. I too, still see a problem: 1424 [exiting thread] make 2052 cygthread::stub: erroneous thread activation, name is NULL. None of my simple test cases seems to fail, but in the guts of a 2-hour build, I get that error message and things grind to a halt. OK, but then it would perhaps be interesting to know if the 20050206 snapshot works for you there - or, in case it fails, whether the error is the same or different ? Cheers CV The 0206 snapshot is DOA in my tests. -- 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: 20050208 hyperthreading bug is back ?
On Wed, Feb 09, 2005 at 08:47:12PM +, CV wrote: Summary: I reported before that the 20050206 snapshot appeared to fix the hyperthreading bug for me. Now it seems that the next snapshot 20050208 broke it again. Yes, you're right. It's back. I see it myself. How wonderfully bittersweet that I can now reproduce these problems at will. :-) I have a patch that makes it better but a long running test died while I was in the middle of typing this, so apparently it isn't perfect. 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: error (lilypond)
Sean Tou writes: This may be obvious, but I've been having problems with lilypond. I'm a Windows XP user. During the installation, an error message popped up that had the following contents: grep.exe - Unable To Locate Component This application has failed to start because cygintl-1.dll was not found. Re-installing the application may fix this problem. This is not a LilyPond problem, it's a problem with grep. flup to cygwin. 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 Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: error (lilypond)
On Thu, Feb 10, 2005 at 12:01:52AM +0100, Jan Nieuwenhuizen wrote: Sean Tou writes: This may be obvious, but I've been having problems with lilypond. I'm a Windows XP user. During the installation, an error message popped up that had the following contents: grep.exe - Unable To Locate Component This application has failed to start because cygintl-1.dll was not found. Re-installing the application may fix this problem. This is not a LilyPond problem, it's a problem with grep. flup to cygwin. grep relies on lintintl1 which provides cygintl-1.dll. If there is a problem it is an installation problem that would probably be greatly enhanced by providing the details mentioned at: http://cygwin.com/problems.html 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: Building Perl modules
Olaf Föllinger wrote: A snippet of the errors: gcc -c -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -I/usr/local/include -DUSEIMPORTLIB -O3 -DVERSION=\3.45\ -DXS_VERSION=\3.45\ -I/usr/lib/perl5/5.8/cygwin/CORE -DMARKED_SECTION Parser.c Parser.xs:18:20: EXTERN.h: No such file or directory Parser.xs:19:18: perl.h: No such file or directory Parser.xs:20:18: XSUB.h: No such file or directory Parser.xs:30:24: patchlevel.h: No such file or directory All the missing files reside here in /usr/lib/perl5/5.8.5/cygwin-thread-multi-64int/CORE. Maybe this path is the right one for your inlcude section. The path mentioned above doesn't exist here. In perl-5.8.6 the path changed to /usr/lib/perl5/5.8/cygwin/CORE, however there are already modules included in the distribution, e.g. XML::Parser and those compiled ok during the build. Gerrit -- =^..^= -- 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: Building Perl modules
linda w wrote:
If the current cygwin version of perl is 5.8.6, will the 5.8.5 directory
be used?
If I print out @INC from my cygwin perl, I don't see 5.8.5 or 5.8.6 in
the include path:
The naming scheme has changed, I use only the major numbers since 5.8.6
and for upcoming releases.
perl -v
This is perl, v5.8.6 built for cygwin-thread-multi-64int
perl -e 'for(@INC) {print $_; print \n;}'
/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
..
---
BTW - why are some of the include dir's included twice?
Yes, interesting. I didn't noticed it, I'll try to figure out
what the reason is unless you can tell me.
Gerrit
--
=^..^=
--
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: Building Perl modules
Alejandro Calbazana wrote: That's what puzzles me... All the files gcc claims are missing exist in my include path '/usr/lib/perl5/5.8/cygwin/CORE'. This path does exist on my install. $ pwd /usr/lib/perl5/5.8/cygwin/CORE $ ls -lrt | grep EXTERN.h -rwxrwxrwx 1 acalbaza mkgroup-l-d1751 Jan 27 06:46 EXTERN.h* -rwxrwxrwx 1 acalbaza mkgroup-l-d 129835 Jan 27 06:46 perl.h* -rwxrwxrwx 1 acalbaza mkgroup-l-d 17922 Jan 27 06:46 XSUB.h* -rwxrwxrwx 1 acalbaza mkgroup-l-d4641 Jan 27 06:46 patchlevel.h* Hmmm, s.th. wrong with the permissons? Is your /etc/group file empty, then run `mkgroup -l -d` and try again. Gerrit -- =^..^= -- 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: perl Win32 lib support
Yitzchak Scott-Thoennes wrote: What exactly is giving the error, and what error are you getting? I had an IsWinNT is undefined error message 2 days ago, but I removed some old-seeming directories (since I have 5.8.6 installed, I thought I'd try deleting older versioned directories, though I have no 5.8.6 directories and most of the perl-lib files I had installed were under /lib/perl5/5.8.5 which seems odd -- I would have thought installing a newer perl would have installed lib files in 5.8.6...(?) The error/build messages I am seeing now are: cpan install Win32 Running install for module Win32 Running make for G/GS/GSAR/libwin32-0.191.zip Is already unwrapped into directory /share/CPAN/build-cygwin/GSAR001 CPAN.pm: Going to build G/GS/GSAR/libwin32-0.191.zip 'INSTALLSITESEARCH' is not a known MakeMaker parameter name. 'SITE_PREFIX' is not a known MakeMaker parameter name. Checking if your kit is complete... Looks good Checking if your kit is complete... Looks good Writing Makefile for Win32API::File Checking if your kit is complete... Looks good Writing Makefile for Win32API::Net Checking if your kit is complete... Looks good Writing Makefile for Win32API::Registry Checking if your kit is complete... Looks good Writing Makefile for Win32::ChangeNotify Checking if your kit is complete... Looks good Writing Makefile for Win32::Clipboard Checking if your kit is complete... Looks good Writing Makefile for Win32::Console Checking if your kit is complete... Looks good Writing Makefile for Win32::Event Checking if your kit is complete... Looks good Writing Makefile for Win32::EventLog Checking if your kit is complete... Looks good Writing Makefile for Win32::File Checking if your kit is complete... Looks good Writing Makefile for Win32::FileSecurity Checking if your kit is complete... Looks good Writing Makefile for Win32::IPC Checking if your kit is complete... Looks good Unrecognized argument in LIBS ignored: ':nosearch' Unrecognized argument in LIBS ignored: 'wininet.lib' Writing Makefile for Win32::Internet Checking if your kit is complete... Looks good Writing Makefile for Win32::Job Checking if your kit is complete... Looks good Writing Makefile for Win32::Mutex Checking if your kit is complete... Looks good Writing Makefile for Win32::NetAdmin Checking if your kit is complete... Looks good Writing Makefile for Win32::NetResource Checking if your kit is complete... Looks good Writing Makefile for Win32::ODBC Checking if your kit is complete... Looks good Processing hints file hints/cygwin.pl Note (probably harmless): No library found for -lole32 Note (probably harmless): No library found for -loleaut32 Note (probably harmless): No library found for -luuid Note (probably harmless): No library found for -lmsvcrt40 Writing Makefile for Win32::OLE Checking if your kit is complete... Looks good Writing Makefile for Win32::PerfLib Checking if your kit is complete... Looks good Writing Makefile for Win32::Pipe Checking if your kit is complete... Looks good Writing Makefile for Win32::Process Checking if your kit is complete... Looks good Writing Makefile for Win32::Registry Checking if your kit is complete... Looks good Writing Makefile for Win32::Semaphore Checking if your kit is complete... Looks good Writing Makefile for Win32::Service Checking if your kit is complete... Looks good Writing Makefile for Win32::Shortcut Checking if your kit is complete... Looks good Writing Makefile for Win32::Sound Checking if your kit is complete... Looks good Warning: prerequisite Win32API::Registry 0 not found. Writing Makefile for Win32::TieRegistry Checking if your kit is complete... Looks good Writing Makefile for Win32::WinError Writing Makefile for Win32 Writing Makefile for Win32 make[1]: Entering directory `//ishtar/share/CPAN/build-cygwin/GSAR001/libwin32-0.191' cp Win32.pm ../blib/lib/Win32.pm make[2]: Entering directory `//ishtar/share/CPAN/build-cygwin/GSAR001/libwin32-0.191/APIFile' Makefile:705: *** missing separator. Stop. make[2]: Leaving directory `//ishtar/share/CPAN/build-cygwin/GSAR001/libwin32-0.191/APIFile' make[1]: *** [subdirs] Error 2 make[1]: Leaving directory `//ishtar/share/CPAN/build-cygwin/GSAR001/libwin32-0.191' make: *** [subdirs] Error 2 /usr/bin/make -- NOT OK Running make test Can't test without successful make Running make install make had returned bad status, install seems impossible = I don't know which error/warning messages are abnormal, starting with: 1) 'INSTALLSITESEARCH' is not a known MakeMaker parameter name. 'SITE_PREFIX' is not a known MakeMaker parameter name. 2) Unrecognized argument in LIBS ignored: ':nosearch' Unrecognized argument in LIBS ignored: 'wininet.lib' 3) Processing hints file hints/cygwin.pl Note (probably harmless): No library found for -lole32 Note (probably harmless): No library found for -loleaut32 Note (probably harmless): No library found for -luuid Note (probably harmless): No library found for -lmsvcrt40 ### these are all
Re: Building Perl modules
Gerrit P. Haase wrote:
linda w wrote:
perl -V
This is perl, v5.8.6 built for cygwin-thread-multi-64int
perl -e 'for(@INC) {print $_; print \n;}'
/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
..
---
BTW - why are some of the include dir's included twice?
Yes, interesting. I didn't noticed it, I'll try to figure out
what the reason is unless you can tell me.
It should be:
/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
/usr/lib/perl5/vendor_perl/5.8/cygwin
/usr/lib/perl5/vendor_perl/5.8
/usr/lib/perl5/vendor_perl
Anyway, this is not related to the build problems of the OP.
Gerrit
--
=^..^=
--
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: perl Win32 lib support
linda w wrote: Yitzchak Scott-Thoennes wrote: What exactly is giving the error, and what error are you getting? I had an IsWinNT is undefined error message 2 days ago, but I removed some old-seeming directories (since I have 5.8.6 installed, I thought I'd try deleting older versioned directories, though I have no 5.8.6 directories and most of the perl-lib files I had installed were under /lib/perl5/5.8.5 which seems odd -- I would have thought installing a newer perl would have installed lib files in 5.8.6...(?) The naming scheme changed. D+LL name is cygperl_5.8.dll and directories are named .../5.8/... The reason is that you can keep your modules when 5.8.7 is released, unless binary compatibility breaks. The error/build messages I am seeing now are: [...] 3) Processing hints file hints/cygwin.pl Note (probably harmless): No library found for -lole32 Note (probably harmless): No library found for -loleaut32 Note (probably harmless): No library found for -luuid Note (probably harmless): No library found for -lmsvcrt40 ### these are all libs I see in /usr/lib/w32api as liblibname.a Then -L/usr/lib/w32api is missing in hints/cygwin.pl. 4) Warning: prerequisite Win32API::Registry 0 not found. Writing Makefile for Win32::TieRegistry 5) make[2]: Entering directory `//ishtar/share/CPAN/build-cygwin/GSAR001/libwin32-0.191/APIFile' Makefile:705: *** missing separator. Stop. make[2]: Leaving directory ### This appears to be a bug in the Makefile, line 704 has a target, ### but the build-line on line 705 isn't tab-indented, it's space indented ### which would seem to be a problem in the source that builds the Makefile This is annoying, I get it occasionally, I believe it is a bug in MakeMaker, but I couldn't find it yet. Does the build continue if you add the missing tab and run make again? Gerrit -- =^..^= -- 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/
scponly for chrooted sftp server in cygwin
Hi,
I am attempting to setup and sftp server on a windows XP pro machine. I have
the latest cygwin and openssh files from cygwin.com. I downloaded the scponly
source files and am now attempting to compile them. I get the following error
message:
$ make
gcc -g -O2 -I. -I. -DHAVE_CONFIG_H
-DDEBUGFILE='/usr/local/etc/scponly/debuglev
el' -o scponly.o -c scponly.c
gcc -g -O2 -I. -I. -DHAVE_CONFIG_H
-DDEBUGFILE='/usr/local/etc/scponly/debuglev
el' -o helper.o -c helper.c
helper.c:12:36: libgen.h: No such file or directory
helper.c: In function `substitute_known_path':
helper.c:174: warning: passing arg 1 of `strdup' makes pointer from integer
with
out a cast
helper.c:179: warning: passing arg 1 of `strcmp' makes pointer from integer
with
out a cast
make: *** [helper.o] Error 1
I have only found a single post
http://www.cygwin.com/ml/cygwin/2004-11/msg01184.html
that says scponly compiles easily under the new cygwin releases with a few
modifications to the makefile, but it doesn't say what those are. I have
included the configure utility screen output, the makefile, and helper.c file.
I would greatly appreciate any help on this.
Thanks,
Chad
# Autoconfed stuff
srcdir = .
prefix := /usr/local
exec_prefix := ${prefix}
bindir = ${exec_prefix}/bin
sbindir = ${exec_prefix}/sbin
mandir = ${prefix}/man
CFLAGS = -g -O2 -I$(srcdir) -I.
INSTALL = /usr/bin/install -c
CC = gcc
CHROOTED_NAME= scponlyc
CONFDIR := ${prefix}/etc/scponly
DEBUGFILE := ${CONFDIR}/debuglevel
DEFS:= -DHAVE_CONFIG_H -DDEBUGFILE='${DEBUGFILE}'
LN_S = ln -s
all: scponly groups
clean:
rm -f *.o scponly *~ debuglevel ${CHROOTED_NAME} groups
love: clean all
scponly: scponly.o helper.o
${CC} ${CFLAGS} ${DEFS} -o $@ scponly.o helper.o
groups: groups.c
${CC} ${CFLAGS} ${DEFS} -o $@ $
scponly.o: scponly.c config.h scponly.h
${CC} ${CFLAGS} ${DEFS} -o $@ -c $
helper.o: helper.c config.h scponly.h
${CC} ${CFLAGS} ${DEFS} -o $@ -c $
install: scponly debuglevel scponly.8
${INSTALL} -d ${bindir}
${INSTALL} -d ${mandir}/man8
${INSTALL} -d ${CONFDIR}
${INSTALL} -o 0 -g 0 scponly ${bindir}/scponly
${INSTALL} -o 0 -g 0 -m 0644 scponly.8 ${mandir}/man8/scponly.8
${INSTALL} -o 0 -g 0 -m 0644 debuglevel ${DEBUGFILE}
if test x${CHROOTED_NAME} != x; then\
${INSTALL} -d ${sbindir}; \
rm -f ${sbindir}/${CHROOTED_NAME}; \
cp scponly ${CHROOTED_NAME};\
${INSTALL} -o 0 -g 0 -m 4755 ${CHROOTED_NAME}
${sbindir}/${CHROOTED_NAME}; \
fi
debuglevel:
echo 0 $@
jail: install
chmod u+x ./setup_chroot.sh
./setup_chroot.sh
distclean: clean
rm -fr autom4te.cache
rm -f config.h config.log config.status Makefile setup_chroot.sh
maintainer-clean: distclean
rm -f configure
$ ./configure --enable-chrooted-binary
checking build system type... i686-pc-cygwin
checking host system type... i686-pc-cygwin
checking for gcc... gcc
checking for C compiler default output... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking for cut... /usr/bin/cut
checking for grep... /usr/bin/grep
checking for sort... /usr/bin/sort
checking for ldd... no
checking for useradd... no
checking for chown... /usr/bin/chown
checking for chmod... /usr/bin/chmod
checking for dirname... /usr/bin/dirname
checking for id... /usr/bin/id
checking for pw... no
checking for rm... /usr/bin/rm
checking for pwd_mkdb... no
configure: enabling core WinSCP and Vanilla SCP binaries...
checking for sftp-server... /usr/sbin/sftp-server
checking for ls... /bin/ls
checking for scp... /bin/scp
checking for rm... /bin/rm
checking for ln... /bin/ln
checking for mv... /bin/mv
checking for chmod... /bin/chmod
checking for chown... /bin/chown
checking for chgrp... /bin/chgrp
checking for mkdir... /bin/mkdir
checking for rmdir... /bin/rmdir
configure: enabling WinSCP compatability...
checking for pwd... /bin/pwd
checking for groups... /bin/groups
checking for id... /bin/id
checking for echo... /bin/echo
configure: enabling SFTP compatability...
checking for sftp-server... (cached) /usr/sbin/sftp-server
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking
Re: OPENGL package maintainer?
At 04:38 PM 2/9/2005, you wrote: Hi, I have tried unsuccessfully to reach André Bleau who is/was the OpenGL package maintainer. Does anybody know how I can reach him or whom I should send my problems with the OpenGL package? This list is generally the preferred way to discuss Cygwin issues unless they are actual packaging issues, in which case cygwin-apps is the preferred list. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- 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/
[Fwd: Re: bug in setup.exe?]
Dang bottom posters: [It depends on what email client you use to read with -- if one is using a GUI, the top of the message is displayed first. This forces scrolling (or turning) to the last page of an email -- reading it in reverse order...how lame is that? Even if you use a tty mode email interface, few of them display the last page first. Putting the new content at the bottom would force scrolling through a long duplicate that one might not need if one already knows context -- but then one doesn't really know if one needs the quoted context until one has read the new content -- thus, unless it is a very small quote, it's usually more direct to put new content at the top.] However, regarding the topic at hand -- setup, special casing cygwin-dll may fix this problem, but it'd be a kludge. Suppose a pre-uninstall script for squid has a dependency on something in coreutils, you update coreutils and squid, but going alphabetically, coreutils gets uninstalled first. The squid pre-uninstall scripts fail because the core-utils were removed before updating. What I would suggest is ordering the uninstalls via dependencies, as, I would assume (?), setup would do when installing -- i.e. it would install packages that depend on other packages after installing the prerequisites. In the case of removals, packages that have pre-reqs would be ordered to be removed *before* any pre-reqs are uninstalled. This way, your system should never be in a state where 1) pre-reqs for a package are removed before the package that depends on them, or 2) pre-reqs are not already installed before a package that depends on them is installed. I'm sure PTC would apply...;-) Linda Swenson, Eric wrote: Thanks, Igor. Would another possible solution be to have setup special case *only* the cygwin-dll package? -- 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/
