X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 	tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS
X-Spam-Check-By: sourceware.org
MIME-Version: 1.0
In-Reply-To: <4B3A45B2.20506@gmail.com>
References: <6c18a4f0912251015k48ff2266l8fca37fc2543772e AT mail DOT gmail DOT com> 	 <416096c60912270956l3a82fb8fu3a62d6532dc1988a AT mail DOT gmail DOT com> 	 <6c18a4f0912271000i3c5f5ecewccf1bb77e30d88b4 AT mail DOT gmail DOT com> 	 <4B37E68C DOT 9000304 AT cygwin DOT com> 	 <20091227233155 DOT GA12367 AT ednor DOT casa DOT cgf DOT cx> 	 <6c18a4f0912280230k601eca9me32c056e09117866 AT mail DOT gmail DOT com> 	 <6c18a4f0912290754h34c5a28s31091eeb6af1cc5a AT mail DOT gmail DOT com> 	 <4B3A36D0 DOT 3030102 AT gmail DOT com> 	 <6c18a4f0912290922u7a1950b8v3974855629d779e0 AT mail DOT gmail DOT com> 	 <4B3A45B2 DOT 20506 AT gmail DOT com>
Date: Tue, 29 Dec 2009 19:19:43 +0100
Message-ID: <6c18a4f0912291019u211e9080p82bf8e8df6d4ffbe@mail.gmail.com>
Subject: Re: Fwd: No go after update to 1.7.1
From: Bernd Bartmann <bernd DOT bartmann AT gmail DOT com>
To: cygwin AT cygwin DOT com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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