Re: [cmake-developers] How does CMake know when to use the rpath option in the build tree with a combination of static internal and shared external libraries?
On 2019-02-08 15:19-0800 Alan W. Irwin wrote: So all is well with that C example, but I would like to know *how* CMake knew (for the build tree case) that the rpath option was needed. Having thought some more about this, I now assume the CMake build-tree algorithm is if the library is specified with a full path, and that location is non-standard use rpath/runpath (regardless of whether the the library referred to sets rpath/runpath or not). And I have also confirmed from several different web sources that the internal property rpath is transitive while the internal propery runpath is non-transitive. So I assume for linkers (such as the one for Debian Testing) that transform external -rpath options to runpath internally, it is no longer possible to be quite so sloppy, i.e., it is best to specify the rpath option following the normal transitive (e.g., for static internal libraries) and non-transitive (e.g., for shared external libraries) rules that are used for linking. But could someone here please confirm (or correct) these assumptions? Once I have the requested confirmation of my assumptions (or else a set of corrected assumptions) from someone here, then I think it should be straightforward for me to deal with the peculiar static OCaml case where I have discovered that internal runpath (for Debian Testing) versus internal rpath (for Debian Jessie) appears to make a crucial difference. Alan __ Alan W. Irwin 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: https://cmake.org/mailman/listinfo/cmake-developers
[Cmake-commits] CMake branch, master, updated. v3.14.0-rc1-36-ge7d3197
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via e7d319714d3b45bf6ce94cab04fc4cc6f20032eb (commit) from 2f2295ec9ec35632b89213ed857e3bae4398f998 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e7d319714d3b45bf6ce94cab04fc4cc6f20032eb commit e7d319714d3b45bf6ce94cab04fc4cc6f20032eb Author: Kitware Robot AuthorDate: Sun Feb 10 00:01:05 2019 -0500 Commit: Kitware Robot CommitDate: Sun Feb 10 00:01:05 2019 -0500 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 7487622..3f20777 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,5 +1,5 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 14) -set(CMake_VERSION_PATCH 20190209) +set(CMake_VERSION_PATCH 20190210) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
[CMake] OBJECT libraries getting fully support?
Hi all; I saw an email to the list from Chuck Atkins in the summer of 2017 suggesting that OBJECT libraries were being enhanced and could become fully-functional libraries hopefully sometime that year. I'm wondering if that ever actally happened and if so what release of cmake it was in, and if not is there still a plan for this sometime? I'm trying to convert a large and complex cmake environment originally started in 2007 or so, which uses all old-school cmake facilities, to use modern cmake methods. I have a situation where we have a library containing basic methods which can be implemented multiple ways and different executables use different implementations. However these methods are used by all sorts of static libraries as well. Since we don't know until executable link time which library to use, the static libraries cannot depend on the base library: it has to be listed only in the executable's target_link_libraries. But of course because the static libraries use them as well we need the base library to be listed last (or near last) in the link line else we get undefined symbols. Adding the base library to the executable TLL doesn't allow us to do that. So I was thinking of making this base library an OBJECT library so it would always be fully linked but it seems that our version of cmake doesn't allow an OBJECT library to be used as a normal library and I'd be reduced to adding lots of generator expressions for it everywhere which is a huge PITA. Any ideas on how best to address this situation, if OBJECT libraries are not supported yet? -- 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: https://cmake.org/mailman/listinfo/cmake
