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: snapshots R us


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]