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, John Williams wrote:

> Max Bowsher wrote:
> > John Williams wrote:
> >
> >>They have a cross compiler that uses the cygwin compatability layer.
> >>They have modified and distribute a version of this layer, which is
> >>built upon cygwin1.dll version 1.3.13.  However, they distribute with
> >>their tools only a minimal subset of cygwin necessary for their tools
> >>to run.  However, in the project I am doing I need not only the 3rd
> >>party cross compiler, but also native gcc and binutils etc.
> >>
> >>However, simply running the 3rd party tools under the current cygwin
> >>release does not work (versioning errors),
>
> > Details?
>
> OK, here it goes.  EDK is the 3rd part tool set.  They distribute
> (binary and source) a modified version of cygwin they call Xygwin (with
> xygwin1.dll and so on).  I suspect this is part of the problem.
>
> Starting point
> ?
> Fresh install of Cygwin 1.3.20 into c:/cygwin
> ?
> Fresh install of EDK SP3 into c:/EDK
>
> At this stage, the EDK toolchain is in the path for both Xygwin and
> Cygwin (i.e. c:/EDK/gnu/powerpc/bin/nt and c:/EDK/gnu/microblaze/bin/nt).
>
> Initial testing
> ?
> EDK/Xygwin works fine
> o
> Binaries executing from /usr/bin, which maps to c:/EDK/xygwin/bin
>
> ?
> Cygwin works fine
> o
> make, gcc, etc
> o
> Executing from /usr/bin, which is mapped to c:/cygwin/ bin
>
> Running Cygwin binaries from within Xygwin:
> ?
> gcc ? not found
> ?
> Add cygwin bin to the path
> o
> export PATH=${PATH}:/xygdrive/c/cygwin/bin
> ?
> running gcc results in
> o
> c:\cygwin\bin\gcc.exe: *** proc version mismatch detected -
> xB3836013/0x8E0899FA.
> You have multiple copies of cygwin1.dll on your system.
> Search for cygwin1.dll using the Windows Start->Find/Search facility and
> delete all but the most recent version.  The most recent version
> *should* reside in x:\cygwin\bin, where 'x' is the drive on which you
> have installed the cygwin distribution.
>
> Running EDK binaries from within Cygwin:
> ?
> Running mb-gcc results in a Windows dialog box stating
> o
> This application has failed to start because xygwin1.dll was not found.
>   Re-installing the application may fix this problem.
> ?
> Adding xygwin/bin to the path, and re-running gives
> o
> c:\EDK\gnu\microblaze\nt\bin\mb-gcc.exe: *** proc version mismatch
> detected - 0x8E0899FA/0xB3836013.
> You have multiple copies of cygwin1.dll on your system.
> Search for cygwin1.dll using the Windows Start->Find/Search facility and
> delete all but the most recent version.  The most recent version
> *should* reside in x:\cygwin\bin, where 'x' is the drive on which you
> have installed the cygwin distribution.
>
> Clearly, there is a version mismatch between Xygwin and Cygwin 1.3.20.
> Checking version info on Xygwin1.dll reveals that Xygwin is built upon
> Cygwin v1.3.13.  This is the source of the versioning error.
>
> New strategy ? accept the versioning differences, and try to fool
> Cygwin/Xygwin into finding the right DLLs.  Approach:
> ?
> Copy c:/cywgin/bin/cygwin1.dll ? c:/cygwin/bin/xygwin1.dll, and
> ?
> c:/EDK/xywgin/bin/xygwin1.dll ? c:/EDK/xygwin/bin/cygwin1.dll
>
> (Note that ?cross-copying? cygwin1.dll from cygwin to Xygwin, and
> xygwin1.dll to Cygwin, won?t work because of the versioning differences
> described above)
>
> After duplicating the DLLs, running mb-gcc inside Cygwin no longer gives
> an error message, but instead it fails silently.  For example, ?mb-gcc
> ?c system.c? runs without error, but does not produce system.o.
>
> You asked for details!!  If anyone read this far they are a champion.
>
> Thanks,
> John

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