Re: Fwd: No go after update to 1.7.1

[Dave Korn <dave dot korn dot cygwin at googlemail dot com>]

Bernd Bartmann wrote:

> Now how to go on to get the cygwin installation fixed? As Larry
> pointed out - because bash could not be run during the setup process
> the postinstall scripts couldn't be run.
> Shall I just reinstall all packages but the core cygwin package?

  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".

> Also, it is not entirely clear to me if cygwin or BitDefender is to
> blame for the problem. Is there work going on to address this issue
> from the cygwin side? Should I contact BitDefender about the problem?
> I would regret it if cygwin can't be installed by Joe User on a system
> that has BitDefender 2010 installed as well.

  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 ...

    cheers,
      DaveK


--
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