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] |
Just installed it (WinXP), getting this: c:\WINDOWS>uname c:\unix\bin\uname.exe: *** shared version mismatch detected - 0xBC3E/0x3E. 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. No multiple copies of cygwin1.dll on my system. -- Gary R. Van Sickle Brewer. Patriot. > > On Tue, Oct 22, 2002 at 06:00:38PM -0400, Norman Vine wrote: > >Christopher Faylor wrote: > > > >> On Mon, Oct 21, 2002 at 03:03:13PM -0400, Norman Vine wrote: > >> >Christopher Faylor writes: > >> > > >> >> I was able to duplicate Jason's mmap problem with his version of exim > >> >> and, so, I think I was also able to fix it. > >> > >> >> So, try a snapshot. Collect them all. Win valuable prizes. > > > > >> >rxvt seems to have a problem with this dll > >> > >> >make[1]: Leaving directory `/src/cygwin2/obj/libiberty' > >> > 2194 [main] ? 2076 open_shared: relocating shared object shared(3) > >from > >> >0xA000000 to 0xC5D0000 on Windows NT > >> >Signal 11 > >> > >>The above message is a warning. The signal 11 is a problem. There > >>should be a stackdump file. Please decode the addresses with addr2line > >>and report them here. > > > >It appears as if todays patch < see below > fixes this problem > > That was my first stab at fixing the problem but it looks like all of > my activity in the last couple of weeks to stabilize 1.3.13 has been a > shell game. > > I tried to introduce a speedup for select() in 1.3.13 by allocating a > reusable thread pool that select could use rather than stopping and > starting threads every time certain types of fds are being selected. > This worked ok except in the case of fork. When the threads are being > initialized, Windows allocated space for their stacks. Sometimes the > stacks showed up in places, like the heap, or in the locations where > dlls were supposed to live. So, cygwin's fork hack got confused. You > can't fault windows for placing the stacks whereever it feels like so, > in hindsight, the thread pool idea was doomed to failure. > > I finally bit the bullet today and scrapped the "allocate a thread pool > at process start" plan and changed it to "allocate threads as they are > needed and reuse them". If my analysis of the situation is correct, then > this should squash most of the problems with heap, mmap, and dlls that > have plagued 1.3.13 and snapshots. > > So, the latest snapshot should be better. It also has some ntsec fixes > courtesy of Pierre Humblet which should make the "incomplete /etc/passwd > file" problem a little better. For most people, in fact, that might be > the most important change in this snapshot. > > So, as usual, please try the 2002-10-22 snapshot. > > cgf > > -- > 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/ >
Attachment:
cygcheck.txt
Description: Text document
-- 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] |