This is the mail archive of the cygwin-developers 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: [Cygwin64] dash segfault


On Mar 11 17:27, Peter Rosin wrote:
> On 2013-03-11 15:35, Peter Rosin wrote:
> > Second, there's the non-crash exit (where dash sometimes exits w/o
> > triggering error_start, this still happens with -3):
> > 
> > Basically, this time config.status didn't complete, and the configure
> > output ended with:
> > 
> > config.status: creating m4/Makefile
> > config.status: creating libgii.conf
> > 
> > but it is expected that it carries on with:
> > 
> > config.status: creating dist/Makefile
> > config.status: creating dist/rpm/Makefile
> > config.status: creating dist/rpm/libgii.spec
> > config.status: creating config.h
> > config.status: executing depfiles commands
> > config.status: executing libtool commands
> > 
> > 
> > That premature unexplained exit later killed make with:
> > 
> > ...
> > Making all in input
> > make[2]: Entering directory `/cygdrive/c/Cygwin/home/peda/ggi/cyg64/gii/input'
> > Making all in directx
> > make[3]: Entering directory `/cygdrive/c/Cygwin/home/peda/ggi/cyg64/gii/input/directx'
> > Makefile:314: .deps/di.Plo: No such file or directory
> > Makefile:315: .deps/dxguid.Plo: No such file or directory
> > Makefile:316: .deps/input.Plo: No such file or directory
> > ...
> > 
> > due to the deps not being there.
> > 
> > This bug is really troublesome, it does not give me a cozy feeling when
> > scripts only get half-done w/o any notice...
> 
> [I wrote most of this before you asked me to test some assumption]
> 
> I have now finally managed to collect the exit status after such
> a premature exit. Zero (or it might not get propagated back to the
> calling shell by configure). This time, configure output ended
> with:
> 
> checking for as... as
> checking for dlltool... (cached) dlltool
> checking for objdump... (cached) objdump
> checking for objdir... .libs
> 
> The next expected line (which didn't appear) is:
> 
> checking if gcc supports -fno-rtti -fno-exceptions... no
> 
> But it seems to happen more often when configure runs config.status
> near the end. Oh, right, I sometimes see a fourth class of errors,

Oh no, please don't.  This is getting confusing since I don't know
where to start anymore.  Can we try to stick with one error at a time
please?

> It might be time to reveal exactly what I'm doing, even if it isn't
> anything special...

I'll try this at one point this week.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]