This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: dll version collision


The ideas suggested here are definitely beyond my current ability. I hope someone else who would like this done, and has the skill will take it up.

On May 27, 2004, at 6:33 PM, Igor Pechtchanski wrote:

On Thu, 27 May 2004, Baurjan Ismagulov wrote:

Hello, Michael!

On Thu, May 27, 2004 at 04:53:17PM -0400, Michael Hale wrote:
Is it possible to recompile a subset of the cygwin binaries to depend
on cygwin1.dll renamed to something like build_cygwin1.dll? How would
I go about doing this?

Some comments:


This is a quite often-discussed topic, but there is not much info in the
archives. All I could understand is:


* It isn't possible with the current cygwin.

It is possible, but non-trivial. Take a look at how the Cygwin testsuite
runs. However, you shouldn't do this unless you know exactly what you're
doing.


* One needs at least to rename the library and use different registry
  entries and shared memory areas in different versions; perhaps
  something else.

That's pretty much it, IIRC. You can even share the mounts/registry entries.

* Max Bowsher has a working version, albeit of an older cygwin. He
wanted to patch the latest version himself, but I'm eager to see even
the old patch, it would be a great starting point without duplicating
the effort. Max, ple-e-ase :) ?

One way to have Cygwin automatically modify the shared memory area name is
to compile it with debugging (by passing the --enable-debugging flag to
configure). The trick here is that once you have such a cygwin1.dll,
you'll have to spawn the process that uses it via Windows mechanisms,
rather than Cygwin's own fork. Again, take a look at the testsuite
scripts, in particular the "cygrun.c" file, or just run it from a
shortcut or the cmd console.


I'm also interested in this kind of setup, but unfortunately, I haven't
got much time for this. If you are going to work on this, I could also
contribute some bits.


With kind regards,
Baurjan.

I repeat: you really should know what you're doing before you attempt this. I can't emphasize this enough. But it *is* possible.

To the OP: why not simply have an internal Cygwin mirror and make sure
everyone has the same version of Cygwin on their machine?
Your suggestion would work... it is just not as nice as having a subset of cygwin tools that are version controlled and don't conflict with anyone's environment. I want our build process to be as simple as possible, which to me means update from the repository then build. I don't want to have to worry about environment issues on different machines. Everything should be version controlled.

	Igor
--
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster." -- Patrick Naughton



"OS X: because it was easier to make UNIX user-friendly than to fix Windows"


-- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]