Created attachment 910902 [details] Output of emerge --info net-im/zoom Hello, I have found net-im/zoom hard crashes on my system. Running the zoom binary in /opt/zoom I receive an error message that says: ./zoom: error while loading shared libraries: libQt5QuickWidgets.so.5: cannot open shared object file: No such file or directory I ran the command ldd on the zoom binary, which yields this: linux-vdso.so.1 (0x00007ffd696cf000) libatomic.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/13/libatomic.so.1 (0x00007f10818d2000) ... libdbus-1.so.3 => /usr/lib64/libdbus-1.so.3 (0x00007f1073125000) libQt5QuickWidgets.so.5 => not found libQt5Quick.so.5 => not found libQt5Svg.so.5 => not found libQt5Widgets.so.5 => not found libQt5Gui.so.5 => not found libQt5Qml.so.5 => not found libQt5Network.so.5 => not found libQt5DBus.so.5 => not found libQt5Xml.so.5 => not found libQt5Core.so.5 => /usr/lib64/libQt5Core.so.5 (0x00007f1072b5e000) libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007f1072aeb000) ... libpciaccess.so.0 => /usr/lib64/libpciaccess.so.0 (0x00007f1070a51000) My workaround is to either specify the LD_LIBRARY_PATH or use the patchelf with the --set-rpath command on the zoom binary and point it to /opt/zoom/Qt/lib.
You are not supposed to execute /opt/zoom/zoom directly. Instead, start it with ZoomLauncher which will set up the correct library paths. The /usr/bin/zoom symlink points to ZoomLauncher (and not to zoom) for this reason.
(In reply to Ulrich Müller from comment #1) > You are not supposed to execute /opt/zoom/zoom directly. Instead, start it > with ZoomLauncher which will set up the correct library paths. > > The /usr/bin/zoom symlink points to ZoomLauncher (and not to zoom) for this > reason. Understood, running ZoomLauncher still yields an error for me. I have QT_QPA_PLATFORM set to wayland. Running it the improper way is the only way to get zoom to run on my system. Do you have an suggestions or anything you would need from me to understand what is going wrong? This is the error from ~/.zoom/logs/zoom_stdout_stderr.log ZoomLauncher started. Zoom path is: /opt/zoom cmd line: Start subprocess: /opt/zoom/zoom sucessfully, process pid: 20486 Class App Lib Possible Culprit Flags resip::Connection 656 656 resip::Data 36 36 resip::DnsResult 1080 1080 resip::Headers 1 1 resip::MsgHeaderScanner 40 40 resip::SipMessage 5224 5224 resip::TransportSelector 896 896 resip::Tuple 128 128 resip::UdpTransport 1144 1144 resip::GenericIPAddress 28 28 zoom started. Client: Breakpad is using Single Client Mode! client fd = -1 qt.qpa.xcb: could not connect to display qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found. This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. Available platform plugins are: minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb. zoom was exited due to a handled signal: 6 ZoomLauncher exit.
Is this a Gentoo specific problem, i.e. is it triggered by something that our ebuild does? Or does the problem also occur when you install from the upstream tarball?
I installed(In reply to Ulrich Müller from comment #3) > Is this a Gentoo specific problem, i.e. is it triggered by something that > our ebuild does? Or does the problem also occur when you install from the > upstream tarball? I believe this is an issue with the tarball from the zoom website. I installed Zoom using the "other linux os" option. When running the ldd command on the zoom binary in that tarball it provides the same output as before. It also provides the same message when I run it from the command line. The log is virtually the same as well, when running ZoomLauncher from the tarball. From the looks of it this bug should probably be reported to Zoom. However if patchelf --set-rpath Qt/lib ./zoom is ran zoom will start. Zoom does start with a crash report, however Zoom still runs. The crash report only pops up on the first execution of zoom.
Please report upstream. We used to start zoom in our own wrapper that would set LD_LIBRARY_PATH, but that caused other problems, see bug 904958. So we reverted to upstream's launcher. I'm also reluctant to do binary patching because that would be just a workaround and leave the real problem unfixed.
