boost.m4 icon indicating copy to clipboard operation
boost.m4 copied to clipboard

if --with_boost is specified, search *only* the specified directory h…

Open djerius opened this issue 9 years ago • 3 comments

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:

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 #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.

djerius avatar Jan 27 '16 21:01 djerius

I just discovered a problem on OS X; am working on a fix.

djerius avatar Jan 27 '16 23:01 djerius

I've updated the code to fix the problem. Should be good to go.

djerius avatar Jan 28 '16 15:01 djerius

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 /usr/lib/x86_64-linux-gnu/)

djerius avatar Aug 27 '19 22:08 djerius