Features "jpeg" and "dynamic_linking" cause linking error in 0.14-rc.4 on linux

[Sorseg]

Bevy version

0.14.0-rc.4

Relevant system information

Linux host 6.9.3-76060903-generic #202405300957~1718348209~22.04~7817b67 SMP PREEMPT_DYNAMIC Mon J x86_64 x86_64 x86_64 GNU/Linux

rustc 1.79.0 (129f3b996 2024-06-10)

What you did

I've updated to new bevy rc on my project and started getting compilation errors after running a cargo clean once.
I've made a repro repo that is a hello world project, with only bevy as the dependency and it also fails to link.

What went wrong

Linking error on stable is

  = note: /usr/bin/ld: __rust_realloc: undefined version: 
          /usr/bin/ld: __rust_no_alloc_shim_is_unstable: undefined version: 
          /usr/bin/ld: __rust_dealloc: undefined version: 
          /usr/bin/ld: __rust_alloc_zeroed: undefined version: 
          /usr/bin/ld: __rust_alloc_error_handler_should_panic: undefined version: 
          /usr/bin/ld: __rust_alloc_error_handler: undefined version: 
          /usr/bin/ld: __rust_alloc: undefined version: 
          /usr/bin/ld: failed to set dynamic section sizes: bad value
          collect2: error: ld returned 1 exit status

and on nightly with lld it is

  = note: rust-lld: error: version script assignment of 'global' to symbol '__rust_alloc' failed: symbol not defined
          rust-lld: error: version script assignment of 'global' to symbol '__rust_alloc_error_handler' failed: symbol not defined
          rust-lld: error: version script assignment of 'global' to symbol '__rust_alloc_error_handler_should_panic' failed: symbol not defined
          rust-lld: error: version script assignment of 'global' to symbol '__rust_alloc_zeroed' failed: symbol not defined
          rust-lld: error: version script assignment of 'global' to symbol '__rust_dealloc' failed: symbol not defined
          rust-lld: error: version script assignment of 'global' to symbol '__rust_no_alloc_shim_is_unstable' failed: symbol not defined
          rust-lld: error: version script assignment of 'global' to symbol '__rust_realloc' failed: symbol not defined
          collect2: error: ld returned 1 exit status
          

error: could not compile `bevy_dylib` (lib) due to 1 previous error

Additional information

A workaround in my case was to get rid of the jpeg feature as I don't use it anymore.

Thank you for maintaining this amazing engine!

[alice-i-cecile]

Thanks a ton for the minimal reproduction: this saves us a ton of time and grief. I'll try and reproduce tomorrow, but I think the odds are high that this doesn't make the 0.14 release. This sort of problem can be quite involved to troubleshoot and dynamic_linking isn't a must-have feature IMO.

[BD103]

I can't seem to reproduce this locally on MacOS. The jpeg feature enables image/jpeg, which adds a dependency on zune-core and zune-jpeg. This is the repository, though with a quick search I can't seem to find anything. Two questions:

1. Do you use a custom linker? (Perhaps through config_fast_builds.toml?)
2. If you disable default features for Bevy, does it still fail to link?

[alice-i-cecile]

I take it this can't be reproduced on 0.13 alone?

[Sorseg]

I agree that this is not a high priority issue, I posted it here mostly for other people running into this linking issue to figure out the cause, as it took me a couple of hours.

I am using this linker.

$ ld --version
GNU ld (GNU Binutils for Ubuntu) 2.38

The only thing in my .cargo/config.toml is rustc-wrapper=sccache, but I've added it there after running into the issue, to speed up investigating since I was cargo cleaning a lot.

Building with bevy 0.13.2 succeeds.

Building with default-features=false fails the same way, updated the repro repo to disable default features

[Sorseg]

I was able to reproduce it in the repro repo with docker
sudo docker run -it -v $PWD:/usr/src --workdir /usr/src rust:1.79.0 cargo build

[AyeTbk]

I get the same problem on Arch Linux.
I managed to make a minimal reproduction of the underlying linking error here. The gist of it seems to be: bevy uses image version 0.25, which uses zune-jpeg version 4.11, which has a crate-type of "cdylib". Either removing the crate-type or changing it to "dylib" (without the c) makes the linking succeed. I have tested this with Sorseg's repo, patching zune-jpeg locally.

Interesting to note: the latest version of zune-jpeg (0.5.0-rc1) doesn't have the crate-type anymore.

[mockersf]

the cdylib crate type has been removed from zune-jpeg: etemesi254/zune-image#187

until everything is updated, not much we can do on Bevy side

[TarekAS]

This is happening in a GitHub Action for me as well, if I run my tests with dynamic linking enabled to save on build time. Will disable dynamic linking until this is fixed.

[ironpeak]

I forked the zune-jpeg repository and made the latest code compatible with bevy so that I could use dynamic linking.
It works in my project although I'm not using many jpegs.

Cargo.toml

# https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html#the-patch-section
[patch.crates-io]
zune-jpeg = { git = "https://github.com/ironpeak/zune-image", rev = "eebb01b72c07aaf8b00200d9d87d4cba6f01651f" }

[bjorn3]

How was this not fixed by rust-lang/rust#113695? That PR should prevent rustc from attempting to link against cdylib's when a rust dependency is expected.

[alice-i-cecile]

I don't see an upstream issue about the cdylib. If this can be reproduced, we should open an issue there, and on the Rust repo itself.

[mockersf]

it should be fixed by etemesi254/zune-image#187, but we're waiting for every dependency to release/update

[Usioumeo]

If anyone reeealy needs to run bevy 0.15 with this two flags, it is possible to add to cargo.toml:

#patches for zune jpeg
[patch.crates-io]
zune-jpeg = { git = "https://github.com/etemesi254/zune-image", branch = "zune-jpeg-4.12"}

[patch."https://github.com/etemesi254/zune-image"]
zune-core = "0.4.12"

For me this solved the issue.

[BenjaminBrienen]

What dependency are we waiting on to release in order to close this?

[rparrett]

As far as I can tell, this should have been fixed as soon as zune-jpeg 0.4.12 was released (jul 21 2014). I don't think there was ever a published version of image that depended on 0.3, so the zune-jpeg release fixing this has has been semver compatible / cargo update should have been bringing it in.

 cargo tree -i zune-jpeg --features=jpeg
zune-jpeg v0.4.14
└── image v0.25.5
    ├── bevy_image v0.15.0 (/Users/robparrett/src/bevy/crates/bevy_image)

@ironpeak @TarekAS @Usioumeo are you able to confirm that this is fixed without patching?

[ironpeak]

It has been sorted out for me, I tested checking out a commit from 18-07-2024 in my repository and removing the zune-jpeg patch and it compiled and ran.

[rparrett]

Great, thanks!