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 __________________________ -- 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
