Mail Archives: cygwin/2009/12/29/13:19:57
On Tue, Dec 29, 2009 at 7:08 PM, Dave Korn wrote:
> =A0Take a look in /etc/postinstall. =A0If 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 runnin=
g any
> scripts that it didn't do last time. =A0OTOH, if you see only lots of fil=
es
> named "*.sh.done", that means it somehow didn't notice that the scripts h=
ad
> 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.
> =A0To 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 addresse=
s 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 in=
to
> memory; that's determined by the OS loader which is invoked when Cygwin c=
alls
> 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 pr=
ocess
> when there's a clash between two DLLs competing for the same base address.
>
> =A0There are some tricks in the DLL to try and avoid and/or work around t=
he
> 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 need=
ed
> for POSIX semantics because (after all) it was designed to implement win32
> semantics.
>
> =A0Of 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 ungula=
nt
> 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
- Raw text -