Re: MinGW build and FTGL library for Octave 3.1.55

[Alexander Mamonov]

Hello Benjamin,

Thank you, this is very helpful indeed. I finally managed to compile
Octave (3.2.0-rc4) with MinGW with all modules being linked
dynamically. I found that the following combination of flags works:

export CPPFLAGS="-I/local/octave-mingw32_gcc-4.3.0-dw2/include"
export CXXFLAGS="-O2 -D_DLL"
export LDFLAGS="-L/local/octave-mingw32_gcc-4.3.0-dw2/lib
-shared-libgcc -lstdc++_s"
export CFLAGS="-O2"
export LIBS="-lstdc++_s"

However, at run-time I still observe the problem that I described in
this thread:

http://www-old.cae.wisc.edu/pipermail/bug-octave/2009-May/008551.html

For my build of 3.2.0-rc4 I used MinGW and the libraries that you
shipped with 3.0.5 on sourceforge (plus a few missing ones that I
built myself using the same version of gcc - qrupdate, fltk, ftgl,
fftw3, graphicsmagick). Thus, I tried to recreate a build environment
as close to yours as possible. But I still have the problem with
exceptions being thrown across DLL (and OCT) boundaries. For example,
in your build of 3.0.5 the command

> eig(Inf)

results in

error: EIG: matrix contains Inf or NaN values

but for my build of 3.2.0-rc4 I get

error: EIG: matrix contains Inf or NaN values
terminate called after throwing an instance of 'octave_execution_exception'

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
panic: Aborted -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete

Do you have any idea what can cause such behavior?

Thank you,
Alex

On Fri, May 22, 2009 at 4:54 PM, Benjamin Lindner <address@hidden> wrote:
> Alexander Mamonov wrote:
>>
>> Hello Benjamin,
>>
>> Many thanks for the excellent work!
>> Can you please share with me the forbidden arcane knowledge of what
>> combination of compiler flag variables and configure options will
>> result in .oct files being linked dynamically to libgcc and libstdc++?
>> I tried different combinations of -shared, -shared-libgcc, and
>> --enable-shared, but the .oct files are still being linked statically.
>>
>
> Well it's certainly not forbidden, but thinking of it, it is not really well
> documented ...
>
> So here we go:
>
> You must distinguish between the shared libgcc and the shared libstd++.
> Linking against shared libgcc is simple, provide -shared-libgcc at linking
> stage.
>
> Linking against shared libstd++ is a bit more tricky. Needless to say, you
> will need a version of gcc which includes a shared libstd++. TDM's mingw
> port 4.3.0-2 does, for example. (mind the -2 !).
> The shared version of libstd++ is called libstd++_s, hence you must add
> -lstdc++_s. Mind that the default libstd++ will be added implicitly, so be
> careful of the order of the linker libraries.
> Then, you should link with --enable-auto-import. This is not mandatory,
> *but*, if you do not compile with -D_DLL, the externals referenced into
> standard c++ library will not be maked as __dllimport__, and therefore are
> not found in the shared library's import libaray, *unless* you link with
> --enable-auto-import, *and* since the static version of libstd++ is
> implicitly added at linker stage this will silenty use the static version of
> libstd++, although you might have explicitly specified -lstd++_s.
> So to save me the debugging pain, I always specify -D_DLL, thus shared and
> only shared libstd++ is used, and if there is a problem, I get a linker
> error.
>
> So here is what I do:
>  CXXFLAGS += -D_DLL
>  LDFLAGS += -shared-libgcc
> and then add
>  -lstdc++_s
> to the linker libraries at the proper position.
>
> try the hello world example
>
> #include <iostream>
> int main()
> {
>   std::cout << "Hello World!\n";
>   return 0;
> }
>
> once as
>  g++ -D_DLL -shared-libgcc -s -o hello_shared.exe hello.cc -lstdc++_s
> (mind the order of object files and linker libraries!)
> and once as
>  g++ -s -o hello_static.exe hello.cc
>
> and (this is also possible)
>  g++ -shared-libgcc -s -o hello_sharedgcc.exe hello.cc
> which will link against shared libgcc but static libstd++
>
> I get
> $ ls -la hello*.*
> -rw-r--r-- 1 admin Admins     82 May 22 22:37 hello.cc
> -rwxr-xr-x 1 admin Admins   5120 May 22 22:38 hello_shared.exe
> -rwxr-xr-x 1 admin Admins 441344 May 22 22:44 hello_sharedgcc.exe
> -rwxr-xr-x 1 admin Admins 460288 May 22 22:38 hello_static.exe
>
>
> Now the really tricky part comes, when you cannot specify "-shared-libgcc"
> because the tool you use, for example mkoctfile, does not recognize this
> flag (libtool doesn't either, by the way).
> The workaround I use here, is to specify -shared-libgcc as part of CXX's
>  name, as in CXX="g++ -shared-libgcc"
>
> hope this helps
> benjamin
>

config.log.gz
Description: GNU Zip compressed data