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

[Nils Gladitz]

On 02/03/2014 12:45 PM, Alan W. Irwin wrote:

> It was that difference between the two cases that was confusing me. (As
> an aside, I am still left wondering a bit about how cmake was able
> to find the python library for the NONE case. It's naming conventions
> are different (python27.lib rather than libstdc++.dll.a) so perhaps
> there is some default CMAKE_FIND_LIBRARY_PREFIXES and
> CMAKE_FIND_LIBRARY_SUFFIXES for the NONE case that allow the python
> library but not the stdc++ library to be found.  But I am not going to
> pursue that question.)

Then as a side note there is a default suffix of ".lib" on windows which 
is what e.g. MSVC uses/expects. For gcc this is overridden.

> I discovered some time ago that for that traditional build-system case
> if both the installed C++ PLplot binding library and the principal
> PLplot C library that it links to are built as static libraries, then
> any attempt to link an executable to those static libraries with g++
> on the command line had to add an explicit reference to libstdc++
> either directly if pkg-config is not used or indirectly via
> pkg-config. (By the way, I am not sure this is still a necessity so I
> will check that tomorrow.)

In theory g++ should link libstdc++ implicitly by default.
Which is one of the reasons why in mixed C/C++ projects g++ should be 
used for the final link as well.

For CMake internal builds this is detected based on the source file 
languages but can also be enforced by using the LINKER_LANGUAGE target 
property.

Any chance your "traditional" build system just needs a nudge to use g++ 
rather than gcc for the link as well?

Nils