[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Octave & Fortran continued
From: |
Benjamin Lindner |
Subject: |
Re: Octave & Fortran continued |
Date: |
Tue, 13 Jan 2009 22:39:25 +0100 |
User-agent: |
Thunderbird 2.0.0.18 (Windows/20081105) |
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.
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.
So the way I took is adding a new configure variable CXXLIBS (in the
style of LIBS and FLIBS) which I add at the appropriate places in the
various makefiles, and call the configure script as
./configure CXXFLAGS="-D_DLL" CXXLIBS="-lstd++_s" LDFLAGS="-shared-libgcc"
Using TDM's gcc-4.3.0-2 this procedure works well.
benjamin
- Re: Octave & Fortran continued, (continued)
- Re: Octave & Fortran continued, Benjamin Lindner, 2009/01/08
- Re: Octave & Fortran continued, Michael Goffioul, 2009/01/08
- Re: Octave & Fortran continued, Benjamin Lindner, 2009/01/09
- Re: Octave & Fortran continued, Michael Goffioul, 2009/01/09
- Message not available
- Re: Octave & Fortran continued, Michael Goffioul, 2009/01/11
- Re: Octave & Fortran continued, Michael Goffioul, 2009/01/11
- Re: Octave & Fortran continued, John W. Eaton, 2009/01/12
- Re: Octave & Fortran continued, John W. Eaton, 2009/01/12
- Re: Octave & Fortran continued, Benjamin Lindner, 2009/01/12
- Re: Octave & Fortran continued, Michael Goffioul, 2009/01/12
- Re: Octave & Fortran continued,
Benjamin Lindner <=
- Re: Octave & Fortran continued, Michael Goffioul, 2009/01/13
- Re: Octave & Fortran continued, Christopher Hulbert, 2009/01/13