Differences

This shows you the differences between two versions of the page.

--- install_actflow [2026/09/13 21:21] – [MacOS] rajit
+++ install_actflow [2026/09/26 14:42] (current) – [Build instructions] rajit
@@ Line 63: / Line 63: @@
    * ''BOOST_ROOT'': if your Boost installation is in a non-standard place (e.g. you had to install your own version because the system version was too old and can't be modified), this should point to the root of your installation directory for Boost.
+<block 75%:0:#FFFFCC;black;1px dotted black;auto/10ptrounded>**Tip:** When the build is complete, a text file ''$ACT_HOME/actflow_git_rev'' is created that contains the Git commit ID of the revision used for the build.</block>
 ===== Microsoft Windows =====
@@ Line 98: / Line 99: @@
 For Alpine Linux look at the alpine section in the yml file.
-==== MacOS ====
-Recent versions of MacOS have a C++ compiler issue, namely that the default compiler distributed by Apple does not support the "-fopenmp" flag. To fix this issue, we normally install either ''llvm'' or ''g++'' using homebrew. This normally results in the compiler being installed in a path that looks something like ''/opt/homebrew/Cellar/llvm/<version>/bin/clang++'' or ''/opt/homebrew/Cellar/gcc/<version>/bin/g++-<version>''. Set the environment variable ''CXX'' to the absolute path name of this C++ compiler before running "./build".
-More recent versions of LLVM have problems with linking.  If you see messages like this:
-<code>
-Undefined symbols for architecture arm64:
-  "std::__1::__hash_memory(void const*, unsigned long)", referenced from:
-  ...
-</code>
-then chances are you have a known issue in recent LLVM versions on MacOS ([[https://github.com/llvm/llvm-project/issues/155606|github issue]]).  The workaround that fixes this at least for the actflow build (see the discussion for details, this may not necessarily be a proper fix) is to edit the ''.cfg'' file installed with LLVM to include
-the location of the LLVM C++ standard library. The [[https://github.com/llvm/llvm-project/issues/155606|github issue]] has details and various workarounds, and the root cause appears to be that while the LLVM compiler uses a specific algorithm to find include paths, it uses a different one to find libraries; so the system C++ standard library is being used instead of the LLVM-provided C++ standard library. Explicitly including the LLVM-provided library fixes this issue in the build.
-For example, on a recent MacOS/homebrew setup, this required editing ''.cfg'' files in ''/opt/homebrew/etc/clang/'', replacing the line ''-i sysroot /Library/Developer/CommandLineTools/SDKs/MacOSX26.sdk'' with
-''/opt/homebrew/opt/llvm/lib/c++/libc++.1.0.dylib -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX26.sdk'' (see the github issue for details).
-More recently, the recommended solution is to simply install ''gcc'' using homebrew, and then set the ''CXX'' environment  variable to ''/opt/homebrew/opt/gcc/bin/g++-16'' (or whatever the ''g++'' version you have installed using ''brew'').
 ==== OpenMP message ====
@@ Line 160: / Line 144: @@
 Tie build script tries to compile this with and without the ''-lstdc++fs'' option (needed for some older C++ compilers, but no longer needed in a modern compiler). This message means both options did not succeed using the compiler that supported the ''-fopenmp'' flag.
+==== MacOS ====
+Recent versions of MacOS have a C++ compiler issue, namely that the default compiler distributed by Apple does not support the "-fopenmp" flag. To fix this issue, we normally install either ''llvm'' or ''g++'' using homebrew. This normally results in the compiler being installed in a path that looks something like ''/opt/homebrew/Cellar/llvm/<version>/bin/clang++'' or ''/opt/homebrew/Cellar/gcc/<version>/bin/g++-<version>''. Set the environment variable ''CXX'' to the absolute path name of this C++ compiler before running "./build".
+=== More recent LLVM versions ===
+More recent versions of LLVM have problems with linking.  If you see messages like this:
+<code>
+Undefined symbols for architecture arm64:
+  "std::__1::__hash_memory(void const*, unsigned long)", referenced from:
+  ...
+</code>
+then chances are you have a known issue in recent LLVM versions on MacOS ([[https://github.com/llvm/llvm-project/issues/155606|github issue]]).  The workaround that fixes this at least for the actflow build (see the discussion for details, this may not necessarily be a proper fix) is to edit the ''.cfg'' file installed with LLVM to include the location of the LLVM C++ standard library.
+The [[https://github.com/llvm/llvm-project/issues/155606|github issue]] has details and various workarounds, and the root cause appears to be that while the LLVM compiler uses a specific algorithm to find include paths, it uses a different one to find libraries; so the system C++ standard library is being used instead of the LLVM-provided C++ standard library. Explicitly including the LLVM-provided library fixes this issue in the build.
+For example, on a recent MacOS/homebrew setup, this required editing ''.cfg'' files in ''/opt/homebrew/etc/clang/'', replacing the line
+<code>
+-i sysroot /Library/Developer/CommandLineTools/SDKs/MacOSX26.sdk
+</code>
+ with
+<code>
+/opt/homebrew/opt/llvm/lib/c++/libc++.1.0.dylib -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX26.sdk
+</code>
+(See the github issue for more details as to why this works). If you are not sure which ''.cfg'' file to edit, running ''clang++'' with ''-v'' will show you which file is being used (as ''Configuration file:'').
+If you downgrade your LLVM installation to, say, ''llvm@22'', it is possible that the OpenMP libraries are still not found. To correct this, the ''.cfg'' file edit looks something like this:
+<code>
+/opt/homebrew/opt/llvm@22/lib/c++/libc++.1.0.dylib -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX26.sdk -I/opt/homebrew/include -L/opt/homebrew/lib
+</code>
+=== Using GNU C++ ===
+More recently, the recommended solution is to simply install ''gcc'' using homebrew, and then set the ''CXX'' environment  variable to ''/opt/homebrew/opt/gcc/bin/g++-16'' or something similar---i.e. to the absolute path to the ''g++'' version installed by ''brew''. If you are switching over from an LLVM-based compiler toolchain to a GNU based compiler toolchain (or vice versa), we recommend starting from a blank ACT install path and a fresh actflow checkout to avoid C++ ABI issues.
+Using ''g++'' can lead to linking errors in Dali. This occurs if you have installed pre-built Qt6 libararies (used by the Dali GUI, but only if Qt6 is found), because those are normally built with LLVM and will cause errors because of incompatibilities between ''g++'' and LLVM C++ libraries. To resolve this, you will have to install a version of Qt6 that is built using ''g++'', or disable the GUI in Dali. To disable Dali's GUI, edit ''Dali/cmake/ConfigureQtGui.cmake'' and replace (around line 15)
+<code>
+set(DALI_HAS_QT_GUI FALSE)
+</code>
+with
+<code>
+set(DALI_HAS_QT_GUI FALSE)
+return()
+</code>
+which will force it to not build the GUI even if Qt6 libraries are found.