Setting up Boost_ARCHITECTURE variable in CMakeLists.txt

[smuroff]

I've a suggestion to explicitly set up Boost_ARCHITECTURE variable in CMakeLists.txt

if (CMAKE_SYSTEM_PROCESSOR MATCHES "(x86)|(X86)|(amd64)|(AMD64)")
    set(Boost_ARCHITECTURE "-x64")
else()
    set(Boost_ARCHITECTURE "-x32")
endif()

This will allow CMake to find Boost libraries with "-x64" or "-x32" suffixes. (I've compiled both architectures and this helps me to avoid "Unable to find the requested Boost libraries" error).

[KevinWMatthews]

@pr0minence Interesting - I think this is a use case that we didn't consider.

A few questions to help us craft a better solution:

• What OS(es) are you using?
• What version of CMake are you using?

Can you explain your specific setup a little bit more? Two machines, a virtual machine, etc. I'm curious to know how you're using both 64 and 32 bit libraries.

Also, can you provide the complete CMake output when it fails to find Boost?

Thanks!

[smuroff]

@KevinWMatthews, sure!

Machine specs:

Processor: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
Windows Version: Microsoft Windows 10 64-bit

I am using Cmake 3.14 and here is CMake output with error:

[cmake]   CMake Error at C:/Develop/CMake/share/cmake-3.14/Modules/FindBoost.cmake:2124 (message):
[cmake]   Unable to find the requested Boost libraries.
[cmake] 
[cmake]   Boost version: 1.69.0
[cmake] 
[cmake]   Boost include path: C:/Develop/Boost/include/boost-1_69
[cmake] 
[cmake]   Could not find the following static Boost libraries:
[cmake] 
[cmake]           boost_unit_test_framework
[cmake]           boost_date_time
[cmake] 
[cmake]   No Boost libraries were found.  You may need to set BOOST_LIBRARYDIR to the
[cmake]   directory containing Boost libraries or BOOST_ROOT to the location of
[cmake]   Boost.
[cmake]   Call Stack (most recent call first):
[cmake]   CMakeLists.txt:14 (find_package)

As I said before, I've compiled Boost libraries. For example:

libboost_unit_test_framework-mgw81-mt-x32-1_69.a
libboost_unit_test_framework-mgw81-mt-x64-1_69.a

Cmake looking for libs without 'suffixes' by default:
[ C:/Develop/CMake/share/cmake-3.14/Modules/FindBoost.cmake:1833 ] Searching for UNIT_TEST_FRAMEWORK_LIBRARY_RELEASE: libboost_unit_test_framework-mgw81-mt-1_69;libboost_unit_test_framework-mgw81-mt;libboost_unit_test_framework-mt-1_69;libboost_unit_test_framework-mt;libboost_unit_test_framework-mt;libboost_unit_test_framework

And here is what cmake looking for with

set(Boost_ARCHITECTURE "-x64")

[cmake] [ C:/Develop/CMake/share/cmake-3.14/Modules/FindBoost.cmake:1833 ] Searching for UNIT_TEST_FRAMEWORK_LIBRARY_RELEASE: libboost_unit_test_framework-mgw81-mt-x64-1_69;libboost_unit_test_framework-mgw81-mt;libboost_unit_test_framework-mt-x64-1_69;libboost_unit_test_framework-mt;libboost_unit_test_framework-mt;libboost_unit_test_framework

[KevinWMatthews]

@pr0minence Awesome, thank you!

I see - Windows adds an architecture-specific string to the library name itself (x64 vs x32).

It looks like the Boost_ARCHITECTURE variable is a recent addition to CMake - it's present in the v3.13 docs but not in v3.12. Similarly, Boost_ARCHITECTURE is present in the v3.13 source but lacking in the v3.12 source.

This shows that the underlying problem you're seeing is real and widespread - CMake itself fixed it. Using the new flag is a good solution but isn't complete for our use case. It won't help out users with an older version of CMake. We're trying to support back to CMake v3.1....

Do you have any ideas on how this could be solved for Windows users with an older version of CMake? I have some homework to do myself.

[arcuru]

I'm not a CMake expert by any means, but as far as the track goes:

The instructions for Windows are wildly complicated and/or out of date. I am almost certain that you can do all the exercises by using the exercism cli tool to download/upload the solutions, and using Visual Studio to install boost and build the tests. I just haven't gotten around to testing that out and fixing the README.

Basically what I'm saying is, if this is only a Windows issue it might be more beneficial to just ignore boost/cmake on Windows and rewrite the instructions to use Visual Studio.

(If you wanted to actually do the exercises on windows outside of Visual Studio, I highly suggest just using WSL to build and test, and you can edit the files using the IDE of your choice).

[smuroff]

@patricksjacksonб you're absolutely right, but it's not a Windows only problem. The problem cause of I'm not prepared my c++ workspace using official instructions (because I'm already had mingw-w64 compiler and boost libraries). Similar situations can happen sometimes, because of people like me :)

@KevinWMatthews, as @patricksjackson said, we can rewrite the instructions to clarify this. And we may write some new instructions to other compilers (mingw, clang, etc.)

[KevinWMatthews]

Can mingw run on Linux/Mac? I saw some hints that it could be run on Unix systems - I didn't realize that.

I wonder if Boost with Visual Studio follows the same naming convention. VS probably handles all the details?

I also wonder how Cygwin behaves, but that's a completely new subject.

I thought that clang would behave much like gcc, at least on Linux. After looking at the Find Boost module, I'm no longer sure.

CMake looks to handle the architecture differently starting with version 1.66. I'm curious to load a Unix system with a new version and see the naming convention.

Point being, there's a lot of detail to consider.
Will definitely keep this in mind for updating instructions.

[KevinWMatthews]

@pr0minence just had an idea. Does CMake work properly if you pass it a configuration option?

From the command line, it could be something like:

$ cmake -DBoost_ARCHITECTURE=-x64

or possibly

$ cmake -DBoost_ARCHITECTURE="-x64"

[smuroff]

@KevinWMatthews Yeah, it works fine.
$ cmake . -DBoost_ARCHITECTURE=-x64

[KevinWMatthews]

@pr0minence Thanks! Obvious in retrospect but useful as a sanity check.

If we can't figure something out in the CMakeLists.txt file, we could always note that in documentation.

I'd like to see if Linux systems append -x64 or -x32 to the Boost library filenames like mingw does. I'm still thinking about how we could use your original recommendation... it would be very convenient.

[smuroff]

@KevinWMatthews this suffixes (-x32, -x64) appear, when you specialize build agruments (architecture and address-model, see here and here) while compiling boost. This is crossplatform feature. You can see here an example for Arch Linux.

[KevinWMatthews]

Hi @pr0minence
Thank you! Those are useful links.

General question: what would happen if someone has a new version of CMake (3.13, 3.14) but an older version of Boost (1.65)? If we see the Boost_ARCHITECTURE flag, would CMake insert -x86 in the .so filename and then fail to find it? Is CMake smart enough to avoid doing that?

Maybe it's an irrelevant concern - I'm still piecing together the details of how the Boost ecosystem works.

[KevinWMatthews]

Data points below.

Looks like Arch Linux stays very up-to-date. They're on Boost 1.69, while testing Debian (buster) is on Boost 1.67 and stable Debian (stretch) is on Boost 1.62.

I think (?) that the architecture suffix is new to Boost 1.66, which is why it isn't supported in older versions of CMake. See Boost's 1.65 Windows docs and 1.66 Windows docs. Do you see the same thing?

The Boost docs state the same thing in the 1.65 Unix docs and the 1.66 Unix docs.

My Ubuntu 18 distro doesn't follow the -x86 naming convention, but it installs Boost 1.65:

libboost_unit_test_framework.so.1.65.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so.1.65.1
libboost_unit_test_framework.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so

I just spun up a Docker container of Debian Buster and installed Boost 1.67. It too doesn't follow the -x86 convention:

libboost_unit_test_framework.so.1.67.0 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so.1.67.0
libboost_unit_test_framework.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so

mingw follows Boost's naming convention but Debian doesn't?

I'd like to experiment with a few different versions of CMake and Boost to make sure that specifying the architecture doesn't break anything, but I'm out of time for now. As I think about it, the CMake guys are probably aware of this and handle it properly.

[smuroff]

I tend to think adding a Boosr_ARCHITECTURE variable just tell CMake to try to find some library with/without -x86, -x32, etc.

You can run the following command to see what it actually searching:

$ cmake -DBoost_DEBUG=1

Searching for UNIT_TEST_FRAMEWORK_LIBRARY_RELEASE: libboost_unit_test_framework-mgw81-mt-x64-1_69;libboost_unit_test_framework-mgw81-mt;libboost_unit_test_framework-mt-x64-1_69;libboost_unit_test_framework-mt;libboost_unit_test_framework-mt;libboost_unit_test_framework`

[KevinWMatthews]

@pr0minence ,
Excellent, thank you. That's convincing output - you look to be exactly correct.

To summarize:

• Newer versions of CMake with newer versions of Boost (>= 1.66) will use Boost_ARCHITECTURE and search both with and without the -x86/-x32 flags.
• Newer versions of CMake with older versions of Boost will use the Boost_ARCHITECTURE flag appropriately. This is controlled by CMake.
• Older versions of CMake with newer versions of Boost will ignore the Boost_ARCHITECTURE flag entirely. Users should upgrade CMake - old CMake with new Boost is a known issue which we need to document.
• Older version so CMake with older versions of Boost should be find, provided the two are kept in sync.

Does that sound accurate?

On a side note, the Boost docs say that the Boost_ARCHITECTURE "Default is auto-computed for the C++ compiler in use." I wonder why it doesn't auto-compute with the mingw setup on your machine? Huh.

I'm happy to create a pull request from your original suggestion but if you'd like to contribute directly you're welcome to create one yourself. There are a lot of CMake files to update... up to you!

Thanks for providing so much detail! You've been very useful (and patient).

[smuroff]

@KevinWMatthews, nice conclusion!

On a side note, the Boost docs say that the Boost_ARCHITECTURE "Default is auto-computed for the C++ compiler in use." I wonder why it doesn't auto-compute with the mingw setup on your machine? Huh.

CMake computes as possible, but not for all compilers. (here)

I hope the following will work:

set(Boost_ARCHITECTURE "")
string(TOLOWER ${CMAKE_HOST_SYSTEM_PROCESSOR} CURRENT_PROCESSOR_ARCHITECTURE)
if(CURRENT_PROCESSOR_ARCHITECTURE STREQUAL amd64 OR CURRENT_PROCESSOR_ARCHITECTURE STREQUAL x86_64)
    string(APPEND Boost_ARCHITECTURE "-x64")
else()
    string(APPEND Boost_ARCHITECTURE "-x32")
endif()

How can we test this before I make pull request? Thanks.