Starting with 1.62.0, tests for gettext-rs crate segfault on x86_64-unknown-linux-musl because pthread_mutex_lock is missing from the binary. I failed to figure out why: If you're into this sort of thing, please lend me a hand!

· · Web · 4 · 4 · 0

@L29Ah Technically the segfault is in GNU gettext, which is a C library :P But it happens because (I think) Rust doesn't link the entirety of pthreads into the binary. Overall it looks like the Rust crate relied on symbols that compiler used for its own stuff, and now that the compiler no longer uses those symbols and doesn't include them in the binary, the crate is broken.

But I can't figure out how to ask Rust to pull that symbols for me :(

@L29Ah Um, yes? GNU software can call POSIX interfaces just fine. (Sorry I don't have a funny response for you here.)

@minoru @L29Ah "Rust is full featured and can do anything!"

@L29Ah Rust has one too: But if you're building an application in multiple languages (e.g. C and Rust), then it's slightly easier to use a single gettext implementation in both languages; that's where gettext-sys and gettext-rs come in.


@minoru Unfortunately, I have no idea how to solve this.

Although it is very unlikely that the following will work, it is very easy to try out, so I mention it here:
have you tried upgrading to 1.62.1? They haved fixed some things in there. Maybe give it a try. 🤷

@janriemer Yeah, I tried it yesterday, but no luck. I'll add a mention of this to the issue though, as every bit might become a clue!

@gigantos The only thing that's in the else branch that I don't yet add is pthread library, but attempting to add it leads to linking errors:

The order given to the linker is important and sometimes the same lib must be mentioned more than once. I'm pretty sure the solution is to add libs in in some way or another, including pthreads. In the linking error it seems to me pthreads depends on libc, but they are in the wrong order.

@minoru Rust has stopped using pthread mutexes itself (now std Mutex is a direct kernel syscall). Are you mixing Rust locks with C's anywhere? Or maybe you need to link with libpthread explicitly yourself, because Rust's std won't pull in these symbols any more?

@kornel No, no mixing that I am aware of.

I did try to link with libpthread, but that failed because of duplicate symbols: Some of those symbols are ostensibly from my host's libc though (which is glibc, not musl). Bizarre.

Sign in to participate in the conversation
Functional Café

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!