Mail Archives: cygwin/2004/05/28/12:39:19
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 AT cs DOT nyu DOT edu
> ZZZzz /,`.-'`' -. ;-;;,_ igor AT watson DOT ibm DOT 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/
- Raw text -