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

[Alan W. Irwin]

On 2014-02-03 14:03+0100 Nils Gladitz wrote:

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

Hi Nils:

The point of the traditional build system is merely to test our
installed pkg-config files.  PLplot users probably ignore that build
system and simply use our pkg-config files in the ordinary way to find
the correct compile and link flags they need to use with the PLplot
libraries. Normally the PLplot core library is a pure C library so
that is what users are used to, but in the special overall case I am
dealing with below that library also contains C++ code.  So for that
special case and version 2 of the linking model below, I cannot
dictate to our pkg-config users what compiler they use for the link.
So I think for version 2, it is better to add an explicit mention of
libstdc++ flags in the pkg-config files which allows our users to use
gcc for this special case just like they do in all other situations.

Note I completely screwed up my previous description of one linking
model (model 2 below) that we use for this overall special case and
have some questions about other linking models for this overall
special case as well.  So let me start fresh by describing various
linking models for this overall special case, and my mental model
(which needs confirmation) of the solutions in each case.

The fundamental issue for this overall special case is we have an
executable written in C that is linked to our core library containing
C++ code. The CMake-based build system for the installed examples
handles this without issues, but I need a deeper understanding of what
is going on with the linking to correctly configure the traditional
(make + pkg-config) build system for the installed examples with CMake
for three different linking models below.

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.

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.

The PLplot build systems for the installed examples currently
implement options for linking models 1 and 2 (the latter linking model
is why our build system needs to find libstdc++ to answer your
original question about use case).  Eventually we might also implement
an option for linking model 3.  So this is why I would appreciate some
confirmation of my different mental models in each of the three cases.

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
__________________________