| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| install_actflow [2026/05/29 12:26] – [Build instructions] rajit | install_actflow [2026/09/14 21:33] (current) – rajit |
|---|
| **MacOS:** These packages can be installed using the [[https://brew.sh/|homebrew]] package manager. Note that on recent versions of MacOS, the C++ compiler provided by Apple does not accept the ''-fopenmp'' flag for OpenMP compilation, so you will likely need to install g++ using homebrew as well. | **MacOS:** These packages can be installed using the [[https://brew.sh/|homebrew]] package manager. Note that on recent versions of MacOS, the C++ compiler provided by Apple does not accept the ''-fopenmp'' flag for OpenMP compilation, so you will likely need to install g++ using homebrew as well. |
| |
| | **Archlinux:** One of the ACT users has contributed an Archlinux [[https://aur.archlinux.org/packages/actflow-git |package]]. |
| ==== Build instructions ==== | ==== Build instructions ==== |
| |
| |
| |
| **actsim and Xyce:** The ACT simulator also supports mixed analog/digital simulation using "Xyce". To include this feature, follow the instructions above. After that, follow the instructions provided by the [[https://github.com/asyncvlsi/actsim|''actsim'']] repository to re-build and re-install ''actsim''. | **actsim and Xyce:** The ACT simulator also supports mixed analog/digital simulation using [[https://xyce.sandia.gov/|Xyce]]. To include this feature, follow the instructions above. After that, follow the instructions provided by the [[https://github.com/asyncvlsi/actsim|actsim]] repository to re-build and re-install ''actsim''. |
| |
| **Building from source.** Sometimes it is not possible to use package managers to install the required dependencies. In this case, the standard approach that we use is to install the missing dependencies by setting the install directory to ''$ACT_HOME''. GNU autotools normally support the ''--prefix=$ACT_HOME'' option to their ''configure'' script, and CMake supports ''-DCMAKE_INSTALL_PREFIX=$ACT_HOME''. | **Building from source.** Sometimes it is not possible to use package managers to install the required dependencies. In this case, the standard approach that we use is to install the missing dependencies by setting the install directory to ''$ACT_HOME''. GNU autotools support the ''--prefix=$ACT_HOME'' (two hyphens before ''prefix'') option to the generated ''configure'' script, and CMake supports ''-DCMAKE_INSTALL_PREFIX=$ACT_HOME''. |
| |
| | === Environment variables === |
| | |
| | The following environment variables are used during the build process: |
| | * ''ACT_HOME'': see above; this is used as the installation directory for the tools and supporting files. |
| | * ''CXX'': used as the C++ compiler. Note that the build script checks if the C++ compiler supports various options that are used by different tools. |
| | * ''ACTFLOW_EXTRA_CFLAGS'': this passes in additional compiler flags (augments the standard ''CFLAGS'' environment variable). |
| | * ''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. |
| |
| |
| |
| For Alpine Linux look at the alpine section in the yml file. | 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). | |
| |
| ==== OpenMP message ==== | ==== OpenMP message ==== |
| 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. | 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. |