run powerpc64le assert_instr on CI
#1784
Conversation
github-merge-queue
bot
removed this pull request from the merge queue due to a conflict with the base branch
folkertdev
force-pushed
the
powerpc64le-assert-instr-ci
branch
from
d206744 to
7f736d2
Compare
|
Locally I'm running into this problem with docker Full commandcc @sayantn if you have thoughts on that |
|
The docker container is unable to modify |
|
Are there downsides to having the script run that? To me the whole point of that script is that it just works. |
|
Idts, except for probably reducing the write access granularity in the docker. |
|
Ok, well I added that. With that though I still get an error because clang is missing: The manual fix here is to install clang in the |
|
You are running |
|
Yes, here's the full output |
|
Honestly, I have no idea. I have never encountered this. Are you on x86? That might explain why I haven't seen this yet |
|
ok, I got it I think. In my global [target.x86_64-unknown-linux-gnu]
linker = "clang"
rustflags = ["-C", "link-arg=-fuse-ld=/usr/bin/mold"]Somehow, the linker field gets used from the docker container. When I remove these lines the docker script works. Maybe the build script for Obviously I'd like to continue to use mold as my linker for standard rust projects, so is there any way we can get docker to ignore this configuration? |
|
The more I look at this, the more it feels like a cargo bug. The doc specifies that |
|
They just don't account for what docker does right? which is to just not propagate these environment variables, but cargo will still read the global config file. I'm trying to see if the config can somehow be ignored by the docker script, but not having much luck so far. |
|
But at each invocation of cargo in the script, we still have |
|
Yeah that's why I'm suspecting a |
|
Ok yes, that is most probably the culprit. I believe the solution is as easy as putting an empty |
|
Apparently, that does not actually override the linker value. Putting this in the local [target.x86_64-unknown-linux-gnu]
linker = "cc"But something like this does not work: [target.'cfg(all())']
linker = "cc" |
|
Unfortunately, I don't think anything else will work. There is an internals thread on this https://internals.rust-lang.org/t/problems-of-cargo-config-files-and-possible-solutions/12987, there are a few old open issues in the cargo repo about this too 😞 |
|
What does seem to work is to set |
|
Maybe better, I can add this to the # Set the linker that is used for the host (e.g. when compiling a build.rs)
# This overrides any configuration in e.g. `.cargo/config.toml`, which will
# probably not work within the docker container.
HOST_TUPLE_UPPERCASE=$(rustc --print host-tuple | tr a-z A-Z | tr '-' '_')
HOST_LINKER="CARGO_TARGET_${HOST_TUPLE_UPPERCASE}_LINKER"
eval 'export ${HOST_LINKER}="cc"' |
|
I feel like this should be in |
folkertdev
force-pushed
the
powerpc64le-assert-instr-ci
branch
from
f1762db to
f00793d
Compare
The host's linker is used to compile build.rs files (e.g. for libc). When the user configures a custom liker (e.g. mold) in their own .cargo/config.toml or ~/.cargo/config.toml, that linker will likely not work when running run-docker.sh. So, we now reset it to `cc`, which should always be installed in the docker container.
folkertdev
force-pushed
the
powerpc64le-assert-instr-ci
branch
from
f00793d to
f7c228c
Compare
Two changes to tests were needed
vrfin -> xvrspic(changed in #1713)So I think that means that this is fine? At least on s390x the rounding mode is not even relevant, this might be the case for powerpc too?
vmaddfp -> xvmaddasp(changed in #1734)That is just what C generates too now https://godbolt.org/z/5M8oT6fox
cc @lu-zero