Re: How is libc shared object chosen in libxul?
On Thu, Apr 28, 2016 at 07:58:24AM +1200, Karl Tomlinson wrote: > 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. It probably does here: https://dxr.mozilla.org/mozilla-central/source/toolkit/components/osfile/modules/osfile_unix_allthreads.jsm#42 The list of library it tries comes from bug 878791, and the reason libc.so is in there is for Android. We should probably stop unconditionally try all variants on all systems. a.out should work on most, and we should special-case on systems where that doesn't work. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How is libc shared object chosen in libxul?
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. >> 0x7fffc0f80b82 in strerror_l () from /usr/lib/libc.so >> (gdb) bt >> #0 0x7fffc0f80b82 in strerror_l () from /usr/lib/libc.so >> #1 0x731299a4 in ffi_call_unix64 () from >> /usr/lib64/firefox-45.0.2/libxul.so >> #2 0x73129050 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 0x76cb8150 in _xstat () from /lib64/libc.so.6 >> #1 0x731299a4 in ffi_call_unix64 () from >> /usr/lib64/firefox-45.0.2/libxul.so >> #2 0x73129050 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
Re: How is libc shared object chosen in libxul?
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. 0x7fffc0f80b82 in strerror_l () from /usr/lib/libc.so (gdb) bt #0 0x7fffc0f80b82 in strerror_l () from /usr/lib/libc.so #1 0x731299a4 in ffi_call_unix64 () from /usr/lib64/firefox-45.0.2/libxul.so #2 0x73129050 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 0x76cb8150 in _xstat () from /lib64/libc.so.6 #1 0x731299a4 in ffi_call_unix64 () from /usr/lib64/firefox-45.0.2/libxul.so #2 0x73129050 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
