Re: Octave & Fortran continued

[Michael Goffioul]

On Tue, Jan 13, 2009 at 9:39 PM, Benjamin Lindner <address@hidden> wrote:
>>
>> Linking against shared libgcc should be doable by simply doing
>> ./configure ... LDFLAGS="-shared-libgcc"...
>> at least for libtool-based build. No source change required.
>
> Theoretically yes, in reality no.
> new versions of libtool (in my case version 2.2.6 as used in fftw3-3.2) fail
> to honor this flag.
> The problem with libtool is that it tries to think too much for itself,
> (which is practically never a good thing). the configure script creates a
> command line, libtool now rescans the command line, interprets it and then
> creates a new command line for the compiler/linker to be called eventually.
> And in rescanning, the flag "-shared-libgcc" is not added to linker flags,
> as a LDFLAGS=-shared-libgcc would suggest.
> It works for older versions, though.
> So some patching is required here.

Can't it be done with LDFLAGS="-Wc,-shared-gcc"?

>> What about shared libstdc++? What is needed to link against it?
>
> 1) CXXFLAGS="-D_DLL" (declares the C++ standard library as __dllimport in
> the headers) and
> 2) the addition of "-lstdc++_s" as the *last* library on the command line,
> more concise, *after* any other library that references libstd++ (this is
> due to GNU ld's method-of-work). But this cannot be done by a simple
> LIBS="-lstdc++_s", since
> a) it's a g++ (not a gcc) libray. gcc does not require it, and it might no
> be found by gcc's lib search paths, and - more important -
> b) you can practically never guarantee that the configure stage does not add
> libraries after the ones specified on the command line in which case  you
> might run into problems with undefined references.

I tried a simple test case (tests if libsigc++), but it fails with
multiple symbol definitions, from libstdc++ and libstdc++_s.
Altough -lstdc++_s is last on the command-line...

Michael.