tweag / rules_nixpkgs

Rules for importing Nixpkgs packages into Bazel.
Apache License 2.0
283 stars 81 forks source link

darwin: "Linking .../libsupport.a [for tool] failed: (Exit 1): false failed" toolchain missing tools #368

Closed Strum355 closed 1 year ago

Strum355 commented 1 year ago

Is your feature request related to a problem? Please describe. Using clang or gcc fails when building https://github.com/sourcegraph/scip-clang using nixpkgs provided toolchain via rules_nixpkgs. Progress/repro case can be found here: https://github.com/sourcegraph/scip-clang/commit/e17078a5b6d4d2e52796ae0c318cdc0b5a23bc31

Describe the solution you'd like

We currently use https://github.com/grailbio/bazel-toolchain for https://github.com/sourcegraph/scip-clang, which I want to experiment replacing with nixpkgs provided toolchains.

Additional context

Example errors from e.g. bazelisk build //...

ERROR: /private/var/tmp/_bazel_noah/415228bb906a2ca0d2de8484c4c71f9b/external/llvm-project/clang/BUILD.bazel:1712:11: Linking external/llvm-project/clang/libsupport.a [for tool] failed: (Exit 1): false failed: error executing command (from target @llvm-project//clang:support) /nix/store/qr4zarpiaf3fk2bm01gnb33grg2nwwrh-coreutils-9.1/bin/false @bazel-out/darwin_arm64-opt-exec-C7777A24/bin/external/llvm-project/clang/libsupport.a-2.params
ERROR: /private/var/tmp/_bazel_noah/415228bb906a2ca0d2de8484c4c71f9b/external/llvm-project/llvm/BUILD.bazel:152:11: Linking external/llvm-project/llvm/libDemangle.a [for tool] failed: (Exit 1): false failed: error executing command (from target @llvm-project//llvm:Demangle) /nix/store/qr4zarpiaf3fk2bm01gnb33grg2nwwrh-coreutils-9.1/bin/false @bazel-out/darwin_arm64-opt-exec-C7777A24/bin/external/llvm-project/llvm/libDemangle.a-2.params

Output from bazelisk build @toolchain-darwin-aarch64_info//:CC_TOOLCHAIN_INFO (note all the missing tools replaced with false)

TOOL_NAMES:objdump:gcov:ld:nm:dwp:ar:cpp:objcopy:strip:libtool:llvm-cov:gcc
TOOL_PATHS:/nix/store/qr4zarpiaf3fk2bm01gnb33grg2nwwrh-coreutils-9.1/bin/false:/nix/store/qr4zarpiaf3fk2bm01gnb33grg2nwwrh-coreutils-9.1/bin/false:/nix/store/wqfyaymrsckr03xibcc2zd6kjqq4d3r7-clang-wrapper-15.0.7/bin/ld:/nix/store/wqfyaymrsckr03xibcc2zd6kjqq4d3r7-clang-wrapper-15.0.7/bin/nm:/nix/store/qr4zarpiaf3fk2bm01gnb33grg2nwwrh-coreutils-9.1/bin/false:/nix/store/wqfyaymrsckr03xibcc2zd6kjqq4d3r7-clang-wrapper-15.0.7/bin/ar:/nix/store/wqfyaymrsckr03xibcc2zd6kjqq4d3r7-clang-wrapper-15.0.7/bin/cpp:/nix/store/qr4zarpiaf3fk2bm01gnb33grg2nwwrh-coreutils-9.1/bin/false:/nix/store/wqfyaymrsckr03xibcc2zd6kjqq4d3r7-clang-wrapper-15.0.7/bin/strip:/nix/store/qr4zarpiaf3fk2bm01gnb33grg2nwwrh-coreutils-9.1/bin/false:/nix/store/qr4zarpiaf3fk2bm01gnb33grg2nwwrh-coreutils-9.1/bin/false:/nix/store/wqfyaymrsckr03xibcc2zd6kjqq4d3r7-clang-wrapper-15.0.7/bin/cc
CXX_BUILTIN_INCLUDE_DIRECTORIES:/nix/store/0xjfx5w9xhnsx2hharl3mpdmrf07q9fm-libSystem-11.0.0/include:/nix/store/fnjn6903m23kkfs89k903vy3rmrix7l8-libcxx-15.0.7-dev/include/c++/v1:/nix/store/wqfyaymrsckr03xibcc2zd6kjqq4d3r7-clang-wrapper-15.0.7/resource-root/include
COMPILE_FLAGS:-U_FORTIFY_SOURCE:-fstack-protector:-Wall:-Wthread-safety:-Wself-assign:-Wunused-but-set-parameter:-Wno-free-nonheap-object:-fcolor-diagnostics:-fno-omit-frame-pointer
CXX_FLAGS:-x:c++:-std=c++0x
LINK_FLAGS:-undefined:dynamic_lookup:-headerpad_max_install_names
LINK_LIBS:-lc++:-lm
OPT_COMPILE_FLAGS:-g0:-O2:-D_FORTIFY_SOURCE=1:-DNDEBUG:-ffunction-sections:-fdata-sections
OPT_LINK_FLAGS
UNFILTERED_COMPILE_FLAGS:-no-canonical-prefixes:-Wno-builtin-macro-redefined:-D__DATE__=\"redacted\":-D__TIMESTAMP__=\"redacted\":-D__TIME__=\"redacted\"
DBG_COMPILE_FLAGS:-g
COVERAGE_COMPILE_FLAGS:-fprofile-instr-generate:-fcoverage-mapping
COVERAGE_LINK_FLAGS:-fprofile-instr-generate
SUPPORTS_START_END_LIB:False
IS_CLANG:True
benradf commented 1 year ago

Sorry for the delay in responding, I've only just had time to look into this. In summary, I was able to fix the missing tool issue by commenting out attribute_path like this. More details below.

The @toolchain-darwin-aarch64_info repository is created here:

    nixpkgs_package(
        name = "{}_info".format(name),
        nix_file = "@rules_nixpkgs_cc//:cc.nix",
        nix_file_deps = nix_file_deps,
        build_file_content = "exports_files(['CC_TOOLCHAIN_INFO'])",
        repositories = repositories,
        repository = repository,
        nixopts = nixopts,
        quiet = quiet,
        fail_not_supported = fail_not_supported,
    )

Note the nixopts parameter. By passing attribute_path to nixpkgs_cc_configure, we follow this path to construct it:

  1. Create a nix_expr with the attribute_path:
    elif attribute_path:
        nix_expr = "(import <nixpkgs> {{}}).{0}".format(attribute_path)
        attribute_path = None
  2. Set ccType=ccTypeExpression in nixopts:
    elif nix_expr:
        nixopts.extend([
            "--argstr",
            "ccType",
            "ccTypeExpression",
            "--arg",
            "ccExpr",
            nix_expr,
            "--argstr",
            "ccLang",
            cc_lang,
        ])
  3. ccTypeExpression causes the special case handling for Darwin to be overridden:
    cc =
    if ccType == "ccTypeAttribute" then
      pkgs.lib.attrByPath (pkgs.lib.splitString "." ccAttrPath) null ccAttrSet
    else if ccType == "ccTypeExpression" then
      ccExpr  # <--- Passing attribute_path causes us to end up here ...
    else      # <--- ... but we want to be here for special handling of Darwin tools
      pkgs.buildEnv (
        let
          cc = if pkgs.stdenv.isDarwin then darwinCC else pkgs.stdenv.cc;
        in
        {
          name = "bazel-nixpkgs-cc";
          # XXX: `gcov` is missing in `/bin`.
          #   It exists in `stdenv.cc.cc` but that collides with `stdenv.cc`.
          paths = [ cc cc.bintools ] ++ pkgs.lib.optional pkgs.stdenv.isDarwin pkgs.darwin.cctools;
          pathsToLink = [ "/bin" ];
          passthru = {
            isClang = cc.isClang;
          };
        }
      )

    If you really do need a custom nix expression, you'll have to make a copy of that bazel-nixpkgs-cc derivation as a base to work from. Ideally, just passing attribute_path wouldn't break the special handling for Darwin but the logic around nixopts is pretty convoluted and some thought is needed for a proper fix.

benradf commented 1 year ago

Closing this as I gave a fix for the specific issue, while the more general problem is being tracked by #374.