nixpkgs/pkgs/development/libraries/boost/generic.nix

239 lines
8.4 KiB
Nix
Raw Normal View History

{ lib, stdenv, icu, expat, zlib, bzip2, python ? null, fixDarwinDylibNames, libiconv
boost*: use packaged b2 instead it of building in configurePhase If we build two things in one derivation, it becomes more complicated and its build time is extended. Therefore we should avoid this if possible. There's a good opportunity for this with boost: We have boost-build packaged already. This has the additional benefit that we can get rid of $CC_FOR_BUILD entirely in boost, meaning we don't need to rely on (as many) hacks to make boost understand our way of cross compiling. Unfortunately boost-build is not backwards compatible, so we need to build a specific boost-build for each boost derivation (the number could probably be reduced, but I'm not interested in testing a lot of boost builds at the moment). Additionally we fix a few cross compilation problems: - boost couldn't cope with different types of compilers for native and cross (as happens if useLLVM is true). Since we only use one of them per derivation, this is no longer an issue. - boost didn't find the cross ar and ranlib for compilation (since it doesn't check $AR or $RANLIB). Instead it used plain ar and ranlib form $PATH which were the native ones before. This is now fixed by setting these tools explicitly in user-config.jam (and no longer providing the native tools). With these changes, pkgsLLVM.boost builds. On darwin, instead of patching the clang-darwin.jam definition, we instead supply -rpath $out/lib via <linkflags> which causes the correct directory to be added to the libraries' rpaths, so that they find each other.
2021-08-03 21:05:12 +00:00
, boost-build
, fetchpatch
, which
, toolset ? /**/ if stdenv.cc.isClang then "clang"
else if stdenv.cc.isGNU then "gcc"
else null
2014-10-29 21:37:37 +00:00
, enableRelease ? true
, enableDebug ? false
, enableSingleThreaded ? false
, enableMultiThreaded ? true
, enableShared ? !(with stdenv.hostPlatform; isStatic || libc == "msvcrt") # problems for now
, enableStatic ? !enableShared
, enablePython ? false
, enableNumpy ? false
2014-10-29 21:37:37 +00:00
, taggedLayout ? ((enableRelease && enableDebug) || (enableSingleThreaded && enableMultiThreaded) || (enableShared && enableStatic))
, patches ? []
, useMpi ? false
, mpi
, extraB2Args ? []
2014-10-29 21:37:37 +00:00
# Attributes inherit from specific versions
, version, src
2014-11-03 19:14:08 +00:00
, ...
2014-10-29 21:37:37 +00:00
}:
# We must build at least one type of libraries
assert enableShared || enableStatic;
2014-10-29 21:37:37 +00:00
# Python isn't supported when cross-compiling
assert enablePython -> stdenv.hostPlatform == stdenv.buildPlatform;
assert enableNumpy -> enablePython;
# Boost <1.69 can't be built on linux with clang >8, because pth was removed
assert with lib; ((stdenv.isLinux && toolset == "clang" && !(versionOlder stdenv.cc.version "8.0.0")) -> !(versionOlder version "1.69"));
with lib;
2014-10-29 21:37:37 +00:00
let
variant = concatStringsSep ","
(optional enableRelease "release" ++
optional enableDebug "debug");
threading = concatStringsSep ","
(optional enableSingleThreaded "single" ++
optional enableMultiThreaded "multi");
link = concatStringsSep ","
(optional enableShared "shared" ++
optional enableStatic "static");
runtime-link = if enableShared then "shared" else "static";
# To avoid library name collisions
layout = if taggedLayout then "tagged" else "system";
# Versions of b2 before 1.65 have job limits; specifically:
# - Versions before 1.58 support up to 64 jobs[0]
# - Versions before 1.65 support up to 256 jobs[1]
#
# [0]: https://github.com/boostorg/build/commit/0ef40cb86728f1cd804830fef89a6d39153ff632
# [1]: https://github.com/boostorg/build/commit/316e26ca718afc65d6170029284521392524e4f8
jobs =
if versionOlder version "1.58" then
"$(($NIX_BUILD_CORES<=64 ? $NIX_BUILD_CORES : 64))"
else if versionOlder version "1.65" then
"$(($NIX_BUILD_CORES<=256 ? $NIX_BUILD_CORES : 256))"
else
"$NIX_BUILD_CORES";
boost*: use packaged b2 instead it of building in configurePhase If we build two things in one derivation, it becomes more complicated and its build time is extended. Therefore we should avoid this if possible. There's a good opportunity for this with boost: We have boost-build packaged already. This has the additional benefit that we can get rid of $CC_FOR_BUILD entirely in boost, meaning we don't need to rely on (as many) hacks to make boost understand our way of cross compiling. Unfortunately boost-build is not backwards compatible, so we need to build a specific boost-build for each boost derivation (the number could probably be reduced, but I'm not interested in testing a lot of boost builds at the moment). Additionally we fix a few cross compilation problems: - boost couldn't cope with different types of compilers for native and cross (as happens if useLLVM is true). Since we only use one of them per derivation, this is no longer an issue. - boost didn't find the cross ar and ranlib for compilation (since it doesn't check $AR or $RANLIB). Instead it used plain ar and ranlib form $PATH which were the native ones before. This is now fixed by setting these tools explicitly in user-config.jam (and no longer providing the native tools). With these changes, pkgsLLVM.boost builds. On darwin, instead of patching the clang-darwin.jam definition, we instead supply -rpath $out/lib via <linkflags> which causes the correct directory to be added to the libraries' rpaths, so that they find each other.
2021-08-03 21:05:12 +00:00
needUserConfig = stdenv.hostPlatform != stdenv.buildPlatform || useMpi || stdenv.isDarwin;
b2Args = concatStringsSep " " ([
2014-10-29 21:37:37 +00:00
"--includedir=$dev/include"
"--libdir=$out/lib"
"-j${jobs}"
2014-10-29 21:37:37 +00:00
"--layout=${layout}"
"variant=${variant}"
"threading=${threading}"
"link=${link}"
2015-10-15 11:57:38 +00:00
"-sEXPAT_INCLUDE=${expat.dev}/include"
"-sEXPAT_LIBPATH=${expat.out}/lib"
# TODO: make this unconditional
] ++ optionals (stdenv.hostPlatform != stdenv.buildPlatform) [
"address-model=${toString stdenv.hostPlatform.parsed.cpu.bits}"
"architecture=${toString stdenv.hostPlatform.parsed.cpu.family}"
"binary-format=${toString stdenv.hostPlatform.parsed.kernel.execFormat.name}"
"target-os=${toString stdenv.hostPlatform.parsed.kernel.name}"
# adapted from table in boost manual
# https://www.boost.org/doc/libs/1_66_0/libs/context/doc/html/context/architectures.html
"abi=${if stdenv.hostPlatform.parsed.cpu.family == "arm" then "aapcs"
else if stdenv.hostPlatform.isWindows then "ms"
else if stdenv.hostPlatform.isMips then "o32"
else "sysv"}"
] ++ optional (link != "static") "runtime-link=${runtime-link}"
++ optional (variant == "release") "debug-symbols=off"
++ optional (toolset != null) "toolset=${toolset}"
++ optional (!enablePython) "--without-python"
boost*: use packaged b2 instead it of building in configurePhase If we build two things in one derivation, it becomes more complicated and its build time is extended. Therefore we should avoid this if possible. There's a good opportunity for this with boost: We have boost-build packaged already. This has the additional benefit that we can get rid of $CC_FOR_BUILD entirely in boost, meaning we don't need to rely on (as many) hacks to make boost understand our way of cross compiling. Unfortunately boost-build is not backwards compatible, so we need to build a specific boost-build for each boost derivation (the number could probably be reduced, but I'm not interested in testing a lot of boost builds at the moment). Additionally we fix a few cross compilation problems: - boost couldn't cope with different types of compilers for native and cross (as happens if useLLVM is true). Since we only use one of them per derivation, this is no longer an issue. - boost didn't find the cross ar and ranlib for compilation (since it doesn't check $AR or $RANLIB). Instead it used plain ar and ranlib form $PATH which were the native ones before. This is now fixed by setting these tools explicitly in user-config.jam (and no longer providing the native tools). With these changes, pkgsLLVM.boost builds. On darwin, instead of patching the clang-darwin.jam definition, we instead supply -rpath $out/lib via <linkflags> which causes the correct directory to be added to the libraries' rpaths, so that they find each other.
2021-08-03 21:05:12 +00:00
++ optional needUserConfig "--user-config=user-config.jam"
++ optionals (stdenv.hostPlatform.libc == "msvcrt") [
"threadapi=win32"
] ++ extraB2Args
);
2014-10-29 21:37:37 +00:00
in
stdenv.mkDerivation {
pname = "boost";
2014-10-29 21:37:37 +00:00
inherit src version;
2019-10-26 15:39:27 +00:00
patchFlags = [];
patches = patches
++ optional stdenv.isDarwin (
if version == "1.55.0"
then ./darwin-1.55-no-system-python.patch
else ./darwin-no-system-python.patch)
# Fix boost-context segmentation faults on ppc64 due to ABI violation
++ optional (versionAtLeast version "1.61" &&
versionOlder version "1.71") (fetchpatch {
url = "https://github.com/boostorg/context/commit/2354eca9b776a6739112833f64754108cc0d1dc5.patch";
sha256 = "067m4bjpmcanqvg28djax9a10avmdwhlpfx6gn73kbqqq70dnz29";
stripLen = 1;
extraPrefix = "libs/context/";
})
2020-10-11 08:01:45 +00:00
++ optional (and (versionAtLeast version "1.70") (!versionAtLeast version "1.73")) ./cmake-paths.patch
++ optional (versionAtLeast version "1.73") ./cmake-paths-173.patch
++ optional (version == "1.77.0") (fetchpatch {
url = "https://github.com/boostorg/math/commit/7d482f6ebc356e6ec455ccb5f51a23971bf6ce5b.patch";
sha256 = "sha256-KlmIbixcds6GyKYt1fx5BxDIrU7msrgDdYo9Va/KJR4=";
stripLen = 2;
extraPrefix = "";
includes = [ "boost/math/special_functions/detail/bernoulli_details.hpp" ];
});
2014-10-29 21:37:37 +00:00
meta = {
homepage = "http://boost.org/";
2014-10-29 21:37:37 +00:00
description = "Collection of C++ libraries";
license = licenses.boost;
platforms = platforms.unix ++ platforms.windows;
badPlatforms = optional (versionOlder version "1.59") "aarch64-linux"
2021-02-25 17:23:09 +00:00
++ optional ((versionOlder version "1.57") || version == "1.58") "x86_64-darwin"
++ optionals (versionOlder version "1.73") lib.platforms.riscv;
2021-12-02 04:04:14 +00:00
maintainers = with maintainers; [ hjones2199 ];
2014-10-29 21:37:37 +00:00
};
boost*: use packaged b2 instead it of building in configurePhase If we build two things in one derivation, it becomes more complicated and its build time is extended. Therefore we should avoid this if possible. There's a good opportunity for this with boost: We have boost-build packaged already. This has the additional benefit that we can get rid of $CC_FOR_BUILD entirely in boost, meaning we don't need to rely on (as many) hacks to make boost understand our way of cross compiling. Unfortunately boost-build is not backwards compatible, so we need to build a specific boost-build for each boost derivation (the number could probably be reduced, but I'm not interested in testing a lot of boost builds at the moment). Additionally we fix a few cross compilation problems: - boost couldn't cope with different types of compilers for native and cross (as happens if useLLVM is true). Since we only use one of them per derivation, this is no longer an issue. - boost didn't find the cross ar and ranlib for compilation (since it doesn't check $AR or $RANLIB). Instead it used plain ar and ranlib form $PATH which were the native ones before. This is now fixed by setting these tools explicitly in user-config.jam (and no longer providing the native tools). With these changes, pkgsLLVM.boost builds. On darwin, instead of patching the clang-darwin.jam definition, we instead supply -rpath $out/lib via <linkflags> which causes the correct directory to be added to the libraries' rpaths, so that they find each other.
2021-08-03 21:05:12 +00:00
preConfigure = optionalString useMpi ''
cat << EOF >> user-config.jam
using mpi : ${mpi}/bin/mpiCC ;
EOF
boost*: use packaged b2 instead it of building in configurePhase If we build two things in one derivation, it becomes more complicated and its build time is extended. Therefore we should avoid this if possible. There's a good opportunity for this with boost: We have boost-build packaged already. This has the additional benefit that we can get rid of $CC_FOR_BUILD entirely in boost, meaning we don't need to rely on (as many) hacks to make boost understand our way of cross compiling. Unfortunately boost-build is not backwards compatible, so we need to build a specific boost-build for each boost derivation (the number could probably be reduced, but I'm not interested in testing a lot of boost builds at the moment). Additionally we fix a few cross compilation problems: - boost couldn't cope with different types of compilers for native and cross (as happens if useLLVM is true). Since we only use one of them per derivation, this is no longer an issue. - boost didn't find the cross ar and ranlib for compilation (since it doesn't check $AR or $RANLIB). Instead it used plain ar and ranlib form $PATH which were the native ones before. This is now fixed by setting these tools explicitly in user-config.jam (and no longer providing the native tools). With these changes, pkgsLLVM.boost builds. On darwin, instead of patching the clang-darwin.jam definition, we instead supply -rpath $out/lib via <linkflags> which causes the correct directory to be added to the libraries' rpaths, so that they find each other.
2021-08-03 21:05:12 +00:00
''
# On darwin we need to add the `$out/lib` to the libraries' rpath explicitly,
# otherwise the dynamic linker is unable to resolve the reference to @rpath
# when the boost libraries want to load each other at runtime.
+ optionalString (stdenv.isDarwin && enableShared) ''
cat << EOF >> user-config.jam
using clang-darwin : : ${stdenv.cc.targetPrefix}c++
: <linkflags>"-rpath $out/lib/"
;
EOF
''
# b2 has trouble finding the correct compiler and tools for cross compilation
# since it apparently ignores $CC, $AR etc. Thus we need to set everything
# in user-config.jam. To keep things simple we just set everything in an
# uniform way for clang and gcc (which works thanks to our cc-wrapper).
# We pass toolset later which will make b2 invoke everything in the right
# way -- the other toolset in user-config.jam will be ignored.
+ optionalString (stdenv.hostPlatform != stdenv.buildPlatform) ''
cat << EOF >> user-config.jam
boost*: use packaged b2 instead it of building in configurePhase If we build two things in one derivation, it becomes more complicated and its build time is extended. Therefore we should avoid this if possible. There's a good opportunity for this with boost: We have boost-build packaged already. This has the additional benefit that we can get rid of $CC_FOR_BUILD entirely in boost, meaning we don't need to rely on (as many) hacks to make boost understand our way of cross compiling. Unfortunately boost-build is not backwards compatible, so we need to build a specific boost-build for each boost derivation (the number could probably be reduced, but I'm not interested in testing a lot of boost builds at the moment). Additionally we fix a few cross compilation problems: - boost couldn't cope with different types of compilers for native and cross (as happens if useLLVM is true). Since we only use one of them per derivation, this is no longer an issue. - boost didn't find the cross ar and ranlib for compilation (since it doesn't check $AR or $RANLIB). Instead it used plain ar and ranlib form $PATH which were the native ones before. This is now fixed by setting these tools explicitly in user-config.jam (and no longer providing the native tools). With these changes, pkgsLLVM.boost builds. On darwin, instead of patching the clang-darwin.jam definition, we instead supply -rpath $out/lib via <linkflags> which causes the correct directory to be added to the libraries' rpaths, so that they find each other.
2021-08-03 21:05:12 +00:00
using gcc : cross : ${stdenv.cc.targetPrefix}c++
: <archiver>$AR
<ranlib>$RANLIB
;
using clang : cross : ${stdenv.cc.targetPrefix}c++
: <archiver>$AR
<ranlib>$RANLIB
;
EOF
2014-10-29 21:37:37 +00:00
'';
NIX_CFLAGS_LINK = lib.optionalString stdenv.isDarwin
"-headerpad_max_install_names";
2014-10-29 21:37:37 +00:00
enableParallelBuilding = true;
boost*: use packaged b2 instead it of building in configurePhase If we build two things in one derivation, it becomes more complicated and its build time is extended. Therefore we should avoid this if possible. There's a good opportunity for this with boost: We have boost-build packaged already. This has the additional benefit that we can get rid of $CC_FOR_BUILD entirely in boost, meaning we don't need to rely on (as many) hacks to make boost understand our way of cross compiling. Unfortunately boost-build is not backwards compatible, so we need to build a specific boost-build for each boost derivation (the number could probably be reduced, but I'm not interested in testing a lot of boost builds at the moment). Additionally we fix a few cross compilation problems: - boost couldn't cope with different types of compilers for native and cross (as happens if useLLVM is true). Since we only use one of them per derivation, this is no longer an issue. - boost didn't find the cross ar and ranlib for compilation (since it doesn't check $AR or $RANLIB). Instead it used plain ar and ranlib form $PATH which were the native ones before. This is now fixed by setting these tools explicitly in user-config.jam (and no longer providing the native tools). With these changes, pkgsLLVM.boost builds. On darwin, instead of patching the clang-darwin.jam definition, we instead supply -rpath $out/lib via <linkflags> which causes the correct directory to be added to the libraries' rpaths, so that they find each other.
2021-08-03 21:05:12 +00:00
nativeBuildInputs = [ which boost-build ]
++ optional stdenv.hostPlatform.isDarwin fixDarwinDylibNames;
buildInputs = [ expat zlib bzip2 libiconv ]
++ optional (stdenv.hostPlatform == stdenv.buildPlatform) icu
++ optional enablePython python
++ optional enableNumpy python.pkgs.numpy;
2014-10-29 21:37:37 +00:00
configureScript = "./bootstrap.sh";
configurePlatforms = [];
dontDisableStatic = true;
dontAddStaticConfigureFlags = true;
configureFlags = [
"--includedir=$(dev)/include"
"--libdir=$(out)/lib"
boost*: use packaged b2 instead it of building in configurePhase If we build two things in one derivation, it becomes more complicated and its build time is extended. Therefore we should avoid this if possible. There's a good opportunity for this with boost: We have boost-build packaged already. This has the additional benefit that we can get rid of $CC_FOR_BUILD entirely in boost, meaning we don't need to rely on (as many) hacks to make boost understand our way of cross compiling. Unfortunately boost-build is not backwards compatible, so we need to build a specific boost-build for each boost derivation (the number could probably be reduced, but I'm not interested in testing a lot of boost builds at the moment). Additionally we fix a few cross compilation problems: - boost couldn't cope with different types of compilers for native and cross (as happens if useLLVM is true). Since we only use one of them per derivation, this is no longer an issue. - boost didn't find the cross ar and ranlib for compilation (since it doesn't check $AR or $RANLIB). Instead it used plain ar and ranlib form $PATH which were the native ones before. This is now fixed by setting these tools explicitly in user-config.jam (and no longer providing the native tools). With these changes, pkgsLLVM.boost builds. On darwin, instead of patching the clang-darwin.jam definition, we instead supply -rpath $out/lib via <linkflags> which causes the correct directory to be added to the libraries' rpaths, so that they find each other.
2021-08-03 21:05:12 +00:00
"--with-bjam=b2" # prevent bootstrapping b2 in configurePhase
] ++ optional enablePython "--with-python=${python.interpreter}"
++ optional (toolset != null) "--with-toolset=${toolset}"
boost*: use packaged b2 instead it of building in configurePhase If we build two things in one derivation, it becomes more complicated and its build time is extended. Therefore we should avoid this if possible. There's a good opportunity for this with boost: We have boost-build packaged already. This has the additional benefit that we can get rid of $CC_FOR_BUILD entirely in boost, meaning we don't need to rely on (as many) hacks to make boost understand our way of cross compiling. Unfortunately boost-build is not backwards compatible, so we need to build a specific boost-build for each boost derivation (the number could probably be reduced, but I'm not interested in testing a lot of boost builds at the moment). Additionally we fix a few cross compilation problems: - boost couldn't cope with different types of compilers for native and cross (as happens if useLLVM is true). Since we only use one of them per derivation, this is no longer an issue. - boost didn't find the cross ar and ranlib for compilation (since it doesn't check $AR or $RANLIB). Instead it used plain ar and ranlib form $PATH which were the native ones before. This is now fixed by setting these tools explicitly in user-config.jam (and no longer providing the native tools). With these changes, pkgsLLVM.boost builds. On darwin, instead of patching the clang-darwin.jam definition, we instead supply -rpath $out/lib via <linkflags> which causes the correct directory to be added to the libraries' rpaths, so that they find each other.
2021-08-03 21:05:12 +00:00
++ [ (if stdenv.hostPlatform == stdenv.buildPlatform then "--with-icu=${icu.dev}" else "--without-icu") ];
2014-10-29 21:37:37 +00:00
buildPhase = ''
runHook preBuild
boost*: use packaged b2 instead it of building in configurePhase If we build two things in one derivation, it becomes more complicated and its build time is extended. Therefore we should avoid this if possible. There's a good opportunity for this with boost: We have boost-build packaged already. This has the additional benefit that we can get rid of $CC_FOR_BUILD entirely in boost, meaning we don't need to rely on (as many) hacks to make boost understand our way of cross compiling. Unfortunately boost-build is not backwards compatible, so we need to build a specific boost-build for each boost derivation (the number could probably be reduced, but I'm not interested in testing a lot of boost builds at the moment). Additionally we fix a few cross compilation problems: - boost couldn't cope with different types of compilers for native and cross (as happens if useLLVM is true). Since we only use one of them per derivation, this is no longer an issue. - boost didn't find the cross ar and ranlib for compilation (since it doesn't check $AR or $RANLIB). Instead it used plain ar and ranlib form $PATH which were the native ones before. This is now fixed by setting these tools explicitly in user-config.jam (and no longer providing the native tools). With these changes, pkgsLLVM.boost builds. On darwin, instead of patching the clang-darwin.jam definition, we instead supply -rpath $out/lib via <linkflags> which causes the correct directory to be added to the libraries' rpaths, so that they find each other.
2021-08-03 21:05:12 +00:00
b2 ${b2Args}
runHook postBuild
'';
installPhase = ''
runHook preInstall
# boostbook is needed by some applications
mkdir -p $dev/share/boostbook
cp -a tools/boostbook/{xsl,dtd} $dev/share/boostbook/
2014-10-29 21:37:37 +00:00
# Let boost install everything else
boost*: use packaged b2 instead it of building in configurePhase If we build two things in one derivation, it becomes more complicated and its build time is extended. Therefore we should avoid this if possible. There's a good opportunity for this with boost: We have boost-build packaged already. This has the additional benefit that we can get rid of $CC_FOR_BUILD entirely in boost, meaning we don't need to rely on (as many) hacks to make boost understand our way of cross compiling. Unfortunately boost-build is not backwards compatible, so we need to build a specific boost-build for each boost derivation (the number could probably be reduced, but I'm not interested in testing a lot of boost builds at the moment). Additionally we fix a few cross compilation problems: - boost couldn't cope with different types of compilers for native and cross (as happens if useLLVM is true). Since we only use one of them per derivation, this is no longer an issue. - boost didn't find the cross ar and ranlib for compilation (since it doesn't check $AR or $RANLIB). Instead it used plain ar and ranlib form $PATH which were the native ones before. This is now fixed by setting these tools explicitly in user-config.jam (and no longer providing the native tools). With these changes, pkgsLLVM.boost builds. On darwin, instead of patching the clang-darwin.jam definition, we instead supply -rpath $out/lib via <linkflags> which causes the correct directory to be added to the libraries' rpaths, so that they find each other.
2021-08-03 21:05:12 +00:00
b2 ${b2Args} install
runHook postInstall
'';
2014-10-29 21:37:37 +00:00
postFixup = ''
# Make boost header paths relative so that they are not runtime dependencies
cd "$dev" && find include \( -name '*.hpp' -or -name '*.h' -or -name '*.ipp' \) \
-exec sed '1s/^\xef\xbb\xbf//;1i#line 1 "{}"' -i '{}' \;
'' + optionalString (stdenv.hostPlatform.libc == "msvcrt") ''
$RANLIB "$out/lib/"*.a
'';
outputs = [ "out" "dev" ];
setOutputFlags = false;
2014-10-29 21:37:37 +00:00
}