Skip to content

linking error: unknown agrument -no-pie #73370

Closed

Description

@xMAC94x

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

Activity

  1. self-assigned this
    on Jun 15, 2020
  2. petrochenkov commented on Jun 15, 2020

    @petrochenkov
    Contributor

    This is a regression from #71769.

  3. petrochenkov commented on Jun 15, 2020

    @petrochenkov
    Contributor

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

  4. petrochenkov commented on Jun 15, 2020

    @petrochenkov
    Contributor

    I'll fix this today.

  5. added
    I-prioritizeIssue needs a team member to assess the impact. Will be replaced by P-{low,medium,high,critical}
    on Jun 15, 2020
  6. added
    P-highHigh priority
    and removed
    I-prioritizeIssue needs a team member to assess the impact. Will be replaced by P-{low,medium,high,critical}
    on Jun 15, 2020
  7. LeSeulArtichaut commented on Jun 15, 2020

    @LeSeulArtichaut
    Contributor
  8. petrochenkov commented on Jun 15, 2020

    @petrochenkov
    Contributor

    Fixed in #73384.

  9. removed their assignment
    on Jun 15, 2020
  10. xMAC94x commented on Jun 15, 2020

    @xMAC94x
    Author

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

  11. added a commit that references this issue on Jun 18, 2020
  12. xMAC94x commented on Jun 23, 2020

    @xMAC94x
    Author

    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

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-linkageArea: linking into static, shared libraries and binariesC-bugCategory: This is a bug.P-highHigh priorityregression-from-stable-to-nightlyPerformance or correctness regression from stable to nightly.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions