Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
Message-ID: <09df01c19459$8414f250$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Jason Tishler" <jason AT tishler DOT net>
Cc: <cygwin-apps AT sources DOT redhat DOT com>
References: <008101c1819b$021aa860$a300a8c0 AT nhv> <20011212085744 DOT A2400 AT dothill DOT com> <20011218211235 DOT GA2476 AT dothill DOT com> <018101c1880b$affd10a0$0200a8c0 AT lifelesswks> <20011219032813 DOT GG10253 AT redhat DOT com> <20011221125117 DOT GC1792 AT dothill DOT com> <027401c18bae$25318fe0$0200a8c0 AT lifelesswks> <20011227174434 DOT GC2204 AT dothill DOT com> <045a01c18f34$10a73730$0200a8c0 AT lifelesswks> <20020103131837 DOT GA1940 AT dothill DOT com>
Subject: Re: rebase for setup.
Date: Fri, 4 Jan 2002 00:21:11 +1100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
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: 03 Jan 2002 13:21:02.0709 (UTC) FILETIME=[7DD36250:01C19459]

----- Original Message -----
From: "Jason Tishler" <jason AT tishler DOT net>

> Unfortunately, it does not actually handle pathological (or should I
say
> incestuous) programs such as Python that use freshly built components
> (i.e., DLLs) during the build process itself.
>
> Does it make any sense to change Cygwin's ld to rebase on the fly
> instead?

Ah, well that's easy. Shoot python :]. This is why I suggested a bfd
based rebase, rather than the MS function orginally - so that binutils
can do this natively, and yes I think that this would be good - but the
system database then gets tightly linked to bfd - urgh. The layering
needs more thought I think.

> > Mine is "rebase everything that appears linked" "x bytes apart". The
> > goal being to avoid rebasing 1000 .dll and .exe's when you run setup
> > and
> > install fortune.exe :}.
>
> Do we really need to rebase the .exe's?  If not, then the I only count
> 113 Cygwin DLLs in my system.  Besides rebasing seems to be quick.

.exes can be loaded via dlopen. (didn't know that huh? :]).

> > That requires persistent storage of the used
> > address range, thus storing the info in /etc/setup.
>
> I understood this part, given that your rebase algorithm is used --
> I just wasn't sure why the simple one wouldn't work.

We've only got 2Gb to play with. Programs with large datasets -
postgresql for instance - may need as much of that as possible. As the
number of .dll's and .exes grow this will become a bigger issue. A
debian box I upgraded today has 48000 files installed, with probably 5%
library or .exe's. So that's starting to eat into that 2Gb quite fast.

> > loadable modules probably need some thought in this context though.
>
> By "loadable," do you mean dlopen-ed DLLs?  If so, then definitely --
> Python has a bunch of them.

Yes.

> A couple of more issues to deal with:
>
> 1. Determine why cygcurl-2.dll and possibly other DLLs do not tolerate
> rebasing.

Hmm. Yes. Did you rebase .dll's after stripping them? And what strip
options where used?

> 2. Make sure whatever algorithm that we use can handle non-relocatable
> DLLs without getting confused or wasting address space.  (The current
> version of rebase would waste the offset value (e.g., 0x10000) of
address
> space on cygtclpip80.dll).

The algorithm I proposed does ('find available space'). That could be
tuned a bit, we still need to isolate how much offset is needed, and
where it really needs to be.

Rob