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

[Alan W. Irwin]

On 2014-02-03 09:33+0100 Nils Gladitz wrote:

> On 02/03/2014 07:36 AM, Alan W. Irwin wrote:
>> I don't understand this result at all since with CMAKE_LIBRARY_PATH
>> defined to the exact PATH where libstdc++.dll.a exists, I would think
>> find_library would give identical results to the case when C++ is
>> enabled (where presumably CMake is using a system location to find
>> libstdc++.dll.a).
>
> Looks like CMAKE_FIND_LIBRARY_PREFIXES and CMAKE_FIND_LIBRARY_SUFFIXES aren't 
> set up with their required values unless any of the languages are enabled.
>
> The setup is in Modules/Platform/Windows-GNU.cmake
> Which gets included from e.g. Modules/Platform/Windows-GNU-CXX.cmake.

Hi Nils:

Thanks for locating those files for me.  Furthermore, that Windows
case appears to be quite different from the Linux one which says
nothing about CMAKE_FIND_LIBRARY_PREFIXES and
CMAKE_FIND_LIBRARY_SUFFIXES in the corresponding
Modules/Platform/Linux-GNU.cmake file.

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

>
> I am curious. What is your use case for wanting to locate libstdc++ this way 
> (or at all)?

The short story is ideally this is completely useless.  :-)

Here is the longer story.

The installed PLplot C++ examples have two separate build systems. One
of those is CMake-based (which we ignore for the rest of this) and the
other is a more traditional Make + pkg-config build system whose
pkg-config and Makefiles are directly configured by cmake prior to
installation, but once those configured files are installed, cmake is
not actually used by that traditional build system.

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 any case, the current PLplot build system has some really ugly
CMake logic to find libstdc++ so that those pkg-config configuration
files could be properly configured by CMake for when the PLplot
libraries are built statically.

I noticed earlier today during tests with C++ disabled, that that ugly
code just did not work for the MinGW/MSYS case.  Which plunged me into
an investigation which lead to the question concerning the
simple test code that I asked.

Note, the pkg-config files for the C++ case are only configured when
C++ is enabled and the error in the ugly logic only occures when C++
is disabled.  So in retrospect, I just have to skip that ugly logic if
C++ is disabled (or better yet remove that ugly logic if I find out
explicit linking of libstdc++ is no longer a necessity for the
conditions stated).

But I still very much appreciate your answer since it satisfied my
curiosity about why the ugly logic worked for the Linux case but not
the MinGW/MSYS case when C++ was disabled.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________