delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2002/07/16/15:16:24

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
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-Id: <200207161916.g6GJGDW81130@pilot15.cl.msu.edu>
Date: Tue, 16 Jul 2002 15:16:13 EDT
To: cygwin AT cygwin DOT com
Subject: Re: Rebasing dlls - why it is necessary
From: Harold L Hunt <huntharo AT msu DOT edu>

Steven O'Brien <steven DOT obrien2 AT ntlworld DOT com> said:

> This can be seen as a hack, because rebasing should really be for
> efficiency, not for functionality. But the only other solution I can
> imagine is a complete re-working of the way cygwin handles dynamically
> loaded dlls and fork() - and I guess this is not likely in a hurry. As a
> long-shot, maybe the work that Egor is doing on runtime re-location for
> auto-export of data symbols could be extended so that cygwin no longer
> needs dlls to be loaded at absolute addresses?
> 
> Steven

Steven,

I have a question: Do you think that rebasing the distributed XFree86 DLL's
would have a positive effect on Cygwin/XFree86's performance/load time?  If
so, perhaps I will look into rebasing the dlls that are in our packages. 
Otherwise, I don't suppose I need to do anything at all.  :)

Harold

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


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019