Le 08/11/13 20:07, Charles Wilson a écrit :
On 11/8/2013 1:49 PM, Bob Friesenhahn wrote:
Isn't it because libtool wants to control the order of the linking and
assure that all dependencies (including static) are tracked/known and
applied at the correct times? It wants to assure that static
dependencies are linked into the dependent program rather than into some
dependent shared library (and thus causing a problem).
It was common (and perhaps still is) for the GNU C++ library to be
delivered as a static library for Windows/MinGW because C++ exceptions
were not handled properly when thrown by DLLs.
Quite a lot of effort went into making this work the way it currently
does.
First libtool tries to take away all of the libraries which would be
added automatically and then it applies the libraries that GCC says it
would use at the correct time.
One of my wishlist roundtuit items is to special-case this behavior for
libtool + GNU toolchains. For that combo, instead of the procedure Bob
outlines, and then using $LD to link....just use the compiler driver
(e.g. g++, or gfortran, or gcc) to link, WITHOUT -nostdlib [1]. We're
already passing the ABI-modifying -m and -f flags anyway, and it would
really REALLY simplify libtool's logic...
[1] unless of course the end user put -nostdlib in $LDFLAGS or something.
--
Chuck
I believe Chuck is oriented in the right direction.
A good example is with -fstack-protector.
gcc/g++ knows how to link depending upon whether the platforms libc has
SSP support or not.
I doubt very much that libtool wants to figure out whether to add the
specific libraries necessary for SSP to the link command.
It *should* however pass through the provided flags to the compiler
driver, and not strip in this case '-fstack-protector'; object of:
Bug: linking shared libraries on Cygwin results in undefined references to
__stack_chck_guard for code compiled with -fstack-protector
In this particular "worst" case, '-fstack-protector' is stripped, and
even if it passed through, the g++ '-nostdlib' defeats the purpose!
