Wine + Musl. Then segfault. Help me understand this bug.
March 30, 2021 2:23 PM Subscribe
I'm trying to compile Wine on a musl-based system. I'm getting a segfault, and I don't know how to fix it. Help me at least understand the nature of the error.
I've posted this question in detail here:
https://forum.winehq.org/viewtopic.php?f=8&t=35046
I've also sought help in other forums to try to understand the error. No responses; therefore I'm not progressing. I realize this isn't exactly the place for coding help, but a generalized explanation of the issue may be helpful beyond this specific hurdle.
This is over my head, clearly. If anyone could help me even understand what is happening with this segfault, that would be a huge step in the right direction.
What is the issue here?:
Program received signal SIGSEGV, Segmentation fault.
0xf7fc2cdc in do_relocs (dso=dso@entry=0xf7ffca20, rel=0x56555914, rel_size=2104, stride=2)
at ldso/dynlink.c:470
470 ldso/dynlink.c: No such file or directory.
I've posted this question in detail here:
https://forum.winehq.org/viewtopic.php?f=8&t=35046
I've also sought help in other forums to try to understand the error. No responses; therefore I'm not progressing. I realize this isn't exactly the place for coding help, but a generalized explanation of the issue may be helpful beyond this specific hurdle.
This is over my head, clearly. If anyone could help me even understand what is happening with this segfault, that would be a huge step in the right direction.
What is the issue here?:
Program received signal SIGSEGV, Segmentation fault.
0xf7fc2cdc in do_relocs (dso=dso@entry=0xf7ffca20
at ldso/dynlink.c:470
470 ldso/dynlink.c: No such file or directory.
I don't have much in the way of a solution, but I think I can explain the error messages.
The line
470 ldso/dynlink.c: No such file or directory.
is coming from gdb; it indicates that you don't have the source for ldso/dynlink.c in a path which gdb can find, so it can't show you the exact source line for the crash. That's an informational error, but not the cause of the crash. It just means if you want to see the source code line for the error, you'll need to set up gdb correctly with pointers to the source code on your system.
A SIGSEGV means you tried to access memory outside the range allocated for this program.
This link might contain a helpful comment. Good luck.
https://github.com/SRI-CSL/musllvm
Ian's notes on what NOT to do with the bitcode
I guess pointing out things that don't work might also illucidate things, especially if I can explain why they don't work. This does not work:
clang -static -nostdlib nweb.bc libc.so.bc crt1.o libc.a -o nweb
It links without warnings, but crashes on running. The reason it crashes on running is that libc.so.bc contains an empty definition of the thread local storage initializer, __init_tls, which it gets from ldso/dynlink.c. The actual definition that is needed is static_init_tls which is a weak alias defined in src/env/__init_tls.c. The static library libc.a is set up correctly:
> nm libc.a | grep init_tls
__init_tls.o:
0000000000000000 W __init_tls
0000000000000000 t static_init_tls
U __init_tls
whereas the Frankenstein one gets by linking a dynamic object libc.so.bc with a static object libc.a is not. The SIGSEGV occurs because of this problematic uninitialized thread local storage.
posted by blob at 3:00 PM on March 30, 2021 [2 favorites]
The line
470 ldso/dynlink.c: No such file or directory.
is coming from gdb; it indicates that you don't have the source for ldso/dynlink.c in a path which gdb can find, so it can't show you the exact source line for the crash. That's an informational error, but not the cause of the crash. It just means if you want to see the source code line for the error, you'll need to set up gdb correctly with pointers to the source code on your system.
A SIGSEGV means you tried to access memory outside the range allocated for this program.
This link might contain a helpful comment. Good luck.
https://github.com/SRI-CSL/musllvm
Ian's notes on what NOT to do with the bitcode
I guess pointing out things that don't work might also illucidate things, especially if I can explain why they don't work. This does not work:
clang -static -nostdlib nweb.bc libc.so.bc crt1.o libc.a -o nweb
It links without warnings, but crashes on running. The reason it crashes on running is that libc.so.bc contains an empty definition of the thread local storage initializer, __init_tls, which it gets from ldso/dynlink.c. The actual definition that is needed is static_init_tls which is a weak alias defined in src/env/__init_tls.c. The static library libc.a is set up correctly:
> nm libc.a | grep init_tls
__init_tls.o:
0000000000000000 W __init_tls
0000000000000000 t static_init_tls
U __init_tls
whereas the Frankenstein one gets by linking a dynamic object libc.so.bc with a static object libc.a is not. The SIGSEGV occurs because of this problematic uninitialized thread local storage.
posted by blob at 3:00 PM on March 30, 2021 [2 favorites]
Other people have had this problem, and solved it by adding -no-pie to the build flags - https://github.com/void-linux/void-packages/issues/25644 mentions this, for example.
when you run make, you can isntaedf run make LDFLAGS="$LDFLAGS -no-pie", at least looking at what's going on in https://raw.githubusercontent.com/void-linux/void-packages/master/srcpkgs/wine/template
(The reason: musl handles position independant stuff differently to what wine expects. solution is don't do that :))
posted by jaymzjulian at 5:18 PM on March 30, 2021
when you run make, you can isntaedf run make LDFLAGS="$LDFLAGS -no-pie", at least looking at what's going on in https://raw.githubusercontent.com/void-linux/void-packages/master/srcpkgs/wine/template
(The reason: musl handles position independant stuff differently to what wine expects. solution is don't do that :))
posted by jaymzjulian at 5:18 PM on March 30, 2021
Response by poster: Thank you. This is all very helpful both for my understanding and getting past the segfault.
In a subsequent build with LDFLAGS including -no-pie, I was able to get to a new fun error. At least I'm past this one.
A further discussion about my build issues isn't proper here as an ongoing series. I'll post any more relevant information as I have it regarding a successful complete build. Suffice it to say that, for the particular issue regarding ldso/dynlink.c, I have made it past that problem with -no-pie.
posted by mr_bovis at 7:04 PM on March 30, 2021 [1 favorite]
In a subsequent build with LDFLAGS including -no-pie, I was able to get to a new fun error. At least I'm past this one.
A further discussion about my build issues isn't proper here as an ongoing series. I'll post any more relevant information as I have it regarding a successful complete build. Suffice it to say that, for the particular issue regarding ldso/dynlink.c, I have made it past that problem with -no-pie.
posted by mr_bovis at 7:04 PM on March 30, 2021 [1 favorite]
« Older Crack in the ceiling - should we be worried? | Citation: 1999 article in Modernism magazine on... Newer »
This thread is closed to new comments.
posted by jquinby at 2:57 PM on March 30, 2021