This is the mail archive of the
mailing list for the Cygwin project.
Re: Obtaining a pervious version
- From: Igor Pechtchanski <pechtcha at cs dot nyu dot edu>
- To: Max Bowsher <maxb at ukf dot net>
- Cc: cygwin at cygwin dot com, John Williams <jwilliams at itee dot uq dot edu dot au>
- Date: Mon, 17 Feb 2003 22:05:47 -0500 (EST)
- Subject: Re: Obtaining a pervious version
- Reply-to: cygwin at cygwin dot com
On Tue, 18 Feb 2003, Max Bowsher wrote:
> Igor Pechtchanski wrote:
> > John,
> > FYI, if you simply copy the DLL, the programs will try to load it
> > twice (once for each name). As I see it, you have the following
> > choices:
> > 1) Check out from CVS with the "cygwin-1-3-13-1" or "cygwin-1-3-13-2"
> > tag (depending on the version they used) and compile a xygwin1.dll
> > with a different shared memory region name.
> First, the cygwin CVS tags are for cgf's private use, and are not guaranteed
> to correspond exactly to releases. Also, they don't reach the sources
> outside of winsup.
> Second, if he were to get the Cygwin sources, he would be compiling
> Actually, building a replacement *x*ygwin1.dll (with different shared memory
> ID) from the *x*ygwin source tarball might be the easiest option.
Yeah, quite true. I did check that the tag was there, and roughly
corresponded to the release date, but no more than that. Didn't think
about using *their* sources... Do you suppose they actually followed
Cygwin's suit of not releasing sources outside of winsup either?
Although I do know that I was able to compile 1.3.13-2, at least, from
released sources + stock w32api (2.0-1), so that shouldn't matter too
much... And Chris did say that all they did was change the DLL name...
> > 2) Compile your own cygwin1.dll from CVS or sources (search the list
> > for instructions) with a different shared memory region name.
> > 3) Recompile your toolset (as Max recommended).
> > If I were you, I'd go with choice #1, as it'll be easier to update
> > cygwin1.dll after that, and it doesn't involve the effort of
> > recompiling the whole toolset. Choice #3 is probably the most
> > prudent in the long run, though.
> #3 is certainly the conventional way to do it. But maybe, if you made an
> alternate xygwin1.dll with different shared memory id, you could submit the
> patch to xilinx, and then once they re-released, you wouldn't have the
> problem any more?
Which is why I recommended #1 (sort of). I didn't think of a patch,
though. And I'm ranting, sorry...
|\ _,,,---,,_ firstname.lastname@example.org
ZZZzz /,`.-'`' -. ;-;;,_ email@example.com
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html