igraph uses a CMake-based build system. To compile it,

The following options may be set to ON or OFF. Some of them have an AUTO setting, which chooses a reasonable default based on what libraries are available on the current system.

igraph bundles several of its dependencies (or simplified versions of its dependencies). During configuration time, it checks whether each dependency is present on the system. If yes, it uses it. Otherwise, it falls back to the bundled (“vendored”) version. In order to make configuration as deterministic as possible, you may want to disable this auto-detection. To do so, set each of the IGRAPH_USE_INTERNAL_XXX options described above. Additionally, set BLA_VENDOR to use the BLAS and LAPACK implementations of your choice. This should be the same BLAS and LAPACK library that igraph's other dependencies (e.g., ARPACK) are linked against.

For example, to force igraph to use external versions of all dependencies except plfit, and to use OpenBLAS for BLAS/LAPACK, use

$ cmake .. \
    -DIGRAPH_USE_INTERNAL_BLAS=OFF \
    -DIGRAPH_USE_INTERNAL_LAPACK=OFF \
    -DIGRAPH_USE_INTERNAL_ARPACK=OFF \
    -DIGRAPH_USE_INTERNAL_GLPK=OFF \
    -DIGRAPH_USE_INTERNAL_GMP=OFF \
    -DIGRAPH_USE_INTERNAL_PLFIT=ON \
    -DBLA_VENDOR=OpenBLAS \
    -DIGRAPH_GRAPHML_SUPPORT=ON

On Windows, shared and static builds should not be installed in the same location. If you decide to do so anyway, keep in mind the following: Both builds contain an igraph.lib file. The static one should be renamed to avoid conflict. The headers from the static build are incompatible with the shared library. The headers from the shared build may be used with the static library, but IGRAPH_STATIC must be defined when compiling programs that will link to igraph statically.

These issues do not affect Unix-like systems.

When building igraph with an internal ARPACK, LAPACK or BLAS, it makes use of f2c, which compiles and runs the arithchk program at build time to detect the floating point characteristics of the current system. It writes the results into the arith.h header. However, running this program is not possible when cross-compiling without providing a userspace emulator that can run executables of the target platform on the host system. Therefore, when cross-compiling, you either need to provide such an emulator with the CMAKE_CROSSCOMPILING_EMULATOR option, or you need to specify a pre-generated version of the arith.h header file through the F2C_EXTERNAL_ARITH_HEADER CMake option. An example version of this header follows for the x86_64 and arm64 target architectures on macOS. Warning: Do not use this version of arith.h on other systems or architectures.

#define IEEE_8087
#define Arith_Kind_ASL 1
#define Long int
#define Intcast (int)(long)
#define Double_Align
#define X64_bit_pointers
#define NANCHECK
#define QNaN0 0x0
#define QNaN1 0x7ff80000

igraph also checks whether the endianness of uint64_t matches the endianness of double on the platform being compiled. This is needed to ensure that certain functions in igraph's random number generator work properly. However, it is not possible to execute this check when cross-compiling without an emulator, so in this case igraph simply assumes that the endianness matches (which is the case for the vast majority of platforms anyway). The only case where you might run into problems is when you cross-compile for Apple Silicon (arm64) from an Intel-based Mac, in which case CMake might not realize that you are cross-compiling and will try to execute the check anyway. You can work around this by setting IEEE754_DOUBLE_ENDIANNESS_MATCHES to ON explicitly before invoking CMake.

Providing an emulator in CMAKE_CROSSCOMPILING_EMULATOR has the added benefit that you can run the compiled unit tests on the host platform. We have experimented with cross-compiling to 64-bit ARM CPUs (aarch64) on 64-bit Intel CPUs (amd64), and we can confirm that using qemu-aarch64 works as a cross-compiling emulator in this setup.