use new native-image options to use bazel's cc

[johnynek]

see: https://github.com/oracle/graal/issues/1557

It may be possible to make this ruleset hermetic with those options. If not, it would be really nice to file the issues we need to make these rules have passing test on sandboxed linux.

cc @ianoc-stripe

[johnynek]

https://github.com/bazelbuild/bazel/blob/master/site/docs/integrating-with-rules-cc.md

That may be useful, also:

https://github.com/bazelbuild/rules_cc/blob/master/examples/my_c_archive/my_c_archive.bzl

[IljaKroonen]

I had a quick look at load("@bazel_tools//tools/cpp:toolchain_utils.bzl", "find_cpp_toolchain")

I get this when I print the result of calling find_cpp_toolchain(ctx) (it's an object of type https://docs.bazel.build/versions/master/skylark/lib/CcToolchainInfo.html)

DEBUG: /home/ilja/.cache/bazel/_bazel_ilja/aa916b52f2b74a23332a53b9fbed97b8/external/rules_graal/graal/graal.bzl:4:5: struct(all_files = depset([]), ar_executable = "/usr/bin/ar", built_in_include_directories = ["/usr/lib/gcc/x86_64-linux-gnu/9/include", "/usr/local/include", "/usr/lib/gcc/x86_64-linux-gnu/9/include-fixed", "/usr/include/x86_64-linux-gnu", "/usr/include", "/usr/include/c++/9", "/usr/include/x86_64-linux-gnu/c++/9", "/usr/include/c++/9/backward"], compiler = "compiler", compiler_executable = "/usr/bin/gcc", cpu = "k8", ld_executable = "/usr/bin/ld", libc = "local", nm_executable = "/usr/bin/nm", objcopy_executable = "/usr/bin/objcopy", objdump_executable = "/usr/bin/objdump", preprocessor_executable = "/usr/bin/cpp", strip_executable = "/usr/bin/strip", sysroot = None, target_gnu_system_name = "local")

If I then pass in /usr/bin/gcc and /usr/bin/ld in the path (regardless of using the new option provided inoracle/graal#1557), I get

Error: Error compiling query code (in /tmp/SVM-6446577993017682427/BuiltinDirectives.c). Compiler command  /usr/bin/gcc /tmp/SVM-6446577993017682427/BuiltinDirectives.c -o /tmp/SVM-6446577993017682427/BuiltinDirectives output included error: gcc: fatal error: cannot execute 'as': execvp: Not a directory

Which is not inside of CcToolchainInfo

As a workaround, the rules execute fine on my system when I add

env = {
    "PATH": "/usr/bin",
},

on the ctx.actions.run in graal.bzl.

Any ideas of where I could look next?

[johnynek]

It looks like gcc itself is calling as. So I guess we go one layer down the rabbit hole.

I can see a few possibilities:

1. Seeing if gcc has an option to give the path to as and have native-image pass that through.
2. Setting up a native-image toolchain in a repository rule that sets up a directory for gcc with symlinks it needs.
3. Maybe getting Bazel to include as in the cc toolchain.

[johnynek]

Possibly relevant: https://stackoverflow.com/questions/14454404/how-to-choose-the-assembler-gcc-uses#14455196

In 2013 the path to as was a compile time option. If this is still the case, this means we should probably fix it in bazel by getting as in the cc toolchain.

[ianoc-stripe]

https://gist.github.com/xianyi/2957847

since we are calling clang on os x for gcc i think this approach could work too to redirect the as call back onto clang.

[johnynek]

This page: https://docs.bazel.build/versions/master/cc-toolchain-config-reference.html#assembler-actions

References assembler actions, so it seems that bazel must know about an assembler.

[snoble]

I was poking at this a bit today and I'm not sure I'm anywhere closer than above. I used cc_common.get_tool_for_action to get the paths for C_COMPILE_ACTION_NAME and CPP_LINK_EXECUTABLE_ACTION_NAME and using the new parameters provided.

Unfortunately CPP_LINK_EXECUTABLE_ACTION_NAME is just the gcc path so it's still missing ld (same for ASSEMBLE_ACTION_NAME).

I started a PR but it's not actually working yet. Also includes downloading from the new URL structure that includes Java version.

https://github.com/snoble/rules_graal/pull/1/files