libxul.so is dlopen()ed from the firefox process. That firefox process would already have a libc.so.6, I assume, and so I would not expect libxul.so to load another libc.so.6.
That seems to be confirmed here by running strace -e trace=file firefox/firefox See whether something different is happening on your system. Aaron Klotz writes: > This question is better suited to the dev-platform audience. > > On 4/24/2016 1:50 PM, john smith wrote: >> Hello, >> >> Today I installed musl C x86-64 library next to GLIBC on Linux 86-64 >> system. It has been installed to /usr/lib/libc.so. I didn't expect >> any problems with that, in fact all programs were running fine but >> Firefox couldn't start. The reason is (I think) that /usr/lib/libc.so >> was chosen by XUL for foreign function call instead of >> /lib64/libc.so.6. This is what gdb says: >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x00007fffc0f80b82 in strerror_l () from /usr/lib/libc.so >> (gdb) bt >> #0 0x00007fffc0f80b82 in strerror_l () from /usr/lib/libc.so >> #1 0x00007ffff31299a4 in ffi_call_unix64 () from >> /usr/lib64/firefox-45.0.2/libxul.so >> #2 0x00007ffff3129050 in ffi_call () from >> /usr/lib64/firefox-45.0.2/libxul.so >> >> Segmentation fault is not strange in such situation, it's normal when >> a dynamic linker is in different version than libc. After removing >> musl XUL picked /lib64/libc.so.6 as shown here albeit for a different >> C function: >> >> (gdb) bt >> #0 0x00007ffff6cb8150 in _xstat () from /lib64/libc.so.6 >> #1 0x00007ffff31299a4 in ffi_call_unix64 () from >> /usr/lib64/firefox-45.0.2/libxul.so >> #2 0x00007ffff3129050 in ffi_call () from >> /usr/lib64/firefox-45.0.2/libxul.so >> >> I cloned gecko-dev repository but I didn't anything related to this >> issue. Can someone explain what happened here? _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
