Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

linking error: unknown agrument -no-pie #73370

Closed
xMAC94x opened this issue Jun 15, 2020 · 7 comments · Fixed by #73384
Closed

linking error: unknown agrument -no-pie #73370

xMAC94x opened this issue Jun 15, 2020 · 7 comments · Fixed by #73384
Labels
A-linkage Area: linking into static, shared libraries and binaries C-bug Category: This is a bug. P-high High priority regression-from-stable-to-nightly Performance or correctness regression from stable to nightly.

Comments

@xMAC94x
Copy link

xMAC94x commented Jun 15, 2020

SUMMARY:

  • between ǹightly-2020-04-17 and nightly-2020-06-10 linking behavior changes which broke my cross compilation from linux to macos. It now adds the -no-pie which is unknown by my compiler.
    leaving it out would probably fix the error. Below are detailed informations about my project and the cross compilation setup in order to reproduce.

Error message:

error: linking with `/dockercache/osxcross/target/bin/x86_64-apple-darwin17-clang` failed: exit code: 1
  |
  = note: "/dockercache/osxcross/target/bin/x86_64-apple-darwin17-clang" "-m64" "-L" "/root/.rustup/toolchains/nightly-2020-06-10-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-apple-darwin/lib" "/dockercache/veloren/target/x86_64-apple-darwin/release/deps/veloren_server_cli-78b52b471002ffce.veloren_server_cli.dfwsp804-cgu.2.rcgu.o" "-o" "/dockercache/veloren/target/x86_64-apple-darwin/release/deps/veloren_server_cli-78b52b471002ffce" "-Wl,-dead_strip" "-no-pie" "-nodefaultlibs" "-L" "/dockercache/veloren/target/x86_64-apple-darwin/release/deps" "-L" "/dockercache/veloren/target/release/deps" "-L" "/dockercache/veloren/target/x86_64-apple-darwin/release/build/ring-c41ee91963e5ddb3/out" "-L" "/dockercache/veloren/target/x86_64-apple-darwin/release/build/libsqlite3-sys-136b28bf48384b6d/out" "-L" "/root/.rustup/toolchains/nightly-2020-06-10-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-apple-darwin/lib" "/tmp/rustcv9Gt5M/liblibsqlite3_sys-ceadf642235a6fee.rlib" "/tmp/rustcv9Gt5M/libring-d0f7bae75ed6ea2a.rlib" "/tmp/rustcv9Gt5M/libbacktrace_sys-767e350fd8547e78.rlib" "/root/.rustup/toolchains/nightly-2020-06-10-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-apple-darwin/lib/libcompiler_builtins-57149daefc485a08.rlib" "-framework" "Security" "-framework" "Security" "-framework" "CoreServices" "-framework" "CoreServices" "-lSystem" "-lresolv" "-lc" "-lm"
  = note: clang: error: unknown argument: '-no-pie'
          
error: aborting due to previous error

I tried this code:

We for the veloren project we have a CI docker container. i tried to update the toolchain.
with docker the error is reproduceable quite easy, however if you are familar with docker you can skip some steps in order to save you a hour of compilation

