This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Re: dll_list::load_after_fork() blues (was Re: [ python-Bugs-489709 ] Building Fails ...)
----- Original Message -----
From: "Charles Wilson" <cwilson@ece.gatech.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/