All Articles

Building IfcOpenShell on MacOS

Building someone else’s CPP libraries is never high on my list of fun things to do, since it often goes particularly pear-shaped on Mac due to unknown symlinks (and it can be difficult to chase down which flags need to be set manually). I also have resigned myself (for better or for worse) to only use Homebrew, and I don’t use Conda. This is more about reducing potential sources of error on my end, rather than being married to a specific setup. This is all to say that I probably made things harder for myself than I had to for this project, but I learned a few things along the way.

I’ve wanted for a while to muck around with IFCOpenShell and BlenderBIM, so I finally got it to build on MacOS Big Sur v11.4 without following the default instructions (though there aren’t any specifically for MacOS to begin with).

Prerequisites

I installed the following packages (or already had them installed) to fulfill the required dependencies

brew install boost
brew install swig
brew install git
brew install cmake
brew install ftgl
brew install cgal
brew install gmp
brew install libaec

Versions installed:

boost: stable 1.76.0
swig: stable 4.0.2
git: stable 2.33.0
cmake: stable 3.21.2
ftgl: stable 2.1.3-rc5
cgal: stable 5.3
gmp: stable 6.2.1
libaec: stable 1.0.6

After attempting to build OCE based on these instructions, I ended up just doing brew install opencascade, which gave me a working version of OCCT. As a general FYI, OCE is no longer available in Homebrew-science, as indicated in the instruction linked above.

Version installed:

opencascade: stable 7.5.3

Cloning the repo

IFCOpenShell 0.7.0 now has submodules that need to be cloned and built for the build process to run. You can clone submodules by doing the following

git clone --recurse-submodules https://github.com/IfcOpenShell/IfcOpenShell.git

Building IfcOpenShell

I didn’t build with COLLADA support, so my commands looked like this:

$ cd /path/to/IfcOpenShell
$ mkdir build && cd build
$ cmake ../cmake -DOCC_LIBRARY_DIR=/usr/local/lib/ \
      -DOCC_INCLUDE_DIR=/usr/local/include/opencascade/ \
      -DCOLLADA_SUPPORT=0 \
      -DCGAL_INCLUDE_DIR=/usr/local/include/ \
      -DGMP_LIBRARY_DIR=/usr/local/lib/ \
      -DMPFR_LIBRARY_DIR=/usr/local/lib

$ make -j8 -lboost_options

My commands differ a bit from the IFCOpenShell instructions. I found that I did need to add -DOCC_INCLUDE_DIR as an explicit env variable, and I nuked my memory twice before I figured out I needed to pass a process limit value to make -j, as well as adding the -lboost_options flag to avoid getting undefined symbols for architecture x86_64 errors based on boost.

When using Homebrew packages, you might get some errors about missing library files when running cmake. The best way to troubleshoot this is to take a look at the CMakeList.txt file noted and set the offending directory manually as a flag passed to cmake. On MacOS, Homebrew puts its library files inside /usr/local/lib rather than /usr/lib, which is what cmake is usually expecting.

The final snag I ran into was due to having installed gcc via brew (primarily because the XCode gcc does not allow you to compile (easily) with OpenMP enabled. I’ve used OpenMP for some Cython builds, so Homebrew’s version is set as the default compiler in my .zshrc file. I’m still not sure why turning this off and building using XCode’s gcc worked, but it did. I got several undefined symbols for architecture_x86_64 errors at the tail end of the build when linking IfcGeomServer. My output using XCode’s gcc is below:

mclare@mclares-MacBook-Pro build % gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 12.0.5 (clang-1205.0.22.11)
Target: x86_64-apple-darwin20.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Published Sep 18, 2021

Striving to stay curious.