octave-maintainers
[Top][All Lists]
Advanced

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

Re: Octave & Fortran continued


From: Christopher Hulbert
Subject: Re: Octave & Fortran continued
Date: Tue, 13 Jan 2009 19:34:08 -0500

On Tue, Jan 13, 2009 at 5:55 PM, Michael Goffioul
<address@hidden> wrote:
> 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.

You can get libtool to accept it if you use the -Xcompiler or
-XCClinker in front of it (i.e. -XCClinker -shared-libgcc). The
problem with that is you cannot use that in a non-libtool
compiler/link command or the compiler will likely choke on an unknown
option. So, the way I get unknown options passed libtool in autotools
packages I develop is add variables that are meant to be passed to
libtool (e.g. LT_CFLAGS, LT_CXXFLAGS, LT_LDFLAGS, etc.). Just add
those variables to the flags defined for libtool libraries.

On the other hand, libtool likes to work with the GNU compilers, so
there is at least some chance that a libtool patch to recognize that
option would be accepted.

Chris

>
> 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.
>


reply via email to

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