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: 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 , but is currently returning 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: AT&T 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 AT&T 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 AT&T!" 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 , but is currently returning 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: AT&T 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/
more ctime bugs
Corinna, since you've been fixing so many ctime bugs lately to match SUSv3 and POSIX, could you also fix open(2) when O_TRUNC is set, and write(2) and link(2) in general, to touch ctime? I guess this all stems from the fact that the Microsoft documentation for Windows file systems calls out the 3 file times as "create, access, and write", with access updates occuring on read or write; while POSIX names the three times as "file status change, file data access, and file data modify", with access updates only required on read (but allowed on write as an implementation extension). Status changes certainly happen more often than creation, so the meaning of ctime is drastically different depending on which word you substitute for 'c'! I found the problem with link(2) from the coreutils testsuite, and the others by browsing this search on the POSIX docs: http://www.opengroup.org/cgi-bin/susv3search.pl?KEYWORDS=st_ctime+update&SUBSTRING=substring&CONTEXT=%28%2Ffunctions%2F%29 $ rm a b $ touch a $ stat a File: `a' Size: 0 Blocks: 0 IO Block: 1024 regular empty file Device: 10292fb1h/271134641dInode: 17451448556181969 Links: 1 Access: (0666/-rw-rw-rw-) Uid: (22382/ eblake) Gid: (10513/Domain Users) Access: 2005-02-09 12:15:49.179375000 -0700 Modify: 2005-02-09 12:15:49.179375000 -0700 Change: 2005-02-09 12:15:49.179375000 -0700 $ ln a b# calls link(2) $ echo a > a# calls open(2) with O_TRUNC, and calls write(2) $ stat a File: `a' Size: 2 Blocks: 1 IO Block: 1024 regular file Device: 10292fb1h/271134641dInode: 17451448556181969 Links: 2 Access: (0666/-rw-rw-rw-) Uid: (22382/ eblake) Gid: (10513/Domain Users) Access: 2005-02-09 12:15:55.804375000 -0700 Modify: 2005-02-09 12:15:55.804375000 -0700 Change: 2005-02-09 12:15:49.179375000 -0700 # Oops, ctime unchanged It is also interesting to note that Microsoft documents that for FAT, mtime has a resolution of only 2 sec, but ctime has a resolution of 10 ms. There are a lot of scripts out there that end up using `sleep 2' to ensure two files in FAT have different mtime stamps, since POSIX requires make(1) to use mtime and not ctime to determine when one file is older than another. If ctime is consistently updated on writes, perhaps cygwin make could use ctime as a tiebreaker between two files with the same mtime to reduce the need for the sleep 2. -- 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/
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 FÃllinger 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 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 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 li
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 "lib.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
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?]
: [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/