-sys crates invoking autoconf configure scripts inherit CONFIG_SITE environment variable

[wreedb]

Problem

I was building a project that uses the jemalloc-sys crate, and it kept breaking from the crates build directory makefile attempting to install against system directories, I spent hours trying to figure out why, until I realized that I use the CONFIG_SITE environment variable, defining my default configure script options, which pointed to system directories for prefix, libdir, includedir, etc. Since this could be possible with any sys crate that uses autoconf, I figured I should report this as a bug, since I cannot imagine a situation in which the use of the CONFIG_SITE environment variable is ever desired in a cargo build process.

Steps

1. create a config.site file, for example /usr/share/config.site

prefix=/usr
libdir=${prefix}/lib
includedir=${prefix}/include
CFLAGS="-somecflags"

2. export the CONFIG_SITE environment variable

export CONFIG_SITE=/usr/share/config.site

3. build a project using the jemalloc-sys crate, e.g. sharkdp/fd
   Warning: do this as an unprivileged user, as otherwise the makefile would successfully install to system directories, possibly overwriting existing files.

Possible Solution(s)

I think it would make sense to either document this as a known limitation when using a -sys crate which builds using autoconf, or to maybe enforce that crates of this type cannot inherit this variable.

Notes

A user on a system which may have set this variable in their environment without them knowing could potentially run into this problem, which does not produce error messages that are particularly useful by their nature; since from the perspective of the configure script, this is it's intended behavior when CONFIG_SITE is present

Version

cargo 1.89.0 (c24e10642 2025-06-23)
release: 1.89.0
commit-hash: c24e1064277fe51ab72011e2612e556ac56addf7
commit-date: 2025-06-23
host: x86_64-unknown-linux-gnu
libgit2: 1.9.0 (sys:0.20.2 vendored)
libcurl: 8.12.1-DEV (sys:0.4.80+curl-8.12.1 vendored ssl:OpenSSL/3.5.0)
ssl: OpenSSL 3.5.0 8 Apr 2025
os: Linux 12.3.0 (linuxfromscratch) [64-bit]

[weihanglo]

Thanks for reporting this. And sorry for the late response.

I totally understand the frustration. However, it is common that a -sys crate would run any build tools of their choice to build the library from source. Those tool varies from ./configure and make, to cmake, ninja, or even xcode-build. Cargo doesn't have the knowledge of all environment used by every external vendored library. The general suggestion is opening a issue to the crate closest to the -sys crate and fix or document the behavior there. For example, The immediate way to fix jemalloc-sys is suggesting https://github.com/tikv/jemallocator to track CONFIG_SITE in build.rs via cargo::rerun-if-env-changed=NAME instruction.

From another angle, the crate jemalloc-sys actually documented it already but not comprehensively, though the official jemalloc does mention it requires autoconf to install. And autoconf has CONFIG_SITE documented. The deep dependency chain may be too far away from Cargo, making it less sense to document or fix on Cargo side.

The other work-in-process stuff is env sandboxing, which cargo might leverage to stop propagating user environment unless explicitly set. You can track the process below:

• Tracking issue for --env-set flag rust#118372
• Environment variable sandboxing rfcs#2794

Given these, I don't think there is any immediate action Cargo to take here, so going to close this. Let us know if we're missing things here.