dll version collision

[Michael Hale]

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/