dll version collision

dll version collision

[Michael Hale]

Hi,

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?

The reason that I want to do this is because the developers at our site 
use the cygwin console for development, and our build process depends 
on certain cygwin files.  I would like to be able to keep all the 
cygwin stuff that the build needs in our repository so that all 
developers will have a consistent environment, but I obviously can't 
have multiple versions of cygwin1.dll on a machine.   My thought was to 
recompile the tools needed by the build process linked to 
build_cygwin1.dll.


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

Re: dll version collision

[Baurjan Ismagulov]

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?

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.

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

* 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 :) ?

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.

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

Re: dll version collision

[Igor Pechtchanski]

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

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

Re: 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/

Re: dll version collision

[Christopher Faylor]

On Fri, May 28, 2004 at 12:38:50PM -0400, Michael Hale wrote:
>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.

If it is beyond your abilities then you shouldn't be considering this
option.  This is likely never to be an accepted way of using the cygwin
DLL.
--
Christopher Faylor			spammer? ->	aaaspam@sourceware.org
Cygwin Co-Project Leader				aaaspam@duffek.com
TimeSys, Inc.

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

Re: dll version collision

[Michael Hale]

On May 28, 2004, at 1:15 PM, Christopher Faylor wrote:

> On Fri, May 28, 2004 at 12:38:50PM -0400, Michael Hale wrote:
>> 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.
>
> If it is beyond your abilities then you shouldn't be considering this
> option.  This is likely never to be an accepted way of using the cygwin
> DLL.
What is the correct way for someone to run multiple versions of cygwin 
on their machine then?  This seems like a very useful feature to me, 
since among other uses it would allow a new version to be tested along 
side an older but known version of cygwin.

> --
> Christopher Faylor			spammer? ->	aaaspam@sourceware.org
> Cygwin Co-Project Leader				aaaspam@duffek.com
> TimeSys, Inc.
>
> --
> 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/
>
>
  "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/

Re: dll version collision

[Reini Urban]

Michael Hale schrieb:
> What is the correct way for someone to run multiple versions of cygwin 
> on their machine then?  

There's none!

 > This seems like a very useful feature to me,
> since among other uses it would allow a new version to be tested along 
> side an older but known version of cygwin.

Kill all cygwin processes (via net stop or psservice and then via 
taskman or pskill),
backup the current cygwin1.dll and rename the new (snapshot) cygwin dll 
to cygwin1.dll,
start the autostarting cygwin processes again (ipc-daemon2, cron, ...),
test it.

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/


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

Re: dll version collision

[Michael Hale]

On May 28, 2004, at 2:17 PM, Reini Urban wrote:

> Michael Hale schrieb:
>> What is the correct way for someone to run multiple versions of 
>> cygwin on their machine then?
>
> There's none!
That is too bad.  I guess that means I will have to worry about varying 
environments in our build process.  At least until cygwin has the 
ability to run in conjunction with other cygwins.

>
> > This seems like a very useful feature to me,
>> since among other uses it would allow a new version to be tested 
>> along side an older but known version of cygwin.
>
> Kill all cygwin processes (via net stop or psservice and then via 
> taskman or pskill),
> backup the current cygwin1.dll and rename the new (snapshot) cygwin 
> dll to cygwin1.dll,
> start the autostarting cygwin processes again (ipc-daemon2, cron, ...),
> test it.
This is not really a solution to my problem, which is how do I run 
multiple cygwin versions simultaneously.
>
> -- 
> Reini Urban
> http://xarch.tu-graz.ac.at/home/rurban/
>
>
> --
> 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/
>
>
  "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/

Re: dll version collision

[Christopher Faylor]

On Fri, May 28, 2004 at 01:31:34PM -0400, Michael Hale wrote:
>On May 28, 2004, at 1:15 PM, Christopher Faylor wrote:
>>On Fri, May 28, 2004 at 12:38:50PM -0400, Michael Hale wrote:
>>>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.
>>
>>If it is beyond your abilities then you shouldn't be considering this
>>option.  This is likely never to be an accepted way of using the cygwin
>>DLL.
>
>What is the correct way for someone to run multiple versions of cygwin
>on their machine then?  This seems like a very useful feature to me,
>since among other uses it would allow a new version to be tested along
>side an older but known version of cygwin.

