Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Message-ID: <008701c17f91$9dc8c2d0$0200a8c0@lifelesswks>
From: "Robert Collins" <robert.collins@itdomain.com.au>
To: "Charles Wilson" <cwilson@ece.gatech.edu>
Cc: "Jason Tishler" <jason@tishler.net>, "Michael Hudson" <mwh@python.net>,
   <david_abrahams@users.sourceforge.net>,
   "Cygwin" <cygwin@sources.redhat.com>
References: <20011206124426.B1448@dothill.com> <3C0FB399.2020300@ece.gatech.edu> <01fc01c17f74$0d774a20$0200a8c0@lifelesswks> <3C1164C8.AF785AAC@ece.gatech.edu>
Subject: Re: dll_list::load_after_fork() blues (was Re: [ python-Bugs-489709 ]  Building Fails ...)
Date: Sat, 8 Dec 2001 13:39:52 +1100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

----- Original Message -----
From: "Charles Wilson" <cwilson@ece.gatech.edu>
> > 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).

Actually what I have in mind is
* changes to install
(pseudo code):
if (installing a .dll or .exe)
  rebase and store info in /etc/setup
* changes to setup
if (installing a .dll or .exe)
  rebase and store info in /etc/setup

rebase:
find object size - sz
  lookup a gap of sz in the address table in /etc/setup
find object dependencies
  foreach
    if (a cygwin .dll)
      rebase this
    if (a non-cygwin .dll)
      store the base and size info in /etc/setup


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

Yes - following the pseudo code above should be ok (because its install
system dependent, not build system dependent).

MS actually have a tool for developers to do this with - as part of
their programs setup.exe. We may even be able to use that tool - which
would use the MS local machine database, not one of our own.

Rob


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