Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Message-ID:	<3C1164C8.AF785AAC@ece.gatech.edu>
Date:	Fri, 07 Dec 2001 19:54:32 -0500
From:	Charles Wilson <cwilson AT ece DOT gatech DOT edu>
X-Mailer:	Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language:	en
MIME-Version:	1.0
To:	Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
CC:	Jason Tishler <jason AT tishler DOT net>, Michael Hudson <mwh AT python DOT net>,
	david_abrahams AT users DOT sourceforge DOT net, Cygwin <cygwin AT sources DOT redhat DOT com>
Subject:	Re: dll_list::load_after_fork() blues (was Re: [ python-Bugs-489709 ]
	Building Fails ...)
References:	<20011206124426 DOT B1448 AT dothill DOT com> <3C0FB399 DOT 2020300 AT ece DOT gatech DOT edu> <01fc01c17f74$0d774a20$0200a8c0 AT lifelesswks>
X-Virus-Scanned:	by amavisd-milter (http://amavis.org/)

Robert Collins wrote:

> > Part of the problem may be that cyggdbm.dll was built with
> > --auto-image-base.  It was later demonstrated that this can cause
> > problems with fork; you're better off just letting ld assign the
> default
> > dllbase, which means that EVERY process will remap the dll at runtime.
> > Thus, no hardcoded conflicts.  Downside: *very* slightly delay in
> > loading DLLs -- probably unnoticeable.
> >
> > (Did I get that right, robert?)
> 
> Yes. There is actually a longer term solution... which is to 'rebase'
> every cygwin linked .dll on a particular system to not conflict with
> each other - which has to be done by setup.exe.

Yes, but only with the apps and dll's that setup knows about.  Recall
the discussion on this list some months ago concerning sybase DLL's (I
think).   Somebody had a custom cygwin app that linked to
vendor-supplied database DLLs as well as cygwin stuff (which is fine as
long as the resulting app is not distributed...GPL conflicts
notwithstanding).

Anyway, they had a problem after upgrading to a new cygwinish dll
(cygncurses?? I think) w.r.t. load-on-fork.  There's no way setup/rebase
can be used to avoid that problem a_priori...is there?  (As I recall,
the person did a 'hand rebase' on his own system to work around
it...aware that he would have to repeat the process every time he
updated that problem DLL from the cygwin dist)

--Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -