This is the mail archive of the cygwin@cygwin.com 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: Obtaining a pervious version


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.
>
> Um?
>
> 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
> *c*ygwin1.dll.
>
> 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?
>
> Max.

Which is why I recommended #1 (sort of).  I didn't think of a patch,
though.  And I'm ranting, sorry...
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.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!
  -- /usr/games/fortune


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.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]