-
-
Notifications
You must be signed in to change notification settings - Fork 211
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
C++: CMake not working with Homebrew Boost on OSX #217
Comments
Hi @araybold , That's odd - CMake finds Boost and all three libraries but then fails to link them into the target. Typically I'm curious to see what happens if I rig up a Docker container with Boost 1.68.0 and your version of CMake. What version of CMake are you using? |
Can you add some print statements to message(STATUS "---------------------")
message(STATUS "Boost_FOUND: ${Boost_FOUND}")
message(STATUS "Boost_INCLUDE_DIRS: ${Boost_INCLUDE_DIRS}")
message(STATUS "Boost_LIBRARY_DIRS: ${Boost_LIBRARY_DIRS}")
message(STATUS "Boost_LIBRARIES: ${Boost_LIBRARIES}")
message(STATUS "---------------------") This needs to be placed after the call to |
My CMake version is 3.7.2. This is the full output from running CMake with the CMakeLists.txt modified as you asked:
These are the Boost unit test framework libraries available in /usr/local/lib:
I see that the messages I added only show the *-mt.a form of the library. If I am following correctly, the exercise will need the dynamic library for at least unit_test_framework, though this may be moot until CMake can agree with itself about whether it has found some version of the required Boost libraries. At the command line, without using CMake, I have successfully built and run a test program that uses dynamically-linking versions of these Homebrew-installed Boost libraries, though I have not yet tried building a unit test framework program. |
You're right, your example doesn't actually link against Boost's unit test library. If you compile this: #define BOOST_TEST_MAIN
#include <boost/test/unit_test.hpp>
BOOST_AUTO_TEST_CASE(test_hello)
{
BOOST_REQUIRE_EQUAL("Hello, World!", "should fail");
} without any flags $ g++ <filename> I'm guessing it will throw a healthy set of linker errors. My Linux box needs: $ g++ <filename> -lboost_unit_test_framework I have boost installed to system so I don't need to add That should link, but likely fails to compile: `undefined reference to 'main'` It seems that $ g++ <filename> -lboost_unit_test_framework --static The program should run but the test will fail:
|
Interesting, I think this is the root of the problem:
It looks like CMake 3.7.2 doesn't support Boost 1.68.0. I've heard of some history here [it might even be accurate ;)]. In an ideal world, Boost would provide explicit CMake support; it's their package so they know best what is required to link against each version. Apparently they don't, so CMake itself steps up and builds in a module, The most straightforward solution is to upgrade CMake. Is that feasible for your system? I think it's possible to install a second version of CMake on a system without ill effects (I did it in a container), but then you need to remember to use the correct executable. If so, think version 3.12 should work. There is a reference to this issue on Stack Overflow. This states that 3.13 is required, but FindBoost.cmake from version 3.12 looks like it will to work. |
Thanks - upgrading CMake (to the current Homebrew version, 3.13.4) solved this problem. Perhaps the instructions could be modified to prominently note the cross-dependency between Boost and CMake, as, in my case, each was more recent than its individual oldest viable version. While this is somewhat off-topic, I have found that one can link statically by explicitly specifying the full paths of the Boost libraries you want to link from (this is how CMake does it.) If you try using -L and -l, the dynamic libraries will be used instead, as they are in the same directory, and dynamic linking is the default. If you try to change this with -static, it is missing at least crt0.o (the C(++) runtime?), which is not available in static form. One can use -L and -l (without -static) by creating a separate directory containing only the static Boost libraries (or links to them, which will be advantageous when one upgrades Boost).
|
@araybold Glad that fixed the issue. Documenting the Boost/CMake interplay is a good idea. Long term we're considering moving away from Boost because it tends to be difficult to configure. Interesting - using |
After installing Homebrew boost, running CMake with the generator 'Unix Makefiles' produces this error:
Similarly for date_time and regex.
There does not seem to be anything unusual about where the libraries are:
I am able to compile and link a working program using boost from the command line, without any arguments to specify the location of headers or libraries:
The text was updated successfully, but these errors were encountered: