octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Octave & Fortran continued


From: Michael Goffioul
Subject: Re: Octave & Fortran continued
Date: Mon, 12 Jan 2009 23:46:35 +0000

On Mon, Jan 12, 2009 at 9:22 PM, Benjamin Lindner <address@hidden> wrote:
> The problem with throwing exceptions across dll boundaries has been a
> long-standing issue with gcc ports for both mingw and cygwin.
> The issue was raised with the question of dw2 vs. sjlj exception
> implementation, dw2 yielding tremendously faster code.
> My first steps with octave in the 2.1.x-era were on cygwin where the at that
> time available gcc-3.3.3 used sjlj exception handling and the speed of the
> generated code was ghastly (sic!) slow. I then rebuilt a native cygwin
> gcc-3.2 version which incorporated a hack (not from me - present in the
> sources) allowing for a working much faster dw2 exception handling and the
> speed of the generated executable was acceptable.
>
> With the release of mingw32-gcc-4.2.1 shared libgcc and shared libstd++ were
> introduced, allowing first for again fast dw2 exception handling and second
> for throwing exceptions across dll boundaries.
>
> [1]
> http://garr.dl.sourceforge.net/sourceforge/mingw/gcc-4.2.1-dw2-2-release_notes.txt
>
> The same is true for the 4.3.0 release
>
> [2] http://sourceforge.net/project/shownotes.php?release_id=596917
> [3] http://www.tdragon.net/recentgcc/
>
> I also found a long thread which also covers this problem.
> [4] http://www.cygwin.com/ml/cygwin/2007-03/msg00676.html
>
> As I understand the information available on the net, the problem of
> exceptions and dlls is still not completely solved. It is still not possible
> to throw dw2-compiled exceptions across non-dw2-compiled stack frames (e.g.
> a windows callback) - see [3].
> Also in [3], TDM reports he has ported the old mingw-3.4.5 hack to his
> recent gcc-4.3 series, where shared libgcc is no longer required. However he
> states, that this is a temporary workaround. So I expect shared libgcc to
> reappear.
>
> So from what I read, shared libgcc is required in order to enable throwing
> (and catching) exceptions across dll boundaries.
> To be very exact, the mingw release notes speak of "libgcc", not of
> "libstd++" as requirement. But if I need a shared libgcc, then I can make
> use of a shared libstd++ in the same build process anyway...

Linking against shared libgcc should be doable by simply doing
./configure ... LDFLAGS="-shared-libgcc"...
at least for libtool-based build. No source change required. What about
shared libstdc++? What is needed to link against it?

Michael.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]