oubidar-Abderrahim
commented
1 year ago Thank you for reporting this, we'll take a look into it shortly
Closed thiagokokada closed 10 months ago
oubidar-Abderrahim
commented
1 year ago Thank you for reporting this, we'll take a look into it shortly
oubidar-Abderrahim
commented
1 year ago Hi,
Could you please provide more specific steps to reproduce the issue? I've created the CC file but it wasn't executed, there is no file under /tmp/environment
thiagokokada
commented
1 year ago Hi,
Could you please provide more specific steps to reproduce the issue? I've created the CC file but it wasn't executed, there is no file under
/tmp/environment
You need to create a cc script that will print the environment in that file. You can do something like this:
mkdir -p ~/bin
export PATH=$HOME/bin:$PATHCreate a new file in ~/bin/cc and paste this contents:
echo "=== Environment CC start ===" >> /tmp/environment
env >> /tmp/environment
echo "==== Environment CC end ====" >> /tmp/environment
/usr/bin/cc "$@"Unfortunately, nothing changed here are the steps I'm following:
If there are any missing steps please include them in your description. Thank you
thiagokokada
commented
1 year ago I think the script is missing the execution bit:
$ chmod +x $HOME/bin/ccThis should work.
thiagokokada
commented
1 year ago Just to make sure, before running GraalVM, run cc and do a cat /tmp/environment to see if it is working correctly.
thiagokokada
commented
11 months ago @oubidar-Abderrahim Any updates on this issue? I have a very strong suspicious this is also affecting Linux systems.
oubidar-Abderrahim
commented
11 months ago Unfortunately, I cannot reproduce the issue. after building the image I compared the Env variable in /tmp/environment and I do see some extra one after building the image, but nothing is missing
borkdude
commented
10 months ago Maybe related? https://github.com/oracle/graal/issues/7981
oubidar-Abderrahim
commented
10 months ago I'll close this issue for now as not reproducible. If the suggestion from #7981 is not solving the issue, and you can provide a more reliable reproducer, please reopen or create a new issue for it and we'll check it again. Thank you
thiagokokada
commented
10 months ago Thanks @oubidar-Abderrahim, using export NATIVE_IMAGE_DEPRECATED_BUILDER_SANITATION=true did the trick for now.
Do we have any idea for how long this environment variable will be supported?
oubidar-Abderrahim
commented
10 months ago We don't have a specific date yet, but I would suggest using -E<env-var-key>[=<env-var-value>] instead so that you won't be affected once it gets removed
borkdude
commented
10 months ago Would it be possible to add an env var wildcard? I have like 20+ environment variables that I'm capturing at build time starting with BABASHKA_
thiagokokada
commented
10 months ago Would it be possible to add an env var wildcard? I have like 20+ environment variables that I'm capturing at build time starting with
BABASHKA_
We also need to inject a bunch of environment variables.
Describe the issue I am working in bumping GraalVM package to the https://github.com/graalvm/graalvm-ce-builds/releases/tag/jdk-21.0.0 inside nixpkgs (see PR) and bumped in the following issue.
Using the latest stable release, it seems
native-imageis cleaning the environment variables before calling the C compiler (cc). I did the following test by creating a small wrapper script forccthat basically does:And this is the result:
Builder environment (I removed a few things since Nix exports all the derivation attributes as environmental variables, so if I put everything here it would be confusing):
CC environment:
Why is this an issue? In Nix we don't have the libraries in their expected places, so we need to give some help for the compiler to find everything. We do this by wrapping the C compiler and exporting some environmental variables that allows the compiler to figure out where everything is. For example
NIX_CFLAGS_COMPILEandNIX_LDFLAGS. By removing those environment variables the compiler can't find the critical libraries, resulting in the following issue we are seeing:As you can see,
Foundation/Foundation.his not found (this build was done in anx86_64MacOS environment). If you look at theNIX_COMPILE_FLAGSandNIX_LDFLAGS, those includes the incantations that the C compiler needs to add to find the libraries. I created a workaround where we re-inject the expectedNIX_COMPILE_FLAGSandNIX_LDFLAGSinside accwrapper, and this was sufficient to get it to build again. However this is ugly and fragile. Also, we didn't need any of those things until GraalVM 22.3.1, so I imagine this is a recent change done in the 23.0.0 release.If the environment cleaning in the C compiler is proposital to workaround some other issue, can we have some flag to disable this behavior or at least some way were we can add environment variables to the allowlist (so they would be re-added to the C compiler environment)? Keep in mind that we always run a build inside a proper sandbox, so the issue where some random environment variables is breaking builds (something that I imagine was the reason for this change) wouldn't affect us.
Steps to reproduce the issue
ccand put it before anything else in yourPATHnative-imagecat /tmp/environmentand compare with your current environment. You will see that it is missing tons of environment variablesDescribe GraalVM and your environment:
More details N/A