Mail Archives: cygwin/2007/09/05/21:26:13
Thank you Brain
>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.
James R. Phillips, who is a maintainer of octave 2.1.73. Pherhaps he
is not working as a maintainer because he has not been made any
respose when I threw a topic of my testing binary of Octave 2.9.12
on cygwin.
John W. Eaton, who is a main develper, seems not to like use
undefault complier because octave uses the develop category tools
including gcc for the advanced user tool. (Function can be complied
to specially named dynamic link library *.oct)
He is afraid that the specially prepared complier confuses the user.
For this reason, James selected the gcc normally prepared.
At that time, there was no other way to build octave on windows so
that even slow binary is meaningful.
>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.
I understand what you would like to say.
>
>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
>related.)
As an user's stand point, technical problem of Dwarf2/SJLJ is not be
concerned.
I would like to get good compliers in which the fast and safe
exceptions facilities are worked.
However I thank to the cygwin developers' efforts every day because
the I'm using cygwin every day.
Thank to all contributers to the cygwin.
Sincerely,
Tatsuro MATSUOKA
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -