[CMake] Cannot find the libstdc++ library on MinGW/MSYS when C++ is not enabled

[Nils Gladitz]

On 03.02.2014 20:18, Alan W. Irwin wrote:
> 1. For this linking model the C++ library is dynamically linked with
> libstdc++, and the executable is dynamically linked with that C++
> library.  If non-transitive linking is working properly, I think for
> this case the executable could be linked by gcc without mention of
> libstdc++, but please confirm that mental model.

Sounds good (not entirely sure about the static libgcc in this case; see 
below).

> 2. For this linking model the C++ library is dynamically linked with
> libstdc++, but the executable is statically linked to the C++ library.
> I am not sure my mental model of static linking is correct, but I
> think for this case the link of the executable simply copies the C++
> (and C) code of the library into the final executable so that
> executable must be linked by gcc with libstdc++ added as an extra
> library to be linked, but that mental model also needs confirmation.
> 3. For this linking model the C++ library is statically linked with
> libstdc++, and the executable is statically linked to the C++ library.
> For this case, I think the part of libstdc++ that is required to
> satisfy the needs of the C++ library becomes part of that library, and
> then that code is copied into the final statically linked executable.
> So for this case, I think that final linking of the executable could
> be done with gcc without mention of libstdc++, but that mental model
> also needs confirmation.

Archives (static libraries) are basically collections of object files.
They are themselves not yet linked to libraries nor do they record 
dependencies
(though e.g. CMake tracks static library dependencies internally when 
you use target_link_libraries() so it can provide them in the final link).

I think the undefined references to libstdc++ can be satisfied by either
the shared or static version of libstdc++ in the final link of your 
executable.

In that sense I'd assume 2 and 3 would be identical on your side since
the final choice would be delayed until the link of the executable.

As long as none of your C++ API is exported "gcc" may work ok for the 
final link otherwise.
-lstdc++ should work (which is what g++ itself passes) without using 
full path names.
I think there are problems though if you throw exception across DLL 
boundaries
with the static libgcc that gcc uses per default (g++ uses -shared-libgcc).

Nils