This is the mail archive of the cygwin 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: Slowness problem due to sjlj-exceptions for Octave

Tatsuro MATSUOKA wrote:

> My octave web
> I think it is better that I keep the my binary on my web but post on
> the new binary package on the cygwin.  I do not want to build the
> octave by the gcc in the cygwin package because it is too slow to use.

Maybe I'm misremembering, but I thought that the current octave package
maintainer entertained the idea of building the octave packages with a
gcc that had been rebuilt with --disable-sjlj-exceptions.  I don't
remember why this never happened.  At the very least, we had this same
discussion about SJLJ when the octave packages were first introduced, or
shortly thereafter.

> Do you mean standalone as standalone from cygwin1.dll?  Mingw binary
> depends on msvcrt.dll.  In this sense the binary built by mingw GCC
> is not standalone. Recently the mingw GCC4.2.1's were released.

But MSVCRT is part of the operating system and exists on every
installation of Windows and needn't be distributed, so MinGW binaries
are effectively stand-alone.  Users of MinGW have very different
expectations than users of Cygwin, which is why for Cygwin we could very
well just make shared libgcc/libstdc++/libgfortran (et al.) the default
and not worry so much about supporting the static case, but that's not
realistic for MinGW.

However this doesn't directly have anything to do with the Dwarf2/SJLJ
issue; it is relevant only in the context of moving to gcc 4.x as the
supported version.  (Of course, since 4.3 brings the possibility of
doing away with SJLJ for good, I suppose it might be indirectly


Unsubscribe info:
Problem reports:

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