liburing: genrule uses relative CC path that breaks after pushd

[travisdowns]

Problem

The liburing module's BUILD.bazel (affects versions 2.5, 2.10, 2.14) has a generate_headers genrule that sets CC from the Bazel toolchain and then pushds into the package directory before running ./configure:

cmd = """
        export CC=$(CC) CXX=$(CC)++

        # switch to the package dir to execute "configure" right there
        pushd $$(dirname $(location configure))
          mkdir -p src/include/liburing
          ./configure --use-libc
        popd
        ...
""",
toolchains = ["@bazel_tools//tools/cpp:current_cc_toolchain"],

$(CC) expands to a relative path like external/toolchains_llvm++llvm+current_llvm_toolchain/bin/cc_wrapper.sh. After pushd changes the working directory to external/liburing+/, this relative path no longer resolves. As a result, every compile_prog check in configure silently fails and all features are detected as no.

Additionally, the genrule does not pass any sysroot flags to configure. Even if CC resolved correctly, configure's compile checks would still fail because the compiler can't find kernel or libc headers (<linux/fs.h>, <sys/wait.h>, etc.) without --sysroot.

Reproducer

Use any Bazel project with toolchains_llvm (or any toolchain that provides a relative CC path and a sysroot). The configure output will show all features as no:

__kernel_rwf_t                no
__kernel_timespec             no
open_how                      no
statx                         no
glibc_statx                   no
has_ucontext                  no
has_idtype_t                  no
has_fanotify                  no
...

This causes compat.h to emit fallback type definitions (e.g. idtype_t) that conflict with the real definitions from the sysroot headers when the library is actually compiled.

Suggested fix

1. Resolve CC/CXX to an absolute path before pushd so the compiler is found from the changed directory. If $(CC) is a bare command (e.g. gcc, no /), it is found via PATH and needs no adjustment; if it contains a / it is a relative path that must be resolved with realpath.
2. Add @bazel_tools//tools/cpp:cc_flags to the genrule's toolchains and pass $(CC_FLAGS) (which includes --sysroot) as CFLAGS/CXXFLAGS/LDFLAGS so configure's compile checks can find system headers.
3. Convert relative sysroot paths in $(CC_FLAGS) to absolute (since they're relative to the execroot, not the pushd target).

Example patch:

     cmd = """
-            export CC=$(CC) CXX=$(CC)++
+            SRCDIR=$$(dirname $(location configure))
+
+            # Resolve CC to an absolute path so it survives the pushd
+            # below. If $(CC) is a bare command (no /) it is found via
+            # PATH and needs no adjustment.
+            _CC=$(CC)
+            case "$$_CC" in */*) _CC=$$(realpath $$_CC) ;; esac
+            export CC=$$_CC CXX=$$_CC++
+
+            # Pass sysroot from the Bazel CC toolchain so that configure's
+            # feature detection finds kernel and libc headers in the sandbox.
+            CC_FLAGS="$(CC_FLAGS)"
+            case "$$CC_FLAGS" in *--sysroot=*)
+              SYSROOT=$${CC_FLAGS##*--sysroot=}; SYSROOT=$${SYSROOT%% *}
+              CC_FLAGS=$${CC_FLAGS//--sysroot=$$SYSROOT/--sysroot=$$(realpath $$SYSROOT)} ;;
+            esac
+            export CFLAGS="$$CC_FLAGS" CXXFLAGS="$$CC_FLAGS" LDFLAGS="$$CC_FLAGS"

             # switch to the package dir to execute "configure" right there
-            pushd $$(dirname $(location configure))
+            pushd $$SRCDIR
...
-    toolchains = ["@bazel_tools//tools/cpp:current_cc_toolchain"],
+    toolchains = [
+        "@bazel_tools//tools/cpp:current_cc_toolchain",
+        "@bazel_tools//tools/cpp:cc_flags",
+    ],

With this fix, configure correctly detects all available features.

[fmeum]

@metti

[travisdowns]

The underlying problem I think is that liburing needs the pushd for configure to work, but changing cwd will "break" any relative paths used in the build, like relative CC, or relative CC_FLAGS like --sysroot (currently CC_FLAGS aren't even included in the configure step, but they should be).

[travisdowns]

This could help for future versions: axboe/liburing#1558

Potentially removing the need to change cwd in the first place