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
__________________________
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