You use the same technique as if you were testing another version of
linux.  Or you'd backup your system prior to updating cygwin.  It is not
likely that you could have two installations running on the same system
with no bleed between them.  Having two versions of cygwin working at
the same time is not a goal for the cygwin project.

cgf

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

Re: dll version collision

[Baurjan Ismagulov]

Hello, Christopher!

On Fri, May 28, 2004 at 03:05:50PM -0400, Christopher Faylor wrote:
> You use the same technique as if you were testing another version of
> linux.  Or you'd backup your system prior to updating cygwin.  It is not
> likely that you could have two installations running on the same system
> with no bleed between them.

Well, with UML I have a reasonable environment to test most of things I
have to deal with. I would be happy to see the same for cygwin.


> Having two versions of cygwin working at the same time is not a goal
> for the cygwin project.

Does this mean that if someone comes with a clean patch doing that, it
would not be accepted? Once it were there, it wouldn't require
maintenance, any kind of user support can be explicitly disclaimed. What
kind of problems do you expect?


With kind regards,
Baurjan.

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

Re: dll version collision

[Christopher Faylor]

On Fri, May 28, 2004 at 09:46:34PM +0200, Baurjan Ismagulov wrote:
>On Fri, May 28, 2004 at 03:05:50PM -0400, Christopher Faylor wrote:
>>You use the same technique as if you were testing another version of
>>linux.  Or you'd backup your system prior to updating cygwin.  It is
>>not likely that you could have two installations running on the same
>>system with no bleed between them.
>
>Well, with UML I have a reasonable environment to test most of things I
>have to deal with.  I would be happy to see the same for cygwin.

UML is not linux.  It is a mechanism for running linux in userspace.  If you
want to implement something like that for Windows, more power to you.  Or
you could just run VMware.

>>Having two versions of cygwin working at the same time is not a goal
>>for the cygwin project.
>
>Does this mean that if someone comes with a clean patch doing that, it
>would not be accepted?  Once it were there, it wouldn't require
>maintenance, any kind of user support can be explicitly disclaimed.
>What kind of problems do you expect?

I thought from this discussion that no one has the technical skills or
time necessary to use the facilities that are already part of cygwin.
Asking whether we would accept patches seems either rhetorical or at
least premature.

cgf

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

Re: dll version collision

[Baurjan Ismagulov]

On Fri, May 28, 2004 at 03:58:09PM -0400, Christopher Faylor wrote:
> UML is not linux.  It is a mechanism for running linux in userspace.

Well, the point was that it can be used for testing. I haven't said it
was linux, although for me it more or less is, as long as my kernel
module or application has the necessary API and run-time environment.
But I think you see what I mean, this goes OT.


> I thought from this discussion that no one has the technical skills or
> time necessary to use the facilities that are already part of cygwin.
> Asking whether we would accept patches seems either rhetorical or at
> least premature.

This is good news :) . Your words in the previous posting sounded so
stark and express that I wanted to eliminate the possibilities that: 1)
there is something fundamentally bad in that idea; 2) the code would
definitely have to be maintained separately.


With kind regards,
Baurjan.

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

Re: dll version collision

[Baurjan Ismagulov]

Hello, Igor!

On Thu, May 27, 2004 at 06:33:20PM -0400, Igor Pechtchanski wrote:
> > * It isn't possible with the current cygwin.
> It is possible, but non-trivial.

Well, I've meant the binary DLL installed using setup.


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

Wow, it's even partly implemented!


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

Thanks for the info! Do you know a good overview of exec, similar to
that of fork, given in the user's guide?


> I repeat: you really should know what you're doing before you attempt
> this.  I can't emphasize this enough.

Are there any other implications that readily come to your mind?


With kind regards,
Baurjan.

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