Tried to write dynamic symbol definition without a resolution

[mati865]

Error:

  Running command: "make libs" in dir: /home/mateusz/projects/rust-rdkafka/target/debug/build/rdkafka-sys-e3110b4b51e6f8c5/out
  Error: Failed copying from <epilogue> to output file

  Caused by:
      Tried to write dynamic symbol definition without a resolution: symbol `_ZTv0_n56_N7RdKafka10HandleImpl8outq_lenEv` (1257 local=239) in file #1536 (6/0) (ProducerImpl.o) defined as 566 in file #1024 (4/0) (HandleImpl.o) (ADDRESS)
  collect2: error: ld returned 255 exit status

Reproduction:

jj git clone https://github.com/fede1024/rust-rdkafka

cd rust-rdkafka

PATH=~/projects/wild:$PATH cargo b

It doesn't reproduce by changing ~/.cargo/config.toml like in the README because [target.<triple>] doesn't apply when linking build scripts.

[marxin]

I tried to reproduce this, but it does not manifest and I double-checked (by adding a todo!) that Wild linker is used.

[mati865]

Weird, I had encountered it on Ubuntu VM on the company workstation and then on Arch Linux on my home machine.
I'll see if I can crate Containerfile that is affected.

[marxin]

Good, now I can reproduce it from an Ubuntu docker image.

[davidlattimore]

I'm able to reproduce.

It doesn't reproduce by changing ~/.cargo/config.toml like in the README because [target.<triple>] doesn't apply when linking build scripts.

It does affect linking of build scripts, however it doesn't affect what linker might be used when those build scripts invoke GCC or clang.

The problem was because there were multiple weak definitions of the same function and we were trying to export all of them from the shared object, not just the canonical definition. PR coming...

[mati865]

It does affect linking of build scripts, however it doesn't affect what linker might be used when those build scripts invoke GCC or clang.

I have hit rust-lang/cargo#4423 so many times previously that I think they do not apply. Or at least, not all ways to configure them are applied to build scripts.

Anyway, thanks for the fix. I'll restore the /usr/local/bin/ld symlink to wild and see how it goes.

[davidlattimore]

I have hit rust-lang/cargo#4423 so many times previously that I think they do not apply. Or at least, not all ways to configure them are applied to build scripts.

You can check what linker was used (although GNU ld doesn't write a comment, but the other linkers do):

readelf -p .comment target/release/build/ahash-efcdc5043814e943/build_script_build-efcdc5043814e943 | grep Linker
  [    58]  Linker: Wild version 0.3.0

So for me at least, the setting in ~/.cargo/config.toml is sufficient for build scripts to be linked with wild.

Anyway, thanks for the fix. I'll restore the /usr/local/bin/ld symlink to wild and see how it goes.

Another option for overriding the linker is setting PATH. e.g. PATH=$HOME/work/wild/fakes:$PATH.

[mati865]

You can check what linker was used (although GNU ld doesn't write a comment, but the other linkers do):

Writing a script that would look for binaries in a given path that are not linked with wild would certainly be an option, but I like the nuclear solution: "ld is wild". No build system so far has outsmarted that yet 😉

So for me at least, the setting in ~/.cargo/config.toml is sufficient for build scripts to be linked with wild.

I cannot recall the specific (it wasn't related to wild), but I have learned it hard way to be wary about RUSTFLAGS when linker script are involved.

Another option for overriding the linker is setting PATH. e.g. PATH=$HOME/work/wild/fakes:$PATH.

Yeah, matter of personal preference. For Dockefiles using RUN cargo install --git --locked <wild_repo> && ln -s ... .... is much more convenient.