This is the mail archive of the
mailing list for the Cygwin project.
Re: rebase for setup.
- 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>
- Date: Fri, 4 Jan 2002 00:21:11 +1100
- Subject: Re: rebase for setup.
- References: <008101c1819b$021aa860$a300a8c0@nhv> <20011212085744.A2400@dothill.com> <20011218211235.GA2476@dothill.com> <018101c1880b$affd10a0$0200a8c0@lifelesswks> <20011219032813.GG10253@redhat.com> <20011221125117.GC1792@dothill.com> <027401c18bae$25318fe0$0200a8c0@lifelesswks> <20011227174434.GC2204@dothill.com> <045a01c18f34$10a73730$0200a8c0@lifelesswks> <20020103131837.GA1940@dothill.com>
----- Original Message -----
From: "Jason Tishler" <email@example.com>
> Unfortunately, it does not actually handle pathological (or should I
> 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
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.
> A couple of more issues to deal with:
> 1. Determine why cygcurl-2.dll and possibly other DLLs do not tolerate
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
> 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.