Any nice way to inspect build configuration from binaries?

[EliahKagan]

Git has git version --build-options, which gives some information about the build, though not which libraries it is linked against:

ek@Glub:~$ git version --build-options
git version 2.34.1
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh

Libraries Git uses that are shared libraries can be inspected with ldd:

ek@Glub:~$ ldd "$(command -v git)"
        linux-vdso.so.1 (0x00007ffe61462000)
        libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007fe87a15f000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fe87a143000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe879f1a000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fe87a5ad000)

(I don't know if git provides any convenient way to list which features that require library support are available when the library is statically linked.)

Does gix or ein have any way to obtain this kind of information about itself? It would be useful to know details corresponding to the output of git version --build-options where applicable, but even more so to know which feature flags gix and ein are compiled with.

Even if gitoxide does not have corresponding functionality, is there an easy way to check this by running or inspecting the binaries? (I've opened this as a question rather than a feature request because I'm not sure I wish to request a change. Maybe this information is already readily available.)

[NobodyXu]

There's verge which enables encoding the build environment and git sha in the binary.

cargo-binstall print these info on -vV.

There's also cargo-auditable, which encodes the dependencies in the binary for auditing, we were able to use it with cargo-zigbuild by setting export CARGO=cargo-zigbuild

[Skgland]

Cargo already sets a bunch of variables at build time, but it doesn't look like top-level feature flags are among them.

For build script cargo sets CARGO_FEATURE_<name> for each activated feature, so a build script could collect all available environment variables starting with CARGO_FEATURE_ to get a list of enabled features, but given that you currently don't appear to be using build scripts this is probably not useful.

CARGO_FEATURE_<name> — For each activated feature of the package being built, this environment variable will be present where <name> is the name of the feature uppercased and having - translated to _.

[NobodyXu]

but given that you currently don't appear to be using build scripts this is probably not useful.

I think build-script is required if we want gitoxide to work on 32-bit windows cargo-bins/cargo-quickinstall#254

Windows requires you to embed a manifest in the binary for it to work.

Cargo-binstall uses build-script to generate a windows manifest and record build environment.

https://github.com/cargo-bins/cargo-binstall/blob/main/crates/bin/build.rs

[Byron]

There is indeed a build script for the binaries already, which could then aggregate cargo features and make them available in another environment variable, thanks @Skgland for the suggestion.

This makes me think a general embedding of features to present when running gix -v or gix -vv would be quite easy to accomplish.

[EliahKagan]

In #1492 (reply in thread) I had made this strange claim:

I had noticed at rust-secure-code/cargo-auditable#124 (comment) that, at some point, cargo-auditable had started working again for gitoxide builds, and I have verified locally that it works.

I wish I remembered what, exactly, I had tested. It may be that I tested a patched gitoxide and/or a patched cargo-auditable, or that I tested with gitoxide features that were able to build even when others were not, or maybe I only tested on one platform. In any case, as noted in rust-secure-code/cargo-auditable#124 (comment) and rust-secure-code/cargo-auditable#124 (comment), it wasn't really fixed at that time.

However, since #1929, it really does work (rust-secure-code/cargo-auditable#124 (comment)). Running cargo auditable build -r will build gitoxide with no errors.

Unfortunately, cargo-auditable does not readily work with cross, and modifying the Docker image used by cross is not sufficient to fix this, at least not by doing it in the ways that had, at one time, been expected to work. (Per rust-secure-code/cargo-auditable#95 (comment), the approaches mentioned in #1492 (reply in thread) seem to be untested and infeasible as described.)

@NobodyXu If I understand correctly what you were saying in #1492 (comment), cargo auditable works--or had at some point worked--when using cargo-zigbuild, which could be used instead of cross. But rust-secure-code/cargo-auditable#179 and rust-secure-code/cargo-auditable#95 (comment) indicate that this may not be working. Is this something that you are currently able to use?

Recently published packages from QuickInstall don't seem to have cargo-auditable metadata, but I haven't examined this comprehensively and I also don't know if that's the setting where you had used this.

[NobodyXu]

@NobodyXu If I understand correctly what you were saying in #1492 (comment), cargo auditable works--or had at some point worked--when using cargo-zigbuild, which could be used instead of cross. Is this something that you are currently able to use?

yes, cargo-binstall is still using it https://github.com/cargo-bins/cargo-binstall/blob/63aaa5c1932cebabc34eceda9d92a70215dcead6/justfile#L20

Recently published packages from QuickInstall don't seem to have cargo-auditable metadata, but I haven't examined this comprehensively and I also don't know if that's the setting where you had used this.

I removed cargo-auditable for quickinstall due to some quirk/bugs