Re: MinGW build of 3.2.0: shared libstdc++

[Alexander Mamonov]

Hi Benjamin,

I did as you suggested - I put the -shared-libgcc flag into the
definition of gcc, g++ and gfortran, and then I hacked the make files
to have -lsdtc++_s in the end of every link call. And it worked! I now
have a build of 3.2.0 which has no problems throwing exceptions across
the boundaries of .oct files. Thank you for all your help!
I know that you use a flag CXXLIBS in your patches to build MinGW
Windows binaries. Maybe you could submit a changeset to make this flag
a standard feature of configure script? Then Octave would be buildable
in MinGW with dynamic libraries without any modifications to make
files.

Regards,
Alex

On Fri, Jun 5, 2009 at 3:34 PM, Benjamin Lindner <address@hidden> wrote:
> Alexander Mamonov wrote:
>>
>> Thank you for a quick reply. Adding -shared-libgcc helps indeed for
>> the example that I provided. For my build of 3.2.0 I added
>> -shared-libgcc to LDFLAGS. Is it enough to ensure that every library
>> is linked dynamically to libgcc?
>
> To my knowledge, yes.
> No, wait, there's a catch (there's always one)
> If the build process involves the use of libtool, then simply adding
> -shared-libgcc to LDFLAGS does not help. libtool interprets all command line
> arguments and reorders/retranslates/messes with them and finally issues
> calls to comiler/linker. Now libtool does not understand "-shared-libgcc" so
> it simply omits it (great!)
> The trick is, to include -shared-libgcc into the names of CC and CXX and
> F77, like CC="gcc -shared-libgcc".
> I do this is all my build scripts when libtool is used.
>
>> The reason I started with an example not involving a dll, is that I
>> wanted to first check if throwing exceptions works at all with
>> dynamically linked standard libraries.
>
> Sure, that's also the way I took, I just wanted to point out that just
> because throwing exceptions in a single file works, the dll issue is a
> seperate one to be aware of.
>
>> Regarding the libraries that I link Octave to, I built them using your
>> scripts from sourceforge, so they must be linked with -shared-libgcc.
>
> Yep, that should be all in order.
> I'm doing a 3.2.0 build right know and it works here for me, so yes, it
> should be ok.
> I need to push my latest changes for 3.2.0 into the svn repository, but I
> want to check first if everything works.
>
>> I will double check just to make sure.
>
> A double check is always welcome, I had already one hard-to-track-down bug
> where loading an oct file failed, but not with crushing octave, but simply
> issuing an error.
> The error not being very helpful I found at last that I had missed one
> particular external library to be linked correclty with -shared-libgcc. This
> took me quite some time to track down, that's why I emphasised it in the
> first place...
>
>>
>> Thanks,
>
> you're welcome
>
> benjamin
>