librsvg build failure after updating rust binary package

[ghost]

When I try to update librsvg to the latest version (2.56.1) I get:

error: process didn't exit successfully: "rustc -vV" (signal: 11, SIGSEGV: invalid memory reference)

Version it worked on

It most recently worked on: Rust 1.69

Version with regression

Rust 1.70.0

[saethlin]

How can someone reproduce this? I ran

https://gitlab.gnome.org/GNOME/librsvg
cd librsvg
cargo +stable test

and I don't get a SIGSEGV.

You say

When I try to update librsvg to the latest version (2.56.1)

Are you building another crate that depends on librsvg?

[ghost]

Hi @saethlin, I am just doing a system update with my distro's package manager, I can share their librsvg pkgbuild if you want.

[saethlin]

Yes, if you can point us to whatever is compiling librsvg that would be great. As it is, I have absolutely no idea.

[ghost]

Thank so much for you help, here's their recipe for librsvg and the one for rust-bin

[saethlin]

I can't reproduce this by following the recipe for librsvg with the official compiler. Rust 1.70 contains an LLVM upgrade, so I would not be surprised if this patch that modifies our targets has now broken something.

Can you run this?

gdb rustc

Then in gdb run these commands

run -vV
backtrace
quit

The backtrace that's printed may help identify where the segfault is coming from.

[ghost]

Ok, I have run gdb but I couldn't even get to backtrace because of this:
`Starting program: /usr/bin/rustc -vV

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7fd9021 in ?? () from /lib64/ld-linux-x86-64.so.2`
EDIT: sorry, I missed an important info, my installed package is actually the precompiled binary.

[hhoffstaette]

We found the problem in #112286 - it's related to stripping during installation, which worked fine previosuly but breaks since 1.70, probably due to how libLLVM is being built.
Update: I looked at the installer recipe and it says "!strip", which I assume already means "no strip". Either that does not work or the problem is somewhere else, because after no longer stripping the bin package in Gentoo I can rebuild librsvg just fine.

[ghost]

Hi @hhoffstaette , actually I made a mistake, the affected package was the precompiled binary, I had pointed to the wrong recipe (just fixed the link). They simply install it directly from the official source.

[saethlin]

@Evhorizon Can you tell me what du -h /usr/lib/libLLVM-16-rust-1.70.0-stable.so is? I'm just guessing at the path, if you ldd $(which rustc) you'll get a path to the libLLVM that it is linked against.

Based on the recipe you've linked, I feel like you're working with a not-stripped libLLVM. The size should be an easy way to confirm whether or not it is stripped.

[ghost]

@saethlin the size output of the command is 144 M

[saethlin]

That sounds stripped to me. So this is definitely a duplicate of #112286

[ghost]

@saethlin does this mean that the official binary package is already stripped?

[saethlin]

No. If you download the tarball and extract it without installing it, you should see that the libLLVM-16-rust-1.70.0-stable.so that is in the package is 170 MB. When I manually install the package on various other distros, the libLLVM that gets installed is also 170 MB, i.e. not stripped.

I don't know how your distro is stripping the libLLVM here, but everything indicates that it is.

[ghost]

Ok, I tried to strip down the Venom's recipe for rust-bin to the bare minimum, like that:
source="https://static.rust-lang.org/dist/rust-$version-x86_64-unknown-linux-gnu.tar.gz" build() { cd rust-$version-x86_64-unknown-linux-gnu ./install.sh --prefix=/usr --destdir="$PKG"
with the intention to have the cleanest and most standard possible install, am I doing right?
The package did install fine but the issue with librsvg is still there. I'm kind of a lost now, I am not even sure whether rust-bin is the problem or something else.

[saethlin]

Unfortunately, I don't know anything about Venom Linux, how your package manager works, or what this build function and PKG variable are. What you pasted might look minimal to you, but to me it's a bunch of things I don't understand and it's part of a bigger system that I also don't understand.

I suspect you can demonstrate that the install package from Rust works if you do this:

curl -LO https://static.rust-lang.org/dist/rust-1.70.0-x86_64-unknown-linux-gnu.tar.gz
tar xf rust-1.70.0-x86_64-unknown-linux-gnu.tar.gz
rust-1.70.0-x86_64-unknown-linux-gnu/rustc/bin/rustc -vV

That should print the version message. If it does, then there is something in Venom Linux that is stripping the components, and disabling that (for now) would make Rust 1.70 work. But I have no idea how to guide you through that process.

Without help from someone managing Venom Linux, I don't think there is anything else I can do to help you.

[ghost]

Yes, sorry, I should have given further details before about how the package manager works. Basically, it's something like Arch Linux PKGBUILD, the build () function encloses all the build instructions in bash, while PKG is the fake installation directory. What puzzles me is that here the package manager seems to just execute the install.sh script in the original package, without stripping or anything else. I will reopen the issue that I opened in their Github, and FWIW following your suggestion, Rust does print the version message. Also, after building Rust from source, librsvg builds fine.

[apiraino]

unsure if we could close this issue (either as "solved" or "not our issue"). The issue reporter is not available anymore I think, can anyone in this thread share if they can still reproduce this?

thanks

[saethlin]

At this point I would be comfortable closing this as a duplicate of #112286

[apiraino]

ah yes thanks @saethlin while scrolling the comment thread I missed your comment from months ago

Closing as duplicate, then.