Re: Problems between GV-3.5.8-2 and Ghostscript-8.50-1 ?
I have verified the behavior described. My guess would be that it is an issue in the interface between gv and gs. Dr. Volker Zell is the current cygwin maintainer for gv; I recently took over maintaining gs, bringing it up to the latest 8.50 GPL release. I note that the cygwin version of gv is somewhat out of date; information at http://ftp.gnu.org/gnu/gv/ indicates that 3.5.8, the cygwin version, has been superceded by 3.6.1 upstream. A search of bug reports for 3.5.8 at gnu.org might be instructive; it is possible the newer version fixes this issue. Since the interface works in at least one scenario, i.e., "gs file.pdf &", I am very reluctant to say the problem resides in gs. 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/
cygpath problem
Folks, according to the cygpath manpage, I should get the following, given a short DOS name, e.g. c:\Progra~1: cygpath -wl C:\Progra~1--> C:\Program Files cygpath -ml C:\Progra~1--> C:/Program Files however, the -m option completely ignores the '-l' flag, and I get instead cygpath -ml C:\Progra~1--> C:/Progra~1 cygpath -m C:\Progra~1--> C:/Progra~1 Which is "right", cygpath or its manpage? H. -- 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: Problems between GV-3.5.8-2 and Ghostscript-8.50-1 ?
James R. Phillips wrote: > ... > Dr. Volker Zell is the current cygwin maintainer for gv... > > ... > > I note that the cygwin version of gv is somewhat out of date It would be nice an update of GV to 3.6.1. > Since the interface works in at least one scenario, i.e., "gs file.pdf > &", I am very reluctant to say the problem resides in gs. I suspected also GS because with GS-7.05-2 those problems were absent. Thanks, Angelo. -- 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: cygheap base mismatch detected
On 16 February 2006 23:17, Dill, Jens (END-CHI) wrote: > More test results: Right, thanks for giving us something we can actually get our teeth into... it would really have been helpful to bring out some of this information a bit earlier in the thread, like in the very first post for instance, but better late than never! >> I can run tests in which I allocate static arrays of increasingly >> large size, and I hit the cygheap base problem *exactly* when I >> try to make an array bigger than 1.5 Gb. > > This still happens reliably, and note that I can declare an array > of *exactly* 1.5 Gb, and load and run the program. I hit the > problem when I go over 1.5 Gb (my script increases the size > in 64-Mb increments). Ah, well hang on; you're about to bang into some fairly fundamental OS limitations here. For starters, there's only 2Gb in the total user address space range, and the windows dlls are by default mapped into the top 1/4 of that, 0x6000 - 0x8000. >> I can run tests in which I set the --stack option for the linker >> to increasingly large sizes, and I get a "thread handle not set" >> error during execution the minute my stack size exceeds 0.5 Gb. >> Yes, that's 0.5. I never go to the full 1.5 Gb. That's a new one I haven't heard of before. It's not very surprising that there are more limitations on the stack than on the heap, as it's kinda special. > My app includes a lot of DLLs. I used cygcheck to get the list, > and summed up their sizes. The total code size on disk before > loading of the app plus the DLLs is just over 115 Mb, leaving > over 1420 Mb to be taken up by static and dynamic memory. > I still don't think the app uses more than a couple of Mb of > static memory, and the problem occurs before anything dynamic > can be allocated. What am I overlooking? Hmm, what kind of DLLs? Any of these your own custom builds? In particular do some of them have base addresses still set to the default 0x1000? If so, the first one that gets loaded into memory is going to frag the address map into two chunks, which is bound to impact the size of contiguous heap chunk that can be allocated. Have you looked into 'rebaseall' yet? There's also the windows boot.ini /3GB switch to investigate, but I remember there having been some kind of limitation on that in the past; I'm afraid I can't remember what the problem was nor if it still applies. 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: Problems using Solaris mapped drive
On Feb 16 09:59, Cowdery, James wrote: > I just updated cygwin and my Solaris mapped drive no longer works > properly. If I create a directory I cannot remove it. I just get > permission denied. If I try and copy a file I get the "skipping file > 'filename' , as it was replaced while being copied" error. The Solaris > machine is running 5.9. I am running cygwin 1.5.19-4. I have seen some > chatter on the copying error message but it wasn't clear if this related > to the same problem I have encountered. I tried reverting to 1.5.18-1 > and snapshot cygwin1-20060206.dll neither of which helped. Here is the > output of the getvolinfo tool in case that helps. My other remote drives > and local drives seem to work fine. Ideas Appreciated. > Thanks, > James > > rootdir: l:\ > Volume Name: <.> > Serial Number : 37093646 > Max Filenamelength : 128 > Filesystemname : > Flags: > FILE_CASE_SENSITIVE_SEARCH : TRUE > FILE_CASE_PRESERVED_NAMES : TRUE > FILE_UNICODE_ON_DISK: FALSE > FILE_PERSISTENT_ACLS: TRUE > FILE_FILE_COMPRESSION : FALSE > FILE_VOLUME_QUOTAS : TRUE > FILE_SUPPORTS_SPARSE_FILES : FALSE > FILE_SUPPORTS_REPARSE_POINTS: FALSE > FILE_SUPPORTS_REMOTE_STORAGE: FALSE > FILE_VOLUME_IS_COMPRESSED : FALSE > FILE_SUPPORTS_OBJECT_IDS: FALSE > FILE_SUPPORTS_ENCRYPTION: FALSE > FILE_NAMED_STREAMS : FALSE > FILE_READ_ONLY_VOLUME : FALSE Sorry, but I doubt that this doesn't work with the latest Cygwin snapshots. The current rule, when to use the inode information of a drive is like this: - If GetDriveType() == DRIVE_UNKNOWN, then we don't trust the inode information and use name hashes instead. - All drives have to have FILE_PERSISTENT_ACLS == TRUE, otherwise we use name hashes. - Remote drives also need to have FILE_SUPPORTS_OBJECT_IDS == TRUE, or they have to have exactly the following set of flags set to TRUE: FILE_CASE_SENSITIVE_SEARCH | FILE_CASE_PRESERVED_NAMES | FILE_PERSISTENT_ACLS which is the set of flags set to TRUE for the usual Samba 3.x shares. So your above volume information is evaluated as an unreliable drive (remote, FILE_SUPPORTS_OBJECT_IDS == FALSE and not Samba), which results in using pathname hashes instead of the inode numbers returned by the appropriate Windows functions. I don't see how it's possible to get the "skipping file..." message with a recent snapshot. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Error C1083
On 16 February 2006 19:36, Elin Aronsen wrote: > Hi ! > > I have attached cygcheck and the to logfiles. I do not know why in > the logfile I geet the message it cannot find oistream fopen. Very > greatful for help. > > Elin Aronsen Can't help very much, because I don't know what CLHEP is, but I noticed a couple of things: ---!--- Chinsoo [EMAIL PROTECTED] ~ $ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/Program Files/Microsoft Visual Studio .NET 2003/Vc7/Bin:/cy gdrive/c/Program Files/Microsoft Visual Studio .NET 2003/Common7/IDE:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/SYSTEM 32:/cygdrive/c/ORAWIN95/BIN:/usr/lib/lapack Chinsoo [EMAIL PROTECTED] ~/CLHEP $ ./configure creating cache ./config.cache checking host system type... i686-pc-cygwin checking target system type... i686-pc-cygwin checking build system type... i686-pc-cygwin checking for cl... cl ---!--- This is very strange. Why has configure chosen to use 'cl' for the compiler? Did you define CC='cl' in your environment? Maybe it looks for cl before it looks for gcc because of a bug in the autoconf scripts in the project. If you were to reset your $PATH to remove the Visual Studio .NET folders, it might not find cl and might choose gcc instead, then it would probably work right. ---!--- checking how to run the C++ preprocessor... /lib/cpp ---!--- And of course the gcc preprocessor and the microsoft compiler aren't going to play nicely together. ---!--- SELECTED C++ COMPILER: cl -DWIN32 -O -GX -GR -MD checking for fl32... no checking for f77... f77 checking for iostream.h... no ** Cannot find include files for C++ run time library. Please add ** the relevant directory to the TOPINCLUDES macro in the Makefile(s) FORTRAN needs ---!--- Ok, and you need to set TOPINCLUDES to point to /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++ it seems? Or perhaps this one will go away if you can get configure to choose gcc instead of cl. 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/
[ANNOUNCEMENT] New package: libgii1-1.0.0-1 (and 2 subpackages)
The following packages have recently been added to the Cygwin net release: libgii1-1.0.0-1 libgii1-devel-1.0.0-1 libgii1-input-x-1.0.0-1 LibGII is a "General Input Interface" and is primarily the input layer for LibGGI, the "General Graphics Interface". The main purpose of this LibGII release is to accompany our LibGGI release, but you're still very welcome to use LibGII as a standalone library for your non-LibGGI applications. libgii1 contains the core libraries and various input modules that do not have any extra dependencies. libgii1-input-x contains the X11 input module, and is provided in a separeat package to please those with non-X11 setups. libgii1-devel contains everything needed to develop for LibGII. Cheers, Peter *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: glut, OpenGL, undefined reference to glutCheckLoop()
On 16 February 2006 22:10, Dean C. Tsai wrote: > I went to Fletcher's site and found some files (glut32.dll, glut32.lib, and > glut.h) but frankly I have no clues if I can use them, or I should put them > if I can use those files. I remember reading that applications must be > re-compiled in Cygwin, does that mean that those files are useless for me? > Can someone please shine some lights on me? If they're win32 versions, they won't be any use with cygwin, but if they're cygwin versions, they will be. That's a general principle. For precise details about the files on Fletcher's site, see Fletcher's site. 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: cygpath problem
On Feb 17 00:23, Hans Horn wrote: > Folks, > > according to the cygpath manpage, I should get the following, given a short > DOS name, e.g. c:\Progra~1: > > cygpath -wl C:\Progra~1--> C:\Program Files > cygpath -ml C:\Progra~1--> C:/Program Files > > however, the -m option completely ignores the '-l' flag, and I get instead > cygpath -ml C:\Progra~1--> C:/Progra~1 > cygpath -m C:\Progra~1--> C:/Progra~1 > > Which is "right", cygpath or its manpage? The manpage. I fixed cygpath to do the "right thing(tm)". Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 'top' command always reports 0.0% cpu usage
On Feb 16 15:56, Manuel Gonzalez Montoya wrote: > All, > > I just installed the lastest cygwin version on an XP Professional > SP2 machine and noticed the output of the top command always reports > wrong info (0.0%) about the CPU usage summary [...] That's a small bug in top. A new version should be available soon. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: CPAN: issues with homedirs containing spaces; how to install globally?
On Fri, Feb 17, 2006 at 02:32:22AM -0500, [EMAIL PROTECTED] wrote: > Hi all, I think there's a bug with cpan and names containing spaces. Please report bugs in CPAN.pm to [EMAIL PROTECTED] This isn't unique to cygwin. I suggest you remove the space. -- 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: Permissions problem - odd setup
Andrew DeFaria wrote: I have a somewhat odd setup here and am having a permissions problem with my userid and authentication. In general I'm trying to have one home directory that is shared between Windows and Linux. On Windows I use Cygwin. Normally this involves mounting my Windows oriented home directory and proper generation of my domain userid in /etc/passwd. Here things are a bit different. My home directory here is on a Linux box running Samba. I login as \defaria on my Windows box. I have generated my /etc/password entry with mkpasswd -d -u defaria > /etc/passwd. However the Linux box running Samba does not participate in a domain rather it is using a workgroup. The symptoms that I see are as follows: While I can create a file in my home directory I cannot edit it - access denied: $ cp opts.cfg opts.cfg.new cp: cannot create regular file `opts.cfg.new': Permission denied $ ls -l opts.cfg* -rw-rw-r-- 1 98 Feb 14 11:17 opts.cfg -rwxr--r-- 1 0 Feb 15 16:01 opts.cfg.new* You'll note that the uid and gid is not correct. I suspect the problem is that /etc/passwd has my domain SID yet my home directory is on a samba server that is not in the domain. Is there any way to configure this properly? If so how? Thanks. Nobody has any ideas?!? -- 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: glut, OpenGL, undefined reference to glutCheckLoop()
On Fri, 17 Feb 2006, Dave Korn wrote: > On 16 February 2006 22:10, Dean C. Tsai wrote: > > I went to Fletcher's site and found some files (glut32.dll, glut32.lib, and > > glut.h) but frankly I have no clues if I can use them, or I should put them > > if I can use those files. I remember reading that applications must be > > re-compiled in Cygwin, does that mean that those files are useless for me? > > Can someone please shine some lights on me? > > If they're win32 versions, they won't be any use with cygwin, but if > they're cygwin versions, they will be. I'm afraid I have to disagree here, Dave. IIRC, Cygwin's glut32.dll is a win32 version built with Microsoft tools. Oh yes..., from /usr/share/doc/Cygwin/opengl-1.1.0-7.README: To build GLUT: In /usr/src/opengl-1.1.0-7/glut-3.7.6 , open glut.dsw with Visual C++ and build the glut32 project. I know no reason why those libraries shouldn't work. Link with their glut32.lib (or, rename it to libglut32.a if you want to be more Cygwin like), and arrange for their glut32.dll to be found before Cygwin's in your PATH at run time. But, if you do this, please do not expect this mailing list to support any further problems. We do not support things not distributed in the Cygwin release. > That's a general principle. Again I disagree, Dave. The general principle is that win32 libraries can be used in Cygwin as long as they are not C++, and you don't mix things like msvcrt stdio with newlib's. Maybe you are confusing trying to do this under X11? Or, your just being a Cygwin purist ;-). -- Brian Ford Lead Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot... -- 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: cygheap base mismatch detected
Dave Korn writes: > Right, thanks for giving us something we can actually get our teeth into... > it would really have been helpful to bring out some of this information a bit > earlier in the thread, like in the very first post for instance, but better > late than never! Sorry I didn't send concrete info earlier. I was trying at first to get more info on possible causes so I could set up my own diagnostics and collect more meaningful information. Didn't want to clutter my message with detail until I was sure the details were relevant. Had I misunderstood or missed something, I could have flooded you with details that were way off track. > > My app includes a lot of DLLs. I used cygcheck to get the list, > > and summed up their sizes. The total code size on disk before > > loading of the app plus the DLLs is just over 115 Mb, leaving > > over 1420 Mb to be taken up by static and dynamic memory. > > I still don't think the app uses more than a couple of Mb of > > static memory, and the problem occurs before anything dynamic > > can be allocated. What am I overlooking? > > Hmm, what kind of DLLs? Any of these your own custom builds? In particular > do some of them have base addresses still set to the default 0x1000? If > so, the first one that gets loaded into memory is going to frag the address > map into two chunks, which is bound to impact the size of contiguous heap > chunk that can be allocated. Have you looked into 'rebaseall' yet? There's > also the windows boot.ini /3GB switch to investigate, but I remember there > having been some kind of limitation on that in the past; I'm afraid I can't > remember what the problem was nor if it still applies. Not our own custom builds. Our own libs are statically linked. I've attached the cygcheck results below. The DLLs are from four sources: CygWin 1.5.19 -- installed as downloaded ICU 3.4 -- built from source under CygWin Xerces-c 2.7.0 -- built from source under CygWin Oracle 9.2.0 -- installed from a download for native Windows 2003 Oracle contributes dozens of DLLs. An executable built with CygWin, ICU, and Xerces executes properly. But it's a much smaller executable, too. I am in the process of trying to see if I can get anything more than circumstantial evidence to implicate Oracle. Also trying to build with statically linked Oracle libs to see if that works. Any other tests I should be doing? I'm not enough of a Windows guru to really know how to look at this sort of thing with Windows tools and understanding. If there are tools that let you see the loading properties of a DLL, I haven't learned them and my IT guys haven't let me in on them. Is it worth my sending you the link map? I think we've managed to narrow the causes to two possibilities: * Static memory conflicts arising from fragmentation or something else. The app in question is known to take up a lot of code space itself, and Oracle contributes a lot of DLLs. Either could be a factor. * Something nobody has thought of yet. This one scares me. -- Jens Dill Endeavor Information Systems $ cygcheck ./acqjob.exe .\acqjob.exe d:\oracle\app\oracle\product\9.2.0\bin\orasql9.dll d:\oracle\app\oracle\product\9.2.0\bin\oracore9.dll d:\oracle\app\oracle\product\9.2.0\bin\oranls9.dll d:\oracle\app\oracle\product\9.2.0\bin\oraunls9.dll C:\WINDOWS\system32\MSVCRT.dll C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\WSOCK32.dll C:\WINDOWS\system32\WS2_32.dll C:\WINDOWS\system32\ADVAPI32.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\WS2HELP.dll C:\WINDOWS\system32\ole32.dll C:\WINDOWS\system32\GDI32.dll C:\WINDOWS\system32\USER32.dll C:\WINDOWS\system32\WINMM.dll d:\oracle\app\oracle\product\9.2.0\bin\oraclient9.dll d:\oracle\app\oracle\product\9.2.0\bin\oravsn9.dll d:\oracle\app\oracle\product\9.2.0\bin\oracommon9.dll d:\oracle\app\oracle\product\9.2.0\bin\orageneric9.dll d:\oracle\app\oracle\product\9.2.0\bin\oraxml9.dll C:\WINDOWS\system32\MSVCIRT.dll d:\oracle\app\oracle\product\9.2.0\bin\oraxsd9.dll d:\oracle\app\oracle\product\9.2.0\bin\oran9.dll d:\oracle\app\oracle\product\9.2.0\bin\oranl9.dll d:\oracle\app\oracle\product\9.2.0\bin\oranldap9.dll d:\oracle\app\oracle\product\9.2.0\bin\orannzsbb9.dll d:\oracle\app\oracle\product\9.2.0\bin\oraldapclnt9.dll d:\oracle\app\oracle\product\9.2.0\bin\orancrypt9.dll C:\WINDOWS\system32\OLEAUT32.dll d:\oracle\app\oracle\product\9.2.0\bin\ORATRACE9.dll d:\oracle\app\oracle\product\9.2.0\bin\oranro9.dll d:\oracle\app\oracle\product\9.2.0\bin\oranhost9.dll
"have you looked into rebaseall?"
In another context, Dave Korn writes: > Have you looked into 'rebaseall' yet? My reaction: o Don't know about that, let's look it up. o Try "man rebaseall" in CygWin shell. No luck. o Try searching Windows 2003 Help. No luck. o Google search turns up people who are complaining about using it or announcing changes to it. o Now clear that it is a CygWin package distributed as "rebase" o Verified that "rebase 2.4.2-1" is installed on my box. o Try "man rebase" in CygWin shell. No luck. o Try looking in online CygWin UG: Not mentioned in the TOC. o Download PDF of user's guide and search for "rebase" and "rebaseall". No hits? o Can't find a "search this site" button on the CygWin web site. Could have sworn there was one. o "rebase --help" produces a one-liner just describing the argument syntax without explanation. o "rebaseall --help" produces a couple of sentences telling me to shut down things before using it, but again, not what it's used for. I'd like to look into this, but how? -- Jens Dill -- 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 logfile do not find iostream fopen no such file or directory
On Fri, 17 Feb 2006, Elin Aronsen wrote: > Actually, I started out on my laptop and I have not done more than > installing cygwin. But cygwin logfile complains about not finding > fopen: no such file or directory, please see attached cygcheck and > logfile. What can the reason be ? FYI, you have just sent 1.5M of stuff to about 1000 people. And it was all in vain, since the message you are asking about is harmless, and has been fixed in the latest setup snapshots. In the future, it's best to not attach setup logs unless they are requested, and even in that case, attach them in compressed form. This doesn't apply to the cygcheck output, of course, which should be sent as an uncompressed text attachment. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte." "But no -- you are no fool; you call yourself a fool, there's proof enough in that!" -- Rostand, "Cyrano de Bergerac" -- 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: Big thanks to Corinna and Chris
"Corinna Vinschen" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] [snip] > Thanks, nice to read somebody is happy with Cygwin :-) [snip] Also I am happy with Cygwin. -- Alex Vinokur email: alex DOT vinokur AT gmail DOT com http://mathforum.org/library/view/10978.html http://sourceforge.net/users/alexvn -- 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: Big thanks to Corinna and Chris
On 17 February 2006 18:45, Alex Vinokur wrote: > "Corinna Vinschen" wrote in message > news:[EMAIL PROTECTED] > > [snip] >> Thanks, nice to read somebody is happy with Cygwin :-) [snip] > > Also I am happy with Cygwin. > No! *I* am Spartacus! 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: "have you looked into rebaseall?"
On 17 February 2006 17:54, Dill, Jens (END-CHI) wrote: > In another context, Dave Korn writes: > >> Have you looked into 'rebaseall' yet? > > My reaction: > > o Don't know about that, let's look it up. > > o Try "man rebaseall" in CygWin shell. No luck. Just FYI, some things have info pages but no man pages. Any time you try "man XXX" and it doesn't work, it's always worth trying "info XXX" as well. > o Try searching Windows 2003 Help. No luck. > > o Google search turns up people who are complaining > about using it or announcing changes to it. > > o Now clear that it is a CygWin package distributed > as "rebase" > > o Verified that "rebase 2.4.2-1" is installed on my box. > > o Try "man rebase" in CygWin shell. No luck. > > o Try looking in online CygWin UG: Not mentioned > in the TOC. > > o Download PDF of user's guide and search for "rebase" > and "rebaseall". No hits? > > o Can't find a "search this site" button on the CygWin > web site. Could have sworn there was one. The mailing list archives have a search form, but the rest of the site doesn't. By far the best way to search it is to go to google, and add "site:cygwin.com" to whatever other search terms you want. > o "rebase --help" produces a one-liner just describing > the argument syntax without explanation. > > o "rebaseall --help" produces a couple of sentences > telling me to shut down things before using it, > but again, not what it's used for. > > I'd like to look into this, but how? Heh, excellent work. Can't fault you there. It's in the cygwin-specific documentation dir, /usr/share/doc/Cygwin. It's called "rebase-2.4.2.README" (unless I missed an update recently). Start at the bit that reads " The rebaseall utility is a convenient way for users that suffer from the Cygwin rebase problem to rebase their entire system (i.e., all of their DLLs) ..." And as you mentioned Oracle in your last post and how many hundreds of dlls it has, they're almost certainly spread out across the address map. Rebaseall will let you shuffle all your dlls up to (nearly) contiguous mappings at the top end of user space, hopefully giving you the maximum clear area in the middle. Good luck! " * Static memory conflicts arising from fragmentation or something else. The app in question is known to take up a lot of code space itself, and Oracle contributes a lot of DLLs. Either could be a factor. " Absolutely so. I reckon doing a proper rebaseall that includes the oracle dlls should make a noticeable difference. 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: "have you looked into rebaseall?"
On Fri, Feb 17, 2006 at 07:01:29PM -, Dave Korn wrote: >On 17 February 2006 17:54, Dill, Jens (END-CHI) wrote: > >> In another context, Dave Korn writes: >> >>> Have you looked into 'rebaseall' yet? >> >> My reaction: >> >> o Don't know about that, let's look it up. >> >> o Try "man rebaseall" in CygWin shell. No luck. > > Just FYI, some things have info pages but no man pages. Any time you try >"man XXX" and it doesn't work, it's always worth trying "info XXX" as well. > >> o Try searching Windows 2003 Help. No luck. >> >> o Google search turns up people who are complaining >> about using it or announcing changes to it. >> >> o Now clear that it is a CygWin package distributed >> as "rebase" >> >> o Verified that "rebase 2.4.2-1" is installed on my box. >> >> o Try "man rebase" in CygWin shell. No luck. >> >> o Try looking in online CygWin UG: Not mentioned >> in the TOC. >> >> o Download PDF of user's guide and search for "rebase" >> and "rebaseall". No hits? >> >> o Can't find a "search this site" button on the CygWin >> web site. Could have sworn there was one. > > The mailing list archives have a search form, but the rest of the site >doesn't. > > By far the best way to search it is to go to google, and add >"site:cygwin.com" to whatever other search terms you want. > >> o "rebase --help" produces a one-liner just describing >> the argument syntax without explanation. >> >> o "rebaseall --help" produces a couple of sentences >> telling me to shut down things before using it, >> but again, not what it's used for. >> >> I'd like to look into this, but how? > > >Heh, excellent work. Can't fault you there. Well, I can sort of fault that you'd take five steps to come to the conclusion that a program suggested in the Cygwin mailing list was actually a Cygwin program, i.e., http://cygwin.com/packages/ . I'd also fault the notion that every single program mentioned in the context of Cygwin would be mentioned in the Cygwin "UG". However, >It's in the cygwin-specific documentation dir, /usr/share/doc/Cygwin. >It's called "rebase-2.4.2.README" (unless I missed an update recently). >Start at the bit that reads i.e., http://cygwin.com/faq/faq-nochunks.html#faq.resources.documentation I am sort of surprised that rebaseall isn't mentioned in the FAQ however. 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: "have you looked into rebaseall?"
Dave Korn wrote: > Absolutely so. I reckon doing a proper rebaseall that includes the oracle > dlls should make a noticeable difference. This is important. The rebaseall script only knows about DLLs installed via setup.exe. So, you will need to provide a list of any additional DLLs that you want rebased, with the -T argument. I haven't been following this thread all that closely, but are we talking about allocating a single large contiguous memory region? Because if you try to allocate it all at once then the DLL layout will matter, but if it's done as a series of smaller allocations then this should be irrelevant. Brian -- 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: "have you looked into rebaseall?"
On 17 February 2006 19:21, Brian Dessent wrote: > Dave Korn wrote: > >> Absolutely so. I reckon doing a proper rebaseall that includes the >> oracle dlls should make a noticeable difference. > > This is important. The rebaseall script only knows about DLLs installed > via setup.exe. So, you will need to provide a list of any additional > DLLs that you want rebased, with the -T argument. Sorry for not being clearer, yes, that's exactly what I meant by 'proper' and 'includes the oracle dlls', but I didn't go lookup the exact syntax. > I haven't been following this thread all that closely, but are we > talking about allocating a single large contiguous memory region? Say, Brian, you are ponderin' what we've been ponderin'! ;-) > Because if you try to allocate it all at once then the DLL layout will > matter, but if it's done as a series of smaller allocations then this > should be irrelevant. Yep, it's the old huge-contiguous-allocation problem again. 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: regular user, bash cannot find /tmp
Apologies for the incomplete posting. Here are two output files: The first is output from 'cygcheck -s -v -r', the second is the error message from cygcheck. History: I want to run 'octave' and tried a package containing a partial cygwin environment and octave 2.1.42. Discovered that it is too old and removed it. Installed cygwin (downloaded this week). Could there be traces of the previous octave/cygwin package left on the system? Thanks. On Thu, 16 Feb 2006, Claude Marinier wrote: I installed cygwin on MS Windows XP from files I downloaded earlier this week (13 or 14 Feb 2006). Picked the default option to make cygwin available for all users. I installed from an account with Administrator privileges. Usually, the first time I start cygwin, it recommends running mkpasswd and mkgroup. This time it did not, so I performed those two steps by hand (with the local option since the PC is not part of a domain). Everything works fine from the Administrator account. From a regular account (in Power User group), bash startup fails with the following error message. bash.exe: warning: could not find /tmp, please create! Made sure /tmp exists and is accessible. Made sure the user's home directory exists and is accessible. It looks like the port-installation failed or initialisation failed. -- Claude Marinier, Information Technology Defence Research & Development Canada (Ottawa) [EMAIL PROTECTED] http://www.ottawa.drdc-rddc.gc.ca Telephone: (613) 998-4901 Cygwin Configuration Diagnostics Current System Time: Fri Feb 17 04:03:26 2006 Windows XP Professional Ver 5.1 Build 2600 Service Pack 2 Path: F:\Tcl\bin F:\watcom\BINNT F:\watcom\BINW C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\system32\WBEM C:\Program Files\Common Files\Adaptec Shared\System C:\Util C:\Program Files\ATI Technologies\ATI Control Panel C:\Util Output from F:\cygwin\bin\id.exe (nontsec) UID: 400(Claude) GID: 401(mkpasswd) 401(mkpasswd) Output from F:\cygwin\bin\id.exe (ntsec) UID: 400(Claude) GID: 401(mkpasswd) 401(mkpasswd) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS Path = 'F:\Tcl\bin;F:\watcom\BINNT;F:\watcom\BINW;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\WBEM;C:\Program Files\Common Files\Adaptec Shared\System;C:\Util;C:\Program Files\ATI Technologies\ATI Control Panel;C:\Util' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users' APPDATA = 'C:\Documents and Settings\Claude\Application Data' CommonProgramFiles = 'C:\Program Files\Common Files' COMPUTERNAME = 'WOLF' ComSpec = 'C:\WINDOWS\system32\cmd.exe' EDITOR = 'C:\Util\MetaPad\metapad' FP_NO_HOST_CHECK = 'NO' HOMEDRIVE = 'C:' HOMEPATH = '\Documents and Settings\Claude' LOGONSERVER = '\\WOLF' NUMBER_OF_PROCESSORS = '1' OS = 'Windows_NT' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.tcl;.CH' PROCESSOR_ARCHITECTURE = 'x86' PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 8 Stepping 1, AuthenticAMD' PROCESSOR_LEVEL = '6' PROCESSOR_REVISION = '0801' ProgramFiles = 'C:\Program Files' PROMPT = '$P$G' SESSIONNAME = 'Console' SystemDrive = 'C:' SystemRoot = 'C:\WINDOWS' TEMP = 'C:\DOCUME~1\Claude\LOCALS~1\Temp' TMP = 'C:\DOCUME~1\Claude\LOCALS~1\Temp' TZ = 'EST' USERDOMAIN = 'WOLF' USERNAME = 'Claude' USERPROFILE = 'C:\Documents and Settings\Claude' WATCOM = 'F:\watcom' windir = 'C:\WINDOWS' XDSDIR = 'C:\XDS' POSIXLY_CORRECT = '1' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 (default) = '/cygdrive' cygdrive flags = 0x0022 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/ (default) = 'C:\util\cygwin' flags = 0x0002 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = 'C:\util\cygwin/bin' flags = 0x0002 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = 'C:\util\cygwin/lib' flags = 0x0002 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\00 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\01 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\02 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\03 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\04 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\05 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\06 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\07 HKEY_C
Re: [ANNOUNCEMENT] Updated: WordNet-2.1
"Dr. Volker Zell" <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: > Hi > > A new version of 'WordNet' has been uploaded to a server near you. > This has defied my Googling Powers. But I have found out a few things You call it from the command line as wn (not wordnet) > wn > man wn The online interface is very useful at http://wordnet.princeton.edu/perl/webwn But further have I got NOT. Could the literati , cognoscenti or any other well disposed Cygwin glitterati please advise? I have found much documentation but not a single example Ha! Sussed it, you put the parameters AFTER the word eg $ wn philosophy -over Overview of noun philosophy The noun philosophy has 3 senses (first 3 from tagged texts) 1. (12) doctrine, philosophy, philosophical system, school of thought, ism -- (a belief (or system of beliefs) accepted as authoritative by some group or school ) 2. (8) philosophy -- (the rational investigation of questions about existence an d knowledge and ethics) 3. (1) philosophy -- (any personal belief about how to live or how to deal with a situation; "self-indulgence was his only philosophy"; "my father's philosophy of child-rearing was to let mother do it") A super tool thanks to those involved!!! -- zzapper Success for Techies http://SuccessTheory.com/ vim, zsh & success tips -- 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: _kbhit
Gary R. Van Sickle wrote: > Arend-Jan Westhoff writes: I cannot confirm your assertion that msvcrt.dll and cygwin1.dll cannot be used together. The Gary Exclusion Principle: Two C runtimes cannot occupy the same point in space at the same moment in time. The problem here is that unfortunately they *can* occupy the same point in space at the same time, with the same bad effects as in science fiction movies when one object materializes in the middle of another :-). The problem is that, for instance, some of your malloc calls will link to the cygwin libc, while others (from within the Windows DLLs) will link to MSVCRT, and if you free the pointer with the "other" library, terrible things will happen. -- 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: _kbhit
On Fri, Feb 17, 2006 at 12:27:52PM -0800, Shankar Unni wrote: >Gary R. Van Sickle wrote: >>Arend-Jan Westhoff writes: >>>I cannot confirm your assertion that msvcrt.dll and cygwin1.dll cannot >>>be used together. > >>The Gary Exclusion Principle: Two C runtimes cannot occupy the same >>point in space at the same moment in time. > >The problem here is that unfortunately they *can* occupy the same point >in space at the same time, with the same bad effects as in science >fiction movies when one object materializes in the middle of another >:-). > >The problem is that, for instance, some of your malloc calls will link >to the cygwin libc, while others (from within the Windows DLLs) will >link to MSVCRT, and if you free the pointer with the "other" library, >terrible things will happen. Details, details. The bottom line comes down to sheer will. If someone really wants _kbhit then, with enough reinstalls, and email messages stating that fact, it will surely happen regardless of runtimes or exclusionary principles. Human spirit and indomitable determination trumps all! 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/
Apache2 Threads
The 'worker' MPM for Apache2 uses threads. According to its docs: By using threads to serve requests, it is able to serve a large number of requests with less system resources than a process-based server. Yet it retains much of the stability of a process-based server by keeping multiple processes available, each with many threads. Since it uses less resources, I would recommend that we use that model under Cygwin. -- 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: Apache2 Threads
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jerry D. Hedden wrote: > The 'worker' MPM for Apache2 uses threads. According to its > docs: By using threads to serve requests, it is able to > serve a large number of requests with less system resources > than a process-based server. Yet it retains much of the > stability of a process-based server by keeping multiple > processes available, each with many threads. > > Since it uses less resources, I would recommend that we use > that model under Cygwin. Unsubstantiated suggestions are not at all helpful. The last time I experimented with worker on cygwin, it failed to perform reliably at all - far less than 50% of requests were served successfully. Now, if you feel like testing and reporting back whether the situation has changed, _that_ would be helpful. (You'd also have to recompile APR with threading support - that's disabled in its configure script as supposedly being unreliable on Cygwin.) Max. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) iD8DBQFD9j3bfFNSmcDyxYARAgEfAKC1Ez66P8reN2qUZ4dzUDcf+Nxm4wCfe55q onmEk00GUvTS5Ek7Hlt0SCs= =tOoo -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: cygheap base mismatch detected
Dave Korn wrote >On 17 February 2006 19:21, Brian Dessent wrote: > >> Dave Korn wrote: >> >>> Absolutely so. I reckon doing a proper rebaseall that includes the >>> oracle dlls should make a noticeable difference. >> >> This is important. The rebaseall script only knows about DLLs installed >> via setup.exe. So, you will need to provide a list of any additional >> DLLs that you want rebased, with the -T argument. > > Sorry for not being clearer, yes, that's exactly what I meant by 'proper' > and 'includes the oracle dlls', but I didn't go lookup the exact syntax. > >> I haven't been following this thread all that closely, but are we >> talking about allocating a single large contiguous memory region? > > Say, Brian, you are ponderin' what we've been ponderin'! ;-) > > >> Because if you try to allocate it all at once then the DLL layout will >> matter, but if it's done as a series of smaller allocations then this >> should be irrelevant. > > Yep, it's the old huge-contiguous-allocation problem again. > > >cheers, > DaveK I'd be a fool if I hadn't looked at that early on. My test scripts for large contiguous allocations have all shown that I can allocate 1.5 GB with a minimal program and no DLLs. With the two dozen or so DLLs and my full app, I expect to use up to 120 Mb of memory for code. Fragment that as you will, in 1536 Mb, you still leave space for decent sized allocations. I know of no part of my app that allocates anywhere near even 1 Mb of static space contiguously. Dynamic allocation is not a concern, since the program never gets to the point of starting execution. And I can say the same for dynamic allocation anyway. If we relied on huge contiguous allocations, we wouldn't have an app that ran anywhere. I did try rebaseall. It told me all the Oracle DLLs were not rebaseable. The -v output is included below. Interestingly enough, the app does run from a Windows CMD window. It's just that it is configured to be launched from a Korn shell script, and one of our *reasons* for choosing CygWin was that we would not have to rewrite our launch scripts as .bat files. The app fails when launched from either bash or ksh, either by exec or as a child process. It launches fine from Windows CMD but dies because it doesn't have the proper environment. So it seems you were right about the relationship of the addresses of the CygWin DLL in the parent (shell) and child (app). Could I "fix" the problem by providing a stripped-down app that links all the DLLs and and all the same static libraries, but does nothing but launch a shell, which can then be used to launch the real app? -- Jens /usr/bin/tclpip84.dll: skipped because not rebaseable /usr/share/terminfo/a/ansi+sgrso: skipped because not rebaseable /usr/share/terminfo/c/cons60-iso: skipped because not rebaseable /usr/share/terminfo/x/xterm-boldso: skipped because not rebaseable /usr/share/xemacs/xemacs-packages/etc/psgml-dtds/ISO_8879-1986/entities/ISOa mso: skipped because not rebaseable /cygdrive/d/oracle/app/oracle/product/9.2.0/bin/orasql9.dll: skipped because not rebaseable /cygdrive/d/oracle/app/oracle/product/9.2.0/bin/oracore9.dll: skipped because not rebaseable /cygdrive/d/oracle/app/oracle/product/9.2.0/bin/oranls9.dll: skipped because not rebaseable /cygdrive/d/oracle/app/oracle/product/9.2.0/bin/oraunls9.dll: skipped because not rebaseable /cygdrive/c/WINDOWS/system32/MSVCRT.dll: skipped because not rebaseable /cygdrive/c/WINDOWS/system32/KERNEL32.dll: skipped because not rebaseable /cygdrive/c/WINDOWS/system32/ntdll.dll: skipped because not rebaseable /cygdrive/c/WINDOWS/system32/WSOCK32.dll: skipped because not rebaseable /cygdrive/c/WINDOWS/system32/WS2_32.dll: skipped because not rebaseable /cygdrive/c/WINDOWS/system32/ADVAPI32.dll: skipped because not rebaseable /cygdrive/c/WINDOWS/system32/RPCRT4.dll: skipped because not rebaseable /cygdrive/c/WINDOWS/system32/WS2HELP.dll: skipped because not rebaseable /cygdrive/c/WINDOWS/system32/ole32.dll: skipped because not rebaseable /cygdrive/c/WINDOWS/system32/GDI32.dll: skipped because not rebaseable /cygdrive/c/WINDOWS/system32/USER32.dll: skipped because not rebaseable /cygdrive/c/WINDOWS/system32/WINMM.dll: skipped because not rebaseable /cygdrive/d/oracle/app/oracle/product/9.2.0/bin/oraclient9.dll: skipped because not rebaseable /cygdrive/d/oracle/app/oracle/product/9.2.0/bin/oravsn9.dll: skipped because not rebaseable /cygdrive/d/oracle/app/oracle/product/9.2.0/bin/oracommon9.dll: skipped because not rebaseable /cygdrive/d/oracle/app/oracle/product/9.2.0/bin/orageneric9.dll: skipped because not rebaseable /cygdrive/d/oracle/app/oracle/product/9.2.0/bin/oraxml9.dll: skipped because not rebaseable /cygdrive/c/WINDOWS/system32/MSVCIRT.dll: skipped because not rebaseable /cygdrive/d/oracle/app/oracle/product/9.2.0/bin/oraxsd9.dll: skipped because not rebaseable /cygdrive/d/oracle/app/oracle/product/9.2.0/bin/oran9.dll
RE: cygheap base mismatch detected
I wrote: > Could I > "fix" the problem by providing a stripped-down app that links all > the DLLs and and all the same static libraries, but does nothing > but launch a shell, which can then be used to launch the real app? Nope, didn't work. Got the same message: 2 [main] ? (-5768) d:\m1\voyagerdev\2006.1\bin\acqjob.exe: *** fatal error - cygheap base mismatch detected - 0x6115B900/0x36B900. is problem is probably due to using incompatible versions of the cygwin DLL. arch for cygwin1.dll using the Windows Start->Find/Search facility d delete all but the most recent version. The most recent version *should* side in x:\cygwin\bin, where 'x' is the drive on which you have stalled the cygwin distribution. Rebooting is also suggested if you e unable to find another cygwin DLL. Cheers, -- Jens -- 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/
rsync fork/exec problem with odd twist for native windows programs
I've found an rsync problem that might be another data point for the
fork() (or exec()?) problems mentioned on the cygwin mailing list last
fall. On one of my systems rsync hangs after it forks a cygwin program.
Surprisingly, when it forks some native windows program, it completes.
I started this investigation when rsync spawning ssh hung. By using the
-vv verbose option I could tell that rsync was starting ssh. However, a
netstat on the remote host did not show any connection. Btw, when I call
ssh directly it works just fine.
Normally rsync executes (ssh remote_host rsync ...) to transfer files.
The -e option allows an arbitrary command to be executed instead. As a
test case I replaced ssh with a command that exits immediately; namely
true.exe.
On a Windows XP system where rsync is working I ran (rsync -vv -e
/bin/true.exe file1 host:file2). It forks and exec's true.exe which then
exits without generating any of the expected rsync protocol traffic.
The local rsync program complains and exits. That's what I would expect.
On my problem XP system, the same rsync command simply hangs. I've used
strace and the task manager to confirm that true.exe really is started.
See below for an excerpt from the strace log.
Now the story gets odd. I used the following source to create a native
windows program that does nothing:
/*
* sample code from http://www.mingw.org/docs.shtml
*
* compile with (gcc -o hello hello.c -mwindows)
*/
#include
int WINAPI WinMain (HINSTANCE hInstance,
HINSTANCE hPrevInstance,
PSTR szCmdLine,
int iCmdShow)
{
MessageBox (NULL, "Hello", "Hello Demo", MB_OK);
return (0);
}
When I run (rsync -vv -e hello.exe ...) the Hello Demo message box comes
up, and when I dismiss it hello.exe exits and rsync complains because it
did not see the traffic it expected. At first I speculated that meant
cygwin programs were hanging and native windows programs worked.
However, in an odd twist, when I commented out the MessageBox() line to
turn the program into a noop, the same hanging behavior occurred. That
screwed up my speculation.
As recommended in an earlier fork() email thread I ran rebaseall. That
did not help. The problem system is a new install of XP. The system is
completely idle. I tried this both in a Windows cmd window running tcsh
as well as in an xterm.
I don't know what to try next. Does anyone have a suggestion?
Scott
P.S. Below is an excerpt from the strace output. I grabbed the lines
starting where true.exe was spawned going to where it hung until I
killed true.exe with the task manager.
% strace rsync -vv -e /bin/true.exe a crag:/tmp
142 1886268 [main] rsync 604 spawn_guts: 604 = spawn_guts (/bin/true.exe,
C:\cygwin\bin\true.exe crag rsync --server -vv . /tmp)
109273 1995541 [main] rsync 604! fhandler_socket::close: 0 =
fhandler_socket::close()
51304 2046845 [main] rsync 604! fhandler_socket::close: 0 =
fhandler_socket::close()
249 2047094 [main] rsync 604! fhandler_base::close: closing '' handle 0x71C
108 2047202 [main] rsync 604! spawn_guts: new process name
C:\cygwin\bin\true.exe
424 2047626 [main] rsync 604! _pinfo::dup_proc_pipe: closed wr_proc_pipe
0x7F4 for pid 604(1300)
34011 2081637 [main] rsync 604! spawn_guts: spawned windows pid 1300
213 2081850 [main] rsync 604! child_info::sync: n 2, waiting for
subproc_ready(0x7F0) and child process(0x630)
**
Program name: C:\cygwin\bin\true.exe (pid 604, ppid 2044)
App version: 1005.19, api: 0.150
DLL version: 1005.19, api: 0.150
DLL build:2006-01-20 13:28
OS version: Windows NT-5.1
Heap size:402653184
Date/Time:2006-02-17 16:32:17
**
1071868 [main] true 604 set_myself: myself->dwProcessId 1300
4082276 [main] true 604 open_shared: name Global\cygwin1S4.cygpid.1300, n
1300, shared 0x3D (wanted 0x0), h 0x79C
9523228 [main] true 604 time: 1140215537 = time (0)
49532 2131382 [main] rsync 604! child_info::sync: process 604 synchronized,
WFMO returned 0
210 2131592 [main] rsync 604! pinfo::maybe_set_exit_code_from_windows: pid
604, exit value - old 0x0, windows 0xDEADBEEF, cygwin 0x0
100 2131692 [main] rsync 604! sigproc_terminate: entering
89 2131781 [main] rsync 604! sig_send: sendsig 0x57C, pid 604, signal -42,
its_me 1
109 2131890 [main] rsync 604! sig_send: Not waiting for sigcomplete. its_me
1 signal -42
88 2131978 [main] rsync 604! sig_send: returning 0x0 from sending signal -42
84 2132062 [main] rsync 604! proc_terminate: nprocs 0
82 2132144 [main] rsync 604! proc_terminate: leaving
10194247 [main] true 604 child_info::ready: signalled 0x7F0 that I was
ready
1124359 [main] true 604 fhandler_socket::fixup_after_fork: WSASocket
Re: rsync fork/exec problem with odd twist for native windows programs
Scott, > I started this investigation when rsync spawning ssh hung. By using > the -vv verbose option I could tell that rsync was starting ssh. It is difficult to tell if this is the same or similar to the rsync hang I experienced: http://sourceware.org/ml/cygwin/2005-12/msg01096.html It seemingly hangs in the same/similar place, in my case I substituted the use of a local pipe for a local socket to resolve. > However, a netstat on the remote host did not show any connection. > Btw, when I call ssh directly it works just fine. Yes, same here. Brett Brett C. Serkez, Techie -- 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: rsync fork/exec problem with odd twist for native windows programs
Brett,
Thanks for the suggestion. Switching from socketpair() to
pipe() does let ssh get going, but rsync later runs into
problems. A few minutes into the transfer it just hangs.
Since I exercised ssh by transferring 16MB files back and
forth for 10 minutes, I'm inclined to point the finger at
rsync. However, I use the same version of rsync on another
system where it runs like a champ. That doesn't leave any
suspects.
I'm still puzzled as to why even true.exe hung. I did not
want to make my problem report even longer, but I had another
test program which was literally "int main() { exit(0) }",
just in case true.exe was not as minimal as expected. That
test program also hung when spawned by rsync.
Scott
On Fri, 17 Feb 2006 18:11:40 -0500, "Brett Serkez" wrote:
> Scott,
>
>
> > I started this investigation when rsync spawning ssh hung. By using
> > the -vv verbose option I could tell that rsync was starting ssh.
>
> It is difficult to tell if this is the same or similar to the rsync hang
> I experienced:
>
> http://sourceware.org/ml/cygwin/2005-12/msg01096.html
>
> It seemingly hangs in the same/similar place, in my case I substituted
> the use of a local pipe for a local socket to resolve.
>
> > However, a netstat on the remote host did not show any connection.
> > Btw, when I call ssh directly it works just fine.
>
> Yes, same here.
>
> Brett
>
> Brett C. Serkez, Techie
>
--
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: Updated: readline-5.1-3, libreadline6-5.1-3 - possible bug
I have key binding set to vi and now after having updated to the newest version of readline the search capability invoked by ESC followed by a / results in the prompt being displayed a few times along with the /. I have reverted to 5.0-4 for now which seems to work fine. 5.0-4 behavior: [EMAIL PROTECTED] ~ $ /mysearch typed ESC / and the search string here 5.1-3 behavior: [EMAIL PROTECTED] ~ $ typed ESC / here [EMAIL PROTECTED] ~ $ / automatically printed [EMAIL PROTECTED] ~ $ / automatically printed [EMAIL PROTECTED] ~ $ /mysearch printed when entering the first character for search 5.0-4 Regards, Paul J. Ghosh -- 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: Updated: readline-5.1-3, libreadline6-5.1-3 - possible bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul J. Ghosh on 2/17/2006 9:28 PM: > I have key binding set to vi and now after having updated to the newest > version of readline the search capability invoked by ESC followed by a / > results in the prompt being displayed a few times along with the /. I have > reverted to 5.0-4 for now which seems to work fine. > > 5.0-4 behavior: > [EMAIL PROTECTED] ~ > $ /mysearch typed ESC / and the search string here What prompt are you using ($PS1)? It makes a difference to my debugging. I don't normally use vi mode, and I thought I had just repaired this in releasing 5.1-3. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] volunteer cygwin readline maintainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD9qOy84KuGfSFAYARAv+oAKDElZl7rLksY3SFybU9Ly6eIXBpQgCeONmS n4GckKD/tWhO20mcpZg5In4= =C9Ys -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/
