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 with cc failed: multiple definition of `__muloti4' #70489

Closed
mimoo opened this issue Mar 28, 2020 · 5 comments
Closed

linking with cc failed: multiple definition of `__muloti4' #70489

mimoo opened this issue Mar 28, 2020 · 5 comments
Labels
A-linkage Area: linking into static, shared libraries and binaries C-bug Category: This is a bug. E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@mimoo
Copy link

mimoo commented Mar 28, 2020

Hello,

I'm running into a link failure with cc and I'm not sure how to investigate this. I'm also running out of ideas.

git clone https://github.com/google/oss-fuzz.git
python infra/helper.py shell libra
compile

This will compile with clang 10 on ubuntu xenial:

Step 8/10 : RUN clang -v
 ---> Running in ef911c30fa25
clang version 10.0.0 (https://github.com/llvm/llvm-project.git e84b7a5fe230e42b8e6fe451369874a773bf1867)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.0.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
Removing intermediate container ef911c30fa25
 ---> 76978329e057
Step 9/10 : RUN cat /etc/os-release
 ---> Running in 1e87f0c344d7
NAME="Ubuntu"
VERSION="16.04.6 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.6 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial

I'm getting this error:

Step #4: error: linking with `cc` failed: exit code: 1

// ...

Step #4:   = note: /rust/rustup/toolchains/1.42.0-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-0b278345638bce90.rlib(compiler_builtins-0b278345638bce90.compiler_builtins.c31qu5fm-cgu.0.rcgu.o): In function `__muloti4':
Step #4:           /cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.25/src/macros.rs:253: multiple definition of `__muloti4'
Step #4:           /tmp/rustcjXWpoV/liblibrocksdb_sys-eab822076e906c87.rlib(int128_builtins.cpp.o):int128_builtins.cpp:(.text.__muloti4+0x0): first defined here
Step #4:           collect2: error: ld returned 1 exit status
Step #4:           
Step #4: 
Step #4: error: aborting due to previous error
Step #4: 
Step #4: error: could not compile `libra_fuzzer_fuzz`.
Step #4: 
Step #4: To learn more, run the command again with --verbose.
Step #4: ********************************************************************************
Step #4: Failed to build.
Step #4: To reproduce, run:
Step #4: python infra/helper.py build_image libra
Step #4: python infra/helper.py build_fuzzers --sanitizer address --engine libfuzzer --architecture x86_64 libra
Step #4: ********************************************************************************
@mimoo mimoo added the C-bug Category: This is a bug. label Mar 28, 2020
@mimoo mimoo changed the title cc link failure cc link failure: multiple definition of `__muloti4' Mar 28, 2020
@mimoo mimoo changed the title cc link failure: multiple definition of `__muloti4' linking with cc failed: multiple definition of `__muloti4' Mar 28, 2020
@jonas-schievink jonas-schievink added A-linkage Area: linking into static, shared libraries and binaries E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 28, 2020
@jonas-schievink
Copy link
Contributor

Apparently this is a regression in 1.42.0?

@jonas-schievink jonas-schievink added E-needs-bisection Call for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc regression-from-stable-to-stable Performance or correctness regression from one stable version to another. labels Mar 31, 2020
@mimoo
Copy link
Author

mimoo commented Apr 1, 2020

Actually no sorry, not introduced by 1.42.0

@msmouse
Copy link

msmouse commented Apr 1, 2020

libcompiler_builtins defines "__muloti4" which is also part of libc++ which is statically linked to liblibrocksdb_sys (from https://github.com/tikv/rust-rocksdb). I naively think compiler-builtins usually should not be included in buiids and it being linked here is the problem? @jonas-schievink

@jonas-schievink jonas-schievink removed E-needs-bisection Call for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc regression-from-stable-to-stable Performance or correctness regression from one stable version to another. labels Apr 1, 2020
@jonas-schievink
Copy link
Contributor

Can't help you with that, I try to do as little FFI as possible

Centril added a commit to Centril/rust that referenced this issue Apr 7, 2020
…nits, r=alexcrichton

Keep codegen units unmerged when building compiler builtins

Make it possible to control how mono items are partitioned into code generation
units, when compiling the compiler builtins, by retaining the original partitioning.

Helps with rust-lang#48625, rust-lang#61063, rust-lang#67960, rust-lang#70489.

r? @alexcrichton
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Apr 7, 2020
…nits, r=alexcrichton

Keep codegen units unmerged when building compiler builtins

Make it possible to control how mono items are partitioned into code generation
units, when compiling the compiler builtins, by retaining the original partitioning.

Helps with rust-lang#48625, rust-lang#61063, rust-lang#67960, rust-lang#70489.

r? @alexcrichton
@Enselic
Copy link
Member

Enselic commented Oct 20, 2023

Triage: I get unauthorized: authentication required when trying to reproduce. We really need a simple way to reproduce this. Without that, not much can be done. Closing, but feel free to reopen when there is a minimal reproduce available.

@Enselic Enselic closed this as not planned Won't fix, can't repro, duplicate, stale Oct 20, 2023
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. E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants