if --with_boost is specified, search *only* the specified directory h… #82
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I just discovered a problem on OS X; am working on a fix. |
|
I've updated the code to fix the problem. Should be good to go. |
…ierarchy for libraries.
Arguably, if --with_boost is specified, the user wants to use only
that boost installation, and no other. This changeset implements this
behavior.
The original code in _BOOST_FIND_LIBS prepended the --with_boost path
to the default list of paths, resulting in all of the paths being
searched if the library wasn't found in that specified by
--with_boost. Because the search for a library begins with the most
specialized version:
boost_$boost_lib_$boost_tag_$boost_mt_$boost_rtopt_$boost_ver_
boost_$boost_lib_$boost_tag_$boost_rtopt_$boost_ver_
boost_$boost_lib_$boost_tag_$boost_mt_$boost_ver_
boost_$boost_lib_$boost_tag_$boost_ver_
if the user's preferred boost installation has a less specialized
version of a library than one provided in the default path, the latter
will be chosen instead.
This may lead to a mismatch between the headers discovered in the
--with_boost hierarchy and the library discovered in the default path,
if they are for different versions of boost, leading to link problems
if the latter is for an earlier version .
Additionally, this will silently invalidate a request for a specific
version of boost in BOOST_REQUIRE, as it will be fulfilled by the
headers, but not by the library.
The new code does the following:
* It will only search the --with_boost hierarchy if that is provided;
* It will (following the suggestion of issue tsuna#49 by mateidavid) use the
absolute path to the library so that the linker's default
library paths are not searched if the library is not found in the
--with_boost hierarchy
* It adds a second path "$with_boost/lib" to the search path, as that
seems to be a standard place for libraries
N.B. There is still a potential for mishap if --with_boost is *not*
specified, namely that if there exist multiple boost installations and
some do not have all of the libraries, it is possible to end up with
libraries selected from multiple installations.
shrext_cmds is actually a quoted set of commands to generate the shared library extension, not the actual shrext itself (regardless of it initially being set directly to .so as a default).
boost_cv_inc_path can have values 'yes' and 'no' in addition to a real path, so don't use it to generate an ldpath if it's 'yes' or 'no'
If the tested ldpath = '', using it to create an absolute path to a library leads to a path in the root directory, which isn't what's intended. So don't. Additionally if ldpath = '', it's equivalent to letting the linker use only the system default paths, and there's no way of knowing in which directory the linker might find the library.
|
I've rebased the code on current master, and fixed a couple of bugs, one of which led to problems on systems where the default search path for libraries wasn't covered by the directories explicitly searched (e.g. on Debian 10 with multi-arch, where libraries are in |
koomie
added a commit
to hpcsi/grvy
that referenced
this pull request
Jan 21, 2022
provided. Needed to avoid pulling in old multi-threaded variants on TACC's frontera system that are incompatible with intel compiler. Based on PR from tsuna/boost.m4#82
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
if --with_boost is specified, search only the specified directory hierarchy for libraries.
Arguably, if --with_boost is specified, the user wants to use only
that boost installation, and no other. This changeset implements this
behavior.
The original code in _BOOST_FIND_LIBS prepended the --with_boost path
to the default list of paths, resulting in all of the paths being
searched if the library wasn't found in that specified by
--with_boost. Because the search for a library begins with the most
specialized version:
if the user's preferred boost installation has a less specialized
version of a library than one provided in the default path, the latter
will be chosen instead.
This may lead to a mismatch between the headers discovered in the
--with_boost hierarchy and the library discovered in the default path,
if they are for different versions of boost, leading to link problems
if the latter is for an earlier version .
Additionally, this will silently invalidate a request for a specific
version of boost in BOOST_REQUIRE, as it will be fulfilled by the
headers, but not by the library.
The new code does the following:
absolute path to the library so that the linker's default
library paths are not searched if the library is not found in the
--with_boost hierarchy
seems to be a standard place for libraries
N.B. There is still a potential for mishap if --with_boost is not
specified, namely that if there exist multiple boost installations and
some do not have all of the libraries, it is possible to end up with
libraries selected from multiple installations.