Hi,
I notice that WebKit, when built with WebRTC enabled, now crashes
during the build:
https://bugs.webkit.org/show_bug.cgi?id=214812#c7
It's a symbol conflict between boringssl (used by libwebrtc) and
openssl. But why is openssl involved at all? It's a dependency of
libcurl, which is a dependency of debuginfod, which apparently gets
initialized by a library constructor of elfutils:
https://sourceware.org/git/?p=elfutils.git;a=blob;f=libdwfl/debuginfod-client.c;h=99b66b6eedf4a8a06024b2bb89da4824847fcd4d;hb=HEAD
So my first thought was: does elfutils get linked into... everything?
It seems the answer is "no" because I can run /usr/bin/true under gdb,
break on __libdwfl_debuginfod_init, and verify that it doesn't get
called. Same for gnome-clocks. But when I try running nautilus under
gdb, I find:
(gdb) break __libdwfl_debuginfod_init
..
(gdb) r
..
(gdb) bt
#0 0x00007fffce58dda0 in __libdwfl_debuginfod_init () at
/lib64/libdw.so.1
#1 0x00007ffff7fe18ee in call_init
(l=<optimized out>, argc=argc@entry=1,
argv=argv@entry=0x7fffffffe168, env=env@entry=0x7fffffffe178)
at dl-init.c:74
#2 0x00007ffff7fe19d8 in call_init (env=0x7fffffffe178,
argv=0x7fffffffe168, argc=1, l=<optimized out>)
at dl-init.c:37
#3 _dl_init (main_map=0x555555ab0000, argc=1, argv=0x7fffffffe168,
env=0x7fffffffe178) at dl-init.c:121
#4 0x00007ffff6e7a095 in __GI__dl_catch_exception
(exception=<optimized out>, operate=<optimized out>,
args=<optimized out>) at dl-error-skeleton.c:182
#5 0x00007ffff7fe5e35 in dl_open_worker (a=0x7fffffffd840) at
dl-open.c:783
#6 0x00007ffff6e7a038 in __GI__dl_catch_exception
(exception=0x7fffffffd820, operate=0x7ffff7fe5a50 <dl_open_worker>,
args=0x7fffffffd840)
at dl-error-skeleton.c:208
#7 0x00007ffff7fe566e in _dl_open
(file=0x7fffffffd820 "\344\025\207UUU", mode=-2147483647,
caller_dlopen=0x7ffff7064bff <g_module_open+799>, nsid=-2, argc=1,
argv=0x7fffffffe168, env=0x7fffffffe178) at dl-open.c:864
#8 0x00007ffff654439c in dlopen_doit (a=a@entry=0x7fffffffda70) at
dlopen.c:66
#9 0x00007ffff6e7a038 in __GI__dl_catch_exception
(exception=exception@entry=0x7fffffffda10, operate=0x7ffff6544340
<dlopen_doit>, args=0x7fffffffda70)
at dl-error-skeleton.c:208
#10 0x00007ffff6e7a103 in __GI__dl_catch_error
(objname=0x5555557789d0, errstring=0x5555557789d8,
mallocedp=0x5555557789c8, operate=<optimized out>, args=<optimized
out>) at dl-error-skeleton.c:227
#11 0x00007ffff6544bd9 in _dlerror_run (operate=0x7ffff6544340
<dlopen_doit>, args=0x7fffffffda70) at dlerror.c:170
#12 0x00007ffff6544428 in __dlopen (file=<optimized out>,
mode=<optimized out>) at dlopen.c:87
#13 0x00007ffff7064bff in g_module_open () at /lib64/libgmodule-2.0.so.0
#14 0x000055555561cfce in nautilus_module_load ()
#15 0x00007ffff71e927b in g_type_module_use () at
/lib64/libgobject-2.0.so.0
#16 0x000055555561e8e7 in nautilus_module_setup ()
#17 0x00005555555ae75a in nautilus_application_startup_common ()
#18 0x00007ffff71e2080 in g_signal_emit_valist () at
/lib64/libgobject-2.0.so.0
#19 0x00007ffff71e21a3 in g_signal_emit () at /lib64/libgobject-2.0.so.0
#20 0x00007ffff72e61c9 in g_application_register () at
/lib64/libgio-2.0.so.0
#21 0x00007ffff72e689e in g_application_real_local_command_line () at
/lib64/libgio-2.0.so.0
#22 0x00007ffff72e6c46 in g_application_run () at /lib64/libgio-2.0.so.0
#23 0x00005555555ab2be in main ()
What is nautilus dlopening?
#12 0x00007ffff6544428 in __dlopen (file=<optimized out>,
mode=<optimized out>) at dlopen.c:87
args = {file = 0x555555933ce0
"/usr/lib64/nautilus/extensions-3.0/libtotem-properties-page.so", mode
= 1, new = 0x3, caller = 0x7ffff7064bff <g_module_open+799>
And, yes:
$ ldd /usr/lib64/nautilus/extensions-3.0/libtotem-properties-page.so |
grep elf
libelf.so.1 => /lib64/libelf.so.1 (0x00007f6d4f17c000)
So not everything links to libelf, and only things that link to it are
affected:
$ ldd /usr/lib64/libwebkit2gtk-4.0.so | grep elf
libelf.so.1 => /lib64/libelf.so.1 (0x00007f159b53c000)
I guess it's being transitively pulled into these libs via...
something... but I'm not sure via what.
Anyway, does debuginfod really need to always be initialized? Could it
be loaded only when running under gdb, perhaps? If it's not truly
needed, that would be the path of least resistance. Otherwise, I
suspect openssl 1.2 -> openssl 3.0 may be a more difficult transition
than expected.
Michael
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
