On Tue, Dec 29, 2009 at 7:08 PM, Dave Korn wrote: > Take a look in /etc/postinstall. If you see lots of files named "*.sh", > then you can simply re-run setup.exe and click right through it without > changing any of the settings from last time and it will finish off running any > scripts that it didn't do last time. OTOH, if you see only lots of files > named "*.sh.done", that means it somehow didn't notice that the scripts had > failed and it won't try re-running them; in that case, you still re-run > setup.exe and click through it largely unaltered, but when you get to the > package chooser screen, select the category view and set the top category to > "reinstall".
After noticing that all files in the /etc/postinstall dir are named *.sh.done I chose your second option. This worked fine and now my /etc dir is filled correctly. But I should note that of course one has to omit the cygwin-1.7.1-1 package from the reinstall process as this will again install the DLL that has not been rebased and thus all postinstall scripts will fail again. > To a large extent, it's one of those 'can't-be-helped' things: > > - To mimic posix fork semantics, Cygwin has to recreate the exact memory map > of the parent process in the child's memory space, including the addresses at > which shared libraries (dlls) are loaded. > > - To intercept file access and check for viruses etc., BitDefender injects > dlls into every process to hook the potentially-dangerous system calls. > > - Cygwin doesn't actually have full control over how things get loaded into > memory; that's determined by the OS loader which is invoked when Cygwin calls > CreateProcess. > > - Sometimes the OS loader doesn't reload all the DLLs in the newly-created > child process at the same base addresses as they were at in the parent process > when there's a clash between two DLLs competing for the same base address. > > There are some tricks in the DLL to try and avoid and/or work around the > problem, but ultimately we're limited by the behaviour of the underlying OS > which isn't directly under our control and doesn't always do what is needed > for POSIX semantics because (after all) it was designed to implement win32 > semantics. > > Of course, this means that it's all someone else's fault and Cygwin is > perfect :-) and I'm not saying that under any kind of duress or > gravitationally-inspired threat from any kind of even-toed aquatic ungulant > whatsoever ... Thanks for your explanations. One just has to keep in mind that for every upcoming update of the cygwin1.dll one has to re-run the rebase process. Best regards, Bernd. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
