dll_list::load_after_fork() blues (was Re: [ python-Bugs-489709 ] Building Fails ...)

Robert Collins robert.collins@itdomain.com.au
Fri Dec 7 18:41:00 GMT 2001

----- Original Message -----
From: "Charles Wilson" <cwilson@ece.gatech.edu>
> > Yes. There is actually a longer term solution... which is to
> > 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
> 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

find object size - sz
  lookup a gap of sz in the address table in /etc/setup
find object dependencies
    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
> 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.


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/

More information about the Cygwin mailing list