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:	<008701c17f91$9dc8c2d0$0200a8c0@lifelesswks>
From:	"Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To:	"Charles Wilson" <cwilson AT ece DOT gatech DOT edu>
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>
References:	<20011206124426 DOT B1448 AT dothill DOT com> <3C0FB399 DOT 2020300 AT ece DOT gatech DOT edu> <01fc01c17f74$0d774a20$0200a8c0 AT lifelesswks> <3C1164C8 DOT AF785AAC AT ece DOT gatech DOT 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
X-Priority:	3
X-MSMail-Priority:	Normal
X-Mailer:	Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE:	Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime:	08 Dec 2001 02:39:49.0222 (UTC) FILETIME=[9B19A860:01C17F91]

----- Original Message -----
From: "Charles Wilson" <cwilson AT ece DOT gatech DOT 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/

- Raw text -