Edward Lam <edward <at> sidefx.com> writes:
> > 61020293 looks like an address in the dll range, probably cygwin1.dll. It
> > would be nice to know what function is dying, but doing that may require
> > rebuilding a bash image with debugging symbols. Did you by chance do any
> > rebasing? Maybe this is a case where I didn't use the correct gcc-4 flags
> > for compilation, at which point an updated binutils/gcc might fix things.
>
> No, I didn't do any rebasing. I also tried using rebaseall and
> peflagsall to no avail.
I'm wondering if the problem is not how I compiled bash, but how I compiled
readline. Dave, any pointers I should try or maybe a missed compiler flag I
should have used to build libreadline7 with gcc4? I'm shooting in the dark,
since I can't seem to reproduce the crash.
>
> Incidentally, is installing the bash and libreadline source broken? If I
> install the src for say, the make package, it installs it into a
> subdirectory under /usr/src. But when I tried to do the same for
> bash-3.2.49-23, I just got a bash src tar ball along with a bunch of
> patch files. Is this expected?
It's more than just patch files - it also includes the .cygport file that uses
those patch files. So yes, this is expected;
quoting /usr/share/doc/Cygwin/bash.README:
Build instructions:
unpack bash-3.2.49-23-src.tar.bz2
if you use setup to install this src package, it will be
unpacked under /usr/src automatically
cd /usr/src
cygport bash-3.2.49-23 all
--
Eric Blake
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