git clone https://gitlab.com/veloren/veloren-docker-ci/
cd veloren-docker-ci
cd base
# modify Dockerfile and change the RUST_TOOLCHAIN argument in line 3 to `nightly-2020-06-10` 
#   or similar, it also breaks with 06-05. 06-10 is only taken because of 
#   https://rust-lang.github.io/rustup-components-history/
nano Dockerfile
#Wait for BASE IMAGE TO BUILD
time docker build -t registry.gitlab.com/veloren/veloren-docker-ci:base --no-cache .;
# It will build just fine. It just generate a docker image to build veloren and it's macos cross compiltion
# Now we will see that the compilation will fail, start the container
docker run -it <id here, some hex number> bash
#inside the docker container setup the project:
export RUST_TOOLCHAIN=nightly-2020-06-10;
export PROJECTNAME=veloren;
cd /dockercache; \
    mkdir /dockercache/cache-all; \
    mkdir /dockercache/cache-release-linux; \
    mkdir /dockercache/cache-release-windows; \
    mkdir /dockercache/cache-release-macos; \
    mkdir /dockercache/cache-tarpaulin; \
    git lfs clone "https://gitlab.com/veloren/${PROJECTNAME}.git"; \
    cd "/dockercache/${PROJECTNAME}"; \
    git lfs install; \
    git lfs fetch --recent; \
    git checkout master; \
    git lfs pull; \
    sleep 10; \
    echo ${RUST_TOOLCHAIN} > ./rust-toolchain; \
    . /root/.cargo/env; \

    ln -s /dockercache/cache-release-macos /dockercache/veloren/target; \
    VELOREN_ASSETS=assets PATH="/dockercache/osxcross/target/bin:$PATH" COREAUDIO_SDK_PATH=/dockercache/osxcross/target/SDK/MacOSX10.13.sdk CC=o64-clang CXX=o64-clang++ cargo build --target=x86_64-apple-darwin --release; \
# the last command will fail with the error above.
# IF you would try this with old `2020-04-17` toolchain it wouldn't fail.

I expected to see this happen:

  • we successfully build the osxcross enviorment with the first docker container, based on this: https://wapl.es/rust/2019/02/17/rust-cross-compile-linux-to-macos.html
  • the code compiles for macos
  • after compilation it starts linking using the '/dockercache/osxcross/target/bin/x86_64-apple-darwin17-clang' linker we build in osxcross
  • the linking suceeds

Instead, this happened:

  • the linking fails as it tries to use a -no-pie flag which isn't supported. Interestingly when you search in the rust code for this flag, you'll find a refactor about a month ago changing no-pie behavior here: 96a466c. however i personally dont know how that caused the change.

Meta

rustc --version --verbose:

root@ddc242b44794:/dockercache/veloren# rustc --version --verbose
rustc 1.46.0-nightly (feb3536eb 2020-06-09)
binary: rustc
commit-hash: feb3536eba10c2e4585d066629598f03d5ddc7c6
commit-date: 2020-06-09
host: x86_64-unknown-linux-gnu
release: 1.46.0-nightly
LLVM version: 10.0
@xMAC94x xMAC94x added the C-bug Category: This is a bug. label Jun 15, 2020
@petrochenkov petrochenkov self-assigned this Jun 15, 2020
@petrochenkov
Copy link
Contributor

This is a regression from #71769.

@petrochenkov
Copy link
Contributor

Looks like the sess.target.target.options.linker_is_gnu condition was lost, and clang for macos is apparently not "linker_is_gnu".

@petrochenkov
Copy link
Contributor

I'll fix this today.

@jonas-schievink jonas-schievink added the regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. label Jun 15, 2020
@rustbot rustbot added the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Jun 15, 2020
@jonas-schievink jonas-schievink added the A-linkage Area: linking into static, shared libraries and binaries label Jun 15, 2020
@LeSeulArtichaut LeSeulArtichaut added P-high High priority and removed I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Jun 15, 2020
@LeSeulArtichaut
Copy link
Contributor

@petrochenkov
Copy link
Contributor

Fixed in #73384.

@petrochenkov petrochenkov removed their assignment Jun 15, 2020
@xMAC94x
Copy link
Author

xMAC94x commented Jun 15, 2020

awesome, i will confirm it, once it's in a good nightly build :)

@bors bors closed this as completed in e55d3f9 Jun 18, 2020
@xMAC94x
Copy link
Author

xMAC94x commented Jun 23, 2020

Just wanted to confirm that with 2020-06-22 this error no longer occurs, so it is fixed now, thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-linkage Area: linking into static, shared libraries and binaries C-bug Category: This is a bug. P-high High priority regression-from-stable-to-nightly Performance or correctness regression from stable to nightly.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants