Discussion and help for Compilation problems and platform portability.

Moderator: coordinators

In my thread at http://www.luxrender.net/forum/viewtopic.php?f=22&t=8158 I ended up largely talking to myself but I have found the solution to the problem and post it here in the hope that it proves useful.

If the devs who supplied the specialised configs would consider adding this suggestion, maybe commented out with explanation, to their config files, I think it could save some folks a lot of time in the future.

The problem is that even if you specify search paths and root directories for boost libraries for cmake it still includes system paths. So after verifying that you have the required minimum libraries, if you have older libraries (in my case 1.42 on Ubuntu 11.04) cmake will happily produce a CMakeCache.txt that causes linkage to the old libraries, which in turn produces stuff like 'undefined reference to ... create_directories()' etc.

The solution is simple. Add the variable below to the config:-

SET(Boost_NO_SYSTEM_PATHS "TRUE")

Then the CMakeCache.txt is usable. (as far as boost is concerned).

Edit: This has been in since cmake 2.8.3 and any value except OFF seems to make it work (FindBoost.cmake gives OFF and TRUE).
gazzatav

Posts: 28
Joined: Wed Jan 20, 2010 6:54 pm
Location: Stockport, UK

### Re: cmake problem solved -specialized config devs please rea

Hi gazzatav,

I am not a dev therefore I have no power to push/merge it, but since I also have had issues setting things up with CMake probably, thank you for taking your time and making it better.
zsolnai

Posts: 243
Joined: Sun May 22, 2011 6:17 pm

### Re: cmake problem solved -specialized config devs please rea

Hi,

Can't you just put this line in your custom config? Using system paths is legitimate in almost all situations.

Jeanphi
jeanphi

Posts: 6577
Joined: Mon Jan 14, 2008 7:21 am

### Re: cmake problem solved -specialized config devs please rea

Yes, that is what I'm saying. That is exactly what I have done. But it took me two weeks to find the answer to the problem, so if it goes in at least one of the custom configs in the repository it could save others a lot of wasted time.

Using system paths is legitimate in almost all situations.

That's why I suggested it be commented out with an explanation of what it could be used for.

Edit: On the other hand, if you specify BOOST_SEARCH_PATH and BOOST_ROOT etc then using the system libraries for Boost is never legitimate. I'm not sure if my point has been fully understood:

1. I'm using Ubuntu 11.04 which has Boost 1.42 from the repository (I don't think that's particularly unusual).
2. I built Boost 1.49 in stage/lib.
3. I created a custom config with the correct search, root, include and library paths for Boost 1.49.
4. On running cmake it reported finding Boost 1.49.
5. On running make, without saying so, it tried to build using the version 1.42 system libraries because it had put all the system paths for Boost in CMakeCache.txt giving all sorts of undefined references to Boost functions even though it had given the impression that it was using Boost 1.49.

This was an extremely frustrating problem causing me to spend hours searching through the libraries with nm trying to check if the functions were indeed present. I also rebuilt Boost countless times in different ways to no avail. At first the only way I could fix it was to edit CMakeCache.txt which is exactly what Dade said not to do when I was advised to use a custom config. Then I found in FindBoost.cmake:

Code: Select all
#Boost_NO_SYSTEM_PATHS        Set to TRUE to suppress searching in system#                             paths (or other locations outside of BOOST_ROOT#                             or BOOST_INCLUDEDIR).  Useful when specifying#                             BOOST_ROOT. Defaults to OFF.#                             [Since CMake 2.8.3]

I just think this might help others at my level of skill in the future if it was part of one of the custom configs.
gazzatav

Posts: 28
Joined: Wed Jan 20, 2010 6:54 pm
Location: Stockport, UK