This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fwd: No go after update to 1.7.1


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]