After upgrading Qt5 to commit 3aeb8b79ba651293817ac01ea6f8e9119766017e, some apps fails to start with error messages as follows. ===== quot ===== % audacious qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in "" This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. zsh: abort (core dumped) audacious ===== End quot ===== At least multimedia/vlc and editors/libreoffice fails to start just as the same way. On the other hand, some other Qt5 apps, including x11/qterminal, security/keepassxc and editors/kate starts fine. Rebuilding multimedia/audacious and multimedia/audacious-plugins didn't help. (editors/libreoffice is too large to try. audacious is most handy to try.) Rebuilding all qt5-* and py*-qt5-* didn't help, too.
Forgot to mention. % uname -a FreeBSD *****.*****.local 13.1-STABLE FreeBSD 13.1-STABLE #587 stable/13-n253342-6e9ab1e63192-dirty: Thu Dec 29 12:01:00 JST 2022 ****@*****.*****.local:/usr/obj/usr/src/amd64.amd64/sys/***** amd64 Previous working state was at commit 81ff56db9fc6aff09acba4a787f09ecdc5aa2360. At first, updated ports tree and rebuilt with poudriere, cloned built repo to /usr/ports/packages/All and installed with pkg_replace -a -PP, which went without error. *pkg_replace looks for packages in /usr/ports/packages/All by default. Then, restarted system and after that, audacious and so on stops starting. Next rebuilt was done by pkg_replace like below. #pkg_replace -c -v -m 'DISABLE_VULNERABILITIES=yes' -W -w -f -b multimedia/audacious multimedia/audacious-plugins && portsclean -C This went fine but rebuilt binary fails to start with the same error. Then, rebuilt qt5 as below. #pkg_replace -c -v -m 'DISABLE_VULNERABILITIES=yes' -W -w -f -b qt5-\* && portsclean -C Which built and installed fine but no success.
Backtrace of audacious. Sorry, not a debug build. % lldb --core ~/audacious.core --file /usr/local/bin/audacious (lldb) target create "/usr/local/bin/audacious" --core "/home/*****/audacious.core" Core file '/home/*****/audacious.core' (x86_64) was loaded. (lldb) bt * thread #1, name = 'audacious', stop reason = signal SIGABRT * frame #0: 0x000000082939e6ea libc.so.7`__sys_thr_kill + 10 frame #1: 0x0000000829313624 libc.so.7`__raise + 52 frame #2: 0x00000008293c960c libc.so.7`abort + 76 frame #3: 0x000000082cc67679 libQt5Core.so.5`___lldb_unnamed_symbol7134 + 9 frame #4: 0x000000082cc6c1e2 libQt5Core.so.5`QMessageLogger::fatal(char const*, ...) const + 216 frame #5: 0x0000000873f4da99 libQt5Gui.so.5`QGuiApplicationPrivate::createPlatformIntegration() + 6681 frame #6: 0x0000000873f4dac0 libQt5Gui.so.5`QGuiApplicationPrivate::createEventDispatcher() + 32 frame #7: 0x000000082ce353c6 libQt5Core.so.5`QCoreApplicationPrivate::init() + 1510 frame #8: 0x0000000873f480ba libQt5Gui.so.5`QGuiApplicationPrivate::init() + 42 frame #9: 0x0000000878297dce libQt5Widgets.so.5`QApplicationPrivate::init() + 14 frame #10: 0x00000008773fbcdd libaudqt.so.2`audqt::init() + 109 frame #11: 0x000000089ca1b86c qtui.so`___lldb_unnamed_symbol1358 + 12 frame #12: 0x000000082294e441 libaudcore.so.5`___lldb_unnamed_symbol1189 + 113 frame #13: 0x00000008229615d6 libaudcore.so.5`___lldb_unnamed_symbol1444 + 422 frame #14: 0x000000082296797d libaudcore.so.5`aud_run() + 45 frame #15: 0x000000000021bec4 audacious`___lldb_unnamed_symbol557 + 1908 frame #16: 0x000000000021b545 audacious`___lldb_unnamed_symbol1516 + 261
Backtrace of editors/libreoffice. Non-debug build. % lldb --core ~/soffice.bin.core --file /usr/local/lib/libreoffice/program/soffice.bin (lldb) target create "/usr/local/lib/libreoffice/program/soffice.bin" --core "/home/*****/soffice.bin.core" Core file '/home/*****/soffice.bin.core' (x86_64) was loaded. (lldb) bt * thread #1, name = 'soffice.bin', stop reason = signal SIGABRT * frame #0: 0x00000008241426ea libc.so.7`__sys_thr_kill + 10 frame #1: 0x00000008240b7624 libc.so.7`__raise + 52 frame #2: 0x000000082416d60c libc.so.7`abort + 76 frame #3: 0x000000087da67679 libQt5Core.so.5`___lldb_unnamed_symbol7134 + 9 frame #4: 0x000000087da6c1e2 libQt5Core.so.5`QMessageLogger::fatal(char const*, ...) const + 216 frame #5: 0x000000087f04aa99 libQt5Gui.so.5`QGuiApplicationPrivate::createPlatformIntegration() + 6681 frame #6: 0x000000087f04aac0 libQt5Gui.so.5`QGuiApplicationPrivate::createEventDispatcher() + 32 frame #7: 0x000000087dc353c6 libQt5Core.so.5`QCoreApplicationPrivate::init() + 1510 frame #8: 0x000000087f0450ba libQt5Gui.so.5`QGuiApplicationPrivate::init() + 42 frame #9: 0x0000000880e97dce libQt5Widgets.so.5`QApplicationPrivate::init() + 14 frame #10: 0x000000087d37b962 libvclplug_qt5lo.so`QtInstance::CreateQApplication(int&, char**) + 130 frame #11: 0x000000087d37baf6 libvclplug_qt5lo.so`create_SalInstance + 102 frame #12: 0x00000008379c89e0 libvcllo.so`___lldb_unnamed_symbol19753 + 352 frame #13: 0x00000008379c856b libvcllo.so`___lldb_unnamed_symbol19751 + 571 frame #14: 0x0000000837a2be9c libvcllo.so`InitVCL() + 172 frame #15: 0x0000000837a2bb2b libvcllo.so`ImplSVMain() + 123 frame #16: 0x00000008220850f4 libsofficeapp.so`soffice_main + 260 frame #17: 0x00000000002019a0 soffice.bin`___lldb_unnamed_symbol17 + 16 frame #18: 0x0000000000201755 soffice.bin`___lldb_unnamed_symbol17 + 261 (lldb)
Backtrace of multimedia/vlc. Non-debug build. % lldb --core ~/vlc.core --file /usr/local/bin/vlc (lldb) target create "/usr/local/bin/vlc" --core "/home/*****/vlc.core" Core file '/home/*****/vlc.core' (x86_64) was loaded. (lldb) bt * thread #1, name = 'vlc', stop reason = signal SIGABRT * frame #0: 0x00000008227896ea libc.so.7`__sys_thr_kill + 10 frame #1: 0x00000008226fe624 libc.so.7`__raise + 52 frame #2: 0x00000008227b460c libc.so.7`abort + 76 frame #3: 0x000000087d667679 libQt5Core.so.5`___lldb_unnamed_symbol7134 + 9 frame #4: 0x000000087d66c1e2 libQt5Core.so.5`QMessageLogger::fatal(char const*, ...) const + 216 frame #5: 0x000000087cc93a99 libQt5Gui.so.5`QGuiApplicationPrivate::createPlatformIntegration() + 6681 frame #6: 0x000000087cc93ac0 libQt5Gui.so.5`QGuiApplicationPrivate::createEventDispatcher() + 32 frame #7: 0x000000087d8353c6 libQt5Core.so.5`QCoreApplicationPrivate::init() + 1510 frame #8: 0x000000087cc8e0ba libQt5Gui.so.5`QGuiApplicationPrivate::init() + 42 frame #9: 0x000000087b297dce libQt5Widgets.so.5`QApplicationPrivate::init() + 14 frame #10: 0x0000000878defb80 libqt_plugin.so`___lldb_unnamed_symbol4088 + 208 frame #11: 0x0000000878defa46 libqt_plugin.so`___lldb_unnamed_symbol4086 + 38 frame #12: 0x000000082177d9ae libthr.so.3`___lldb_unnamed_symbol556 + 318 (lldb)
Moin moin So far I have not experienced any issues myself. mfg Tobias
Hi, I have also seen no issues so far. Your error message has some very specific information about an xcb plugin failing to start, I think you should investigate that. you should also check your Xorg logs, including the xsession log (usually somewhere in home directory, depends on how you start your X session). There could be indications there on why xcb (which is a basic X11 mechanism) fails. Maybe you need to rebuild some more basic Xorg component? a quick search on the internet does turn out some pointers for your problem, for example: https://stackoverflow.com/questions/17106315/failed-to-load-platform-plugin-xcb-while-launching-qt5-app-on-linux-without Have you tried googling the original error message?
(In reply to Guido Falsi from comment #6) Some info only shows what I've done helped, but doesn't for me. *Rebuilding qt-gui and qt-dbus, but it's rebuilt after first update. The site you pointed looks indicating that libqxcb.so is not existing on correct place, but % pkg which -o /usr/local/lib/qt5/plugins/platforms/libqxcb.so /usr/local/lib/qt5/plugins/platforms/libqxcb.so was installed by package x11-toolkits/qt5-gui it looks existing at correct place. Symlinking /usr/local/lib/qt5/plugins/platforms/ directory under /usr/local/bin/ looks incorrect for me, so not tried. But strangely, updating ports to commit 0409cf54eb1c753bc8dc390b5c97c5289feeb2a9 state finally resolved the issue. There are toooo many commits (mostly python and ruby related) and could not determine which commit actually helped. I'll close this as "overcome by event" after some more testing. Thanks! FYI: Output from `pkg version -o -v | rg '<'` just before starting upgrading was as below. Note that compiz-related ones are locked and x11-fonts/noto-* is failing. % pkg version -o -v | rg '<' sysutils/accountsservice < needs updating (index has 0.6.55_4) astro/cfitsio < needs updating (index has 4.2.0) x11-wm/compiz-plugins-extra < needs updating (index has 0.8.8_12) x11-wm/compiz-plugins-main < needs updating (index has 0.8.8_10) ftp/curl < needs updating (index has 7.87.0) audio/fluidsynth < needs updating (index has 2.3.1) graphics/gdal < needs updating (index has 3.5.3) graphics/geos < needs updating (index has 3.11.1) net/gssdp < needs updating (index has 1.6.2) net/gssdp14 < needs updating (index has 1.4.1) net/gupnp < needs updating (index has 1.6.2) net/gupnp14 < needs updating (index has 1.4.4) devel/indi < needs updating (index has 1.9.6_1) x11-fonts/noto-hk < needs updating (index has 2.004) x11-fonts/noto-jp < needs updating (index has 2.004) x11-fonts/noto-kr < needs updating (index has 2.004) x11-fonts/noto-sc < needs updating (index has 2.004) x11-fonts/noto-tc < needs updating (index has 2.004) devel/p5-Clone < needs updating (index has 0.46) devel/p5-Exporter-Tiny < needs updating (index has 1.004004) www/p5-HTML-Parser < needs updating (index has 3.80) www/p5-HTTP-Message < needs updating (index has 6.44) devel/p5-Log-Log4perl < needs updating (index has 1.57) devel/p5-Path-Tiny < needs updating (index has 0.142) net/p5-URI < needs updating (index has 5.17) misc/pciids < needs updating (index has 20221028) devel/protobuf < needs updating (index has 3.21.9,1) dns/public_suffix_list < needs updating (index has 20221030) devel/py-astroid < needs updating (index has 2.12.13) textproc/py-charset-normalizer < needs updating (index has 3.0.1) devel/py-lazy-object-proxy < needs updating (index has 1.8.0) devel/py-pbr < needs updating (index has 5.11.0) devel/py-pip < needs updating (index has 22.3.1) devel/py-platformdirs < needs updating (index has 2.5.4) sysutils/py-psutil < needs updating (index has 5.9.4) www/py-pyjwt < needs updating (index has 2.6.0) www/py-requests < needs updating (index has 2.28.1_1) textproc/py-sphinx-copybutton < needs updating (index has 0.5.1) textproc/py-sphinxcontrib-towncrier < needs updating (index has 0.3.2a0) textproc/py-tomlkit < needs updating (index has 0.11.6) textproc/py-towncrier < needs updating (index has 22.12.0_1) devel/ruby-gems < needs updating (index has 3.3.26) textproc/rubygem-asciidoctor < needs updating (index has 2.0.18) graphics/webp < needs updating (index has 1.2.4_1)
Confirmed fixed now. Maybe any of updates I've listed in my previous post (or anything newly pulled into by it) should fixed the issue. I think would be bitten by incomplete intermediate state. Closing as "Overcome By Events".
Reopen. This problem happenes again at commit 1fe9749d833c521b518e1190086ef02c7f3e31da. (Qt: Update Qt 5 to 5.15.8) and newer (at least commit 78bc61928a8c4df2058374b4999d8fd681b738f8 is still NG). Known to be OK was at commit 885e50f344100a4ee6c5829ef87effef378d4f70. On first reboot after updating to commit 1c0f318b761394f2ee0ea17bb6df7124f901ae47, this problem rappeared. Unfortunately, doing below didn't help. 1. Rebuilding/reinstalling qt5-gui. 2. Rebuilding/reinstalling whole bunch of installed qt5-* 3. Rebuilding/reinstalling affected ports 4. Rebuilding/reinstalling qt5-gui and its direct dependencies 5. Rebuilding/reinstalling multimedia/audacious-plugins and its dependencies with `pkg_replace -RR -f -b multimedia/audacious-plugins` Currently, ports below are currently known to be affected. editors/libreoffice multimedia/audacious multimedia/vlc Ports below are currently known NOT to be affected, even though they are Qt5 apps. security/keepassxc x11/qterminal math/kcalc accessibility/kmag x11/konsole Maybe something are missed to be updated on ports tree.
Changed summary to reflect current state. Additional info: Base is stable/13, amd64 at commit 16dd69d46577bea5807d49340d894a68f8ea7d3a.
(In reply to Tomoaki AOKI from comment #10) What does this command print: find -s /usr/local/lib/qt5/plugins/ -not -type d -exec pkg which {} + | sed 's/.* //' | sort -u Were all the packages it lists rebuilt?
(In reply to Tijl Coosemans from comment #11) Thanks for your comment. Not all are rebuilt, but they seems to be clients, right? At least, qt5-* are rebuilt. % find -s /usr/local/lib/qt5/plugins/ -not -type d -exec pkg which {} + | sed 's/.* //' | sort -u akonadi-22.12.1 akonadi-calendar-22.12.1 akonadi-contacts-22.12.1 akonadi-import-wizard-22.12.1 akonadi-mime-22.12.1 akonadi-search-22.12.1 akregator-22.12.1 ark-22.12.1 audiocd-kio-22.12.1 baloo-widgets-22.12.1 cantor-22.12.1_3 dolphin-22.12.1 dragon-player-22.12.1 falkon-22.12.1 fcitx-qt5-1.2.7 gwenview-22.12.1 k3b-22.12.1 kaccounts-integration-22.12.1 kaddressbook-22.12.1 kalarm-22.12.1 kamera-22.12.1 kate-22.12.1 kcron-22.12.1 kdegraphics-svgpart-22.12.1 kdegraphics-thumbnailers-22.12.1 kdemultimedia-ffmpegthumbs-22.12.1 kdenetwork-filesharing-22.12.1 kdenlive-22.12.1_1 kdepim-addons-22.12.1 kdepim-runtime-22.12.1_1 kdf-22.12.1 kf5-baloo-5.101.0 kf5-frameworkintegration-5.101.0 kf5-kauth-5.101.0 kf5-kcompletion-5.101.0 kf5-kconfigwidgets-5.101.0 kf5-kdelibs4support-5.101.0 kf5-kdewebkit-5.101.0 kf5-kemoticons-5.101.0 kf5-kfilemetadata-5.101.0_1 kf5-kglobalaccel-5.101.0 kf5-khtml-5.101.0 kf5-ki18n-5.101.0 kf5-kiconthemes-5.101.0 kf5-kidletime-5.101.0 kf5-kimageformats-5.101.0_1 kf5-kio-5.101.0 kf5-kitemviews-5.101.0 kf5-knewstuff-5.101.0 kf5-kplotting-5.101.0 kf5-kross-5.101.0 kf5-ktexteditor-5.101.0 kf5-ktextwidgets-5.101.0 kf5-kwidgetsaddons-5.101.0 kf5-kwindowsystem-5.101.0 kf5-kxmlgui-5.101.0 kf5-plasma-framework-5.101.0 kf5-purpose-5.101.0 kf5-qqc2-desktop-style-5.101.0 kf5-sonnet-5.101.0 kig-22.12.1 kio-extras-22.12.1 kipi-plugins-22.12.1 kldap-22.12.1 kmail-22.12.1 kmail-account-wizard-22.12.1 kmailtransport-22.12.1 kmplot-22.12.1 konsole-22.12.1 kontact-22.12.1 kopete-22.12.1 korganizer-22.12.1 kpimtextedit-22.12.1 krdc-22.12.1 krfb-22.12.1 kwalletmanager-22.12.1 libkcddb-22.12.1 libkdepim-22.12.1 mailcommon-22.12.1 marble-22.12.1 messagelib-22.12.1 okular-22.12.1_3 palapeli-22.12.1 phonon-gstreamer-qt5-4.10.0_4 pimcommon-22.12.1 plasma5-breeze-5.24.7 plasma5-discover-5.24.7 plasma5-kactivitymanagerd-5.24.7 plasma5-kde-cli-tools-5.24.7 plasma5-kde-gtk-config-5.24.7 plasma5-kdeplasma-addons-5.24.7 plasma5-kgamma5-5.24.7 plasma5-khotkeys-5.24.7 plasma5-kinfocenter-5.24.7 plasma5-kscreen-5.24.7 plasma5-kscreenlocker-5.24.7 plasma5-ksystemstats-5.24.7 plasma5-kwayland-integration-5.24.7 plasma5-kwin-5.24.7 plasma5-kwrited-5.24.7 plasma5-layer-shell-qt-5.24.7 plasma5-libkscreen-5.24.7 plasma5-libksysguard-5.24.7 plasma5-oxygen-5.24.7 plasma5-plasma-browser-integration-5.24.7 plasma5-plasma-desktop-5.24.7 plasma5-plasma-disks-5.24.7 plasma5-plasma-integration-5.24.7 plasma5-plasma-pa-5.24.7 plasma5-plasma-sdk-5.24.7 plasma5-plasma-workspace-5.24.7_1 plasma5-powerdevil-5.24.7 plasma5-systemsettings-5.24.7 print-manager-22.12.1 py39-qt5-pyqt-5.15.7 qt5-declarative-5.15.8p21 qt5-designer-5.15.8p1 qt5-gui-5.15.8p157 qt5-imageformats-5.15.8p6 qt5-location-5.15.8p3 qt5-multimedia-5.15.8p1 qt5-network-5.15.8p157 qt5-printsupport-5.15.8p157 qt5-quick3d-5.15.8p1 qt5-sensors-5.15.8p0 qt5-speech-5.15.8p1 qt5-sqldrivers-mysql-5.15.8p157 qt5-sqldrivers-sqlite3-5.15.8p157 qt5-svg-5.15.8p8 qt5-virtualkeyboard-5.15.8p0 qt5-wayland-5.15.8p57 qt5-webengine-5.15.2_7 qt5ct-1.5 rocs-22.12.1
(In reply to Tomoaki AOKI from comment #12) Limit the search to /usr/local/lib/qt5/plugins/plat*
(In reply to Tijl Coosemans from comment #13) Already started rebuilding the ports listed on comment #12 (not yet finished) with command below. pkg_replace -c -v -m 'DISABLE_VULNERABILITIES=yes' -W -w -f -n `find -s /usr/local/lib/qt5/plugins/ -not -type d -exec pkg which {} + | sed 's/.* //' | sort -u` && portsclean -C And the narrowed down list is as follows. % find -s /usr/local/lib/qt5/plugins/plat* -not -type d -exec pkg which {} + | sed 's/.* //' | sort -u fcitx-qt5-1.2.7 plasma5-plasma-integration-5.24.7 qt5-gui-5.15.8p157 qt5-virtualkeyboard-5.15.8p0 qt5-wayland-5.15.8p57 qt5ct-1.5
What happens when environment variables such as LC_* or LANG are unset?
(In reply to Tomoaki AOKI from comment #14) Rebuilding/reinstalling of ports listed on comment 12 are finished, and rebooted. Without luck. Tested with multimedia/vlc. *Other 2 affected ports are temporarily rebuilt with other toolkit. Gtk3 for editors/libreoffice and Gtk2 for multimedia/audacious*. *Options for pkg_replace was wrong (was for dry-run). -n is actually -b. Additionally rebuilding vlc alone didn't help, too. But one good news is that known-to-be-OK ports are still OK.
(In reply to Tatsuki Makino from comment #15) Tried both env LC_ALL= LC_MESSAGES= LANG= vlc env -u LC_ALL -u LC_MESSAGES -u LANG vlc without luck, unfortunately. % env -u LC_ALL -u LC_MESSAGES -u LANG vlc VLC media player 3.0.18 Vetinari (revision fb4ef23dde67) [00000008295c7060] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in "" This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. zsh: abort (core dumped) env -u LC_ALL -u LC_MESSAGES -u LANG vlc % lldb --core ~/vlc.core --file /usr/local/bin/vlc (lldb) target create "/usr/local/bin/vlc" --core "/home/junchoon/vlc.core" Core file '/home/junchoon/vlc.core' (x86_64) was loaded. (lldb) bt * thread #1, name = 'vlc', stop reason = signal SIGABRT * frame #0: 0x000000082314d6fa libc.so.7`__sys_thr_kill + 10 frame #1: 0x00000008230c2624 libc.so.7`__raise + 52 frame #2: 0x000000082317861c libc.so.7`abort + 76 frame #3: 0x0000000866067679 libQt5Core.so.5`___lldb_unnamed_symbol7134 + 9 frame #4: 0x000000086606c1e2 libQt5Core.so.5`QMessageLogger::fatal(char const*, ...) const + 216 frame #5: 0x0000000861c78d49 libQt5Gui.so.5`QGuiApplicationPrivate::createPlatformIntegration() + 6681 frame #6: 0x0000000861c78d70 libQt5Gui.so.5`QGuiApplicationPrivate::createEventDispatcher() + 32 frame #7: 0x00000008662353a6 libQt5Core.so.5`QCoreApplicationPrivate::init() + 1510 frame #8: 0x0000000861c7336a libQt5Gui.so.5`QGuiApplicationPrivate::init() + 42 frame #9: 0x0000000864a975be libQt5Widgets.so.5`QApplicationPrivate::init() + 14 frame #10: 0x0000000860233af0 libqt_plugin.so`___lldb_unnamed_symbol4088 + 208 frame #11: 0x00000008602339b6 libqt_plugin.so`___lldb_unnamed_symbol4086 + 38 frame #12: 0x0000000821ba29ae libthr.so.3`___lldb_unnamed_symbol556 + 318 (lldb)
(In reply to Tomoaki AOKI from comment #14) Are you using wayland? Because then xcb is the wrong platform and you could try running "env QT_QPA_PLATFORM=wayland vlc".
Perhaps: $ env QT_DEBUG_PLUGINS=1 vlc can give some clues?
(In reply to Tijl Coosemans from comment #18) No, but not 100% sure. I start up my PC on CLI, then, manually startx. It's based upon an old configuration, before Wayland appears. But Wayland is pulled in as a dependency by some ports (by default). So I cannot be 100% sure. And % env QT_QPA_PLATFORM=wayland vlc VLC media player 3.0.18 Vetinari (revision fb4ef23dde67) [000000082a599060] main libvlc: vlcはデフォルトのインターフェースで実行しています。インターフェースのない vlc を使用するには'cvlc'を使用してください。 qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in "" This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. zsh: abort (core dumped) env QT_QPA_PLATFORM=wayland vlc % lldb --core ~/vlc.core --file /usr/local/bin/vlc (lldb) target create "/usr/local/bin/vlc" --core "/home/junchoon/vlc.core" Core file '/home/junchoon/vlc.core' (x86_64) was loaded. (lldb) bt * thread #1, name = 'vlc', stop reason = signal SIGABRT * frame #0: 0x0000000822f926fa libc.so.7`__sys_thr_kill + 10 frame #1: 0x0000000822f07624 libc.so.7`__raise + 52 frame #2: 0x0000000822fbd61c libc.so.7`abort + 76 frame #3: 0x0000000868267679 libQt5Core.so.5`___lldb_unnamed_symbol7134 + 9 frame #4: 0x000000086826c1e2 libQt5Core.so.5`QMessageLogger::fatal(char const*, ...) const + 216 frame #5: 0x0000000866dc7d49 libQt5Gui.so.5`QGuiApplicationPrivate::createPlatformIntegration() + 6681 frame #6: 0x0000000866dc7d70 libQt5Gui.so.5`QGuiApplicationPrivate::createEventDispatcher() + 32 frame #7: 0x00000008684353a6 libQt5Core.so.5`QCoreApplicationPrivate::init() + 1510 frame #8: 0x0000000866dc236a libQt5Gui.so.5`QGuiApplicationPrivate::init() + 42 frame #9: 0x00000008666975be libQt5Widgets.so.5`QApplicationPrivate::init() + 14 frame #10: 0x0000000861effaf0 libqt_plugin.so`___lldb_unnamed_symbol4088 + 208 frame #11: 0x0000000861eff9b6 libqt_plugin.so`___lldb_unnamed_symbol4086 + 38 frame #12: 0x0000000821f8c9ae libthr.so.3`___lldb_unnamed_symbol556 + 318 (lldb)
(In reply to Bengt Ahlgren from comment #19) Tried. % env QT_DEBUG_PLUGINS=1 vlc VLC media player 3.0.18 Vetinari (revision fb4ef23dde67) [000000082953e060] main libvlc: vlcはデフォルトのインターフェースで実行しています。インターフェースのない vlc を使用するには'cvlc'を使用してください。 QFactoryLoader::QFactoryLoader() checking directory path "/usr/local/bin/platforms" ... qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in "" This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. zsh: abort (core dumped) env QT_DEBUG_PLUGINS=1 vlc % lldb --core ~/vlc.core --file /usr/local/bin/vlc (lldb) target create "/usr/local/bin/vlc" --core "/home/junchoon/vlc.core" Core file '/home/junchoon/vlc.core' (x86_64) was loaded. (lldb) bt * thread #1, name = 'vlc', stop reason = signal SIGABRT * frame #0: 0x00000008218b76fa libc.so.7`__sys_thr_kill + 10 frame #1: 0x000000082182c624 libc.so.7`__raise + 52 frame #2: 0x00000008218e261c libc.so.7`abort + 76 frame #3: 0x0000000866667679 libQt5Core.so.5`___lldb_unnamed_symbol7134 + 9 frame #4: 0x000000086666c1e2 libQt5Core.so.5`QMessageLogger::fatal(char const*, ...) const + 216 frame #5: 0x0000000862dd0d49 libQt5Gui.so.5`QGuiApplicationPrivate::createPlatformIntegration() + 6681 frame #6: 0x0000000862dd0d70 libQt5Gui.so.5`QGuiApplicationPrivate::createEventDispatcher() + 32 frame #7: 0x00000008668353a6 libQt5Core.so.5`QCoreApplicationPrivate::init() + 1510 frame #8: 0x0000000862dcb36a libQt5Gui.so.5`QGuiApplicationPrivate::init() + 42 frame #9: 0x0000000863e975be libQt5Widgets.so.5`QApplicationPrivate::init() + 14 frame #10: 0x0000000861ec4af0 libqt_plugin.so`___lldb_unnamed_symbol4088 + 208 frame #11: 0x0000000861ec49b6 libqt_plugin.so`___lldb_unnamed_symbol4086 + 38 frame #12: 0x00000008228859ae libthr.so.3`___lldb_unnamed_symbol556 + 318 (lldb)
(In reply to Tomoaki AOKI from comment #21) Yes, and there you see that it looks in the wrong place for the plugin. I however have no clue to why.
(In reply to Bengt Ahlgren from comment #22) Yes, /usr/local/bin/platforms is odd for FreeBSD (but Linux?). It SHALL be /usr/local/lib/qt5/plugins/platforms. Something should incorrectly overridden the default (or any of FreeBSD patch is lost). Just to test, doing # ln -s /usr/local/lib/qt5/plugins/platforms /usr/local/bin/platforms as root, and then vlc started up successfully, but with button icons being simple rectangle. Maybe more things are overridden (or kept Linux defaults). % env QT_DEBUG_PLUGINS=1 vlc VLC media player 3.0.18 Vetinari (revision fb4ef23dde67) [0000000828b00060] main libvlc: vlcはデフォルトのインターフェースで実行しています。インターフェースのない vlc を使用するには'cvlc'を使用してください。 QFactoryLoader::QFactoryLoader() checking directory path "/usr/local/bin/platforms" ... QFactoryLoader::QFactoryLoader() looking at "/usr/local/bin/platforms/libqbsdfb.so" Found metadata in lib /usr/local/lib/qt5/plugins/platforms/libqbsdfb.so, metadata= { "IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3", "MetaData": { "Keys": [ "bsdfb" ] }, "archreq": 2, "className": "QBsdFbIntegrationPlugin", "debug": false, "version": 331520 } Got keys from plugin meta data ("bsdfb") QFactoryLoader::QFactoryLoader() looking at "/usr/local/bin/platforms/libqminimal.so" Found metadata in lib /usr/local/lib/qt5/plugins/platforms/libqminimal.so, metadata= { "IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3", "MetaData": { "Keys": [ "minimal" ] }, "archreq": 2, "className": "QMinimalIntegrationPlugin", "debug": false, "version": 331520 } Got keys from plugin meta data ("minimal") QFactoryLoader::QFactoryLoader() looking at "/usr/local/bin/platforms/libqoffscreen.so" Found metadata in lib /usr/local/lib/qt5/plugins/platforms/libqoffscreen.so, metadata= { "IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3", "MetaData": { "Keys": [ "offscreen" ] }, "archreq": 2, "className": "QOffscreenIntegrationPlugin", "debug": false, "version": 331520 } Got keys from plugin meta data ("offscreen") QFactoryLoader::QFactoryLoader() looking at "/usr/local/bin/platforms/libqvnc.so" Found metadata in lib /usr/local/lib/qt5/plugins/platforms/libqvnc.so, metadata= { "IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3", "MetaData": { "Keys": [ "vnc" ] }, "archreq": 2, "className": "QVncIntegrationPlugin", "debug": false, "version": 331520 } Got keys from plugin meta data ("vnc") QFactoryLoader::QFactoryLoader() looking at "/usr/local/bin/platforms/libqwayland-egl.so" Found metadata in lib /usr/local/lib/qt5/plugins/platforms/libqwayland-egl.so, metadata= { "IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3", "MetaData": { "Keys": [ "wayland-egl" ] }, "archreq": 2, "className": "QWaylandEglPlatformIntegrationPlugin", "debug": false, "version": 331520 } Got keys from plugin meta data ("wayland-egl") QFactoryLoader::QFactoryLoader() looking at "/usr/local/bin/platforms/libqwayland-generic.so" Found metadata in lib /usr/local/lib/qt5/plugins/platforms/libqwayland-generic.so, metadata= { "IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3", "MetaData": { "Keys": [ "wayland" ] }, "archreq": 2, "className": "QWaylandIntegrationPlugin", "debug": false, "version": 331520 } Got keys from plugin meta data ("wayland") QFactoryLoader::QFactoryLoader() looking at "/usr/local/bin/platforms/libqwayland-xcomposite-egl.so" Found metadata in lib /usr/local/lib/qt5/plugins/platforms/libqwayland-xcomposite-egl.so, metadata= { "IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3", "MetaData": { "Keys": [ "wayland-xcomposite-egl" ] }, "archreq": 2, "className": "QWaylandXCompositeEglPlatformIntegrationPlugin", "debug": false, "version": 331520 } Got keys from plugin meta data ("wayland-xcomposite-egl") QFactoryLoader::QFactoryLoader() looking at "/usr/local/bin/platforms/libqwayland-xcomposite-glx.so" Found metadata in lib /usr/local/lib/qt5/plugins/platforms/libqwayland-xcomposite-glx.so, metadata= { "IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3", "MetaData": { "Keys": [ "wayland-xcomposite-glx" ] }, "archreq": 2, "className": "QWaylandXCompositeGlxPlatformIntegrationPlugin", "debug": false, "version": 331520 } Got keys from plugin meta data ("wayland-xcomposite-glx") QFactoryLoader::QFactoryLoader() looking at "/usr/local/bin/platforms/libqxcb.so" Found metadata in lib /usr/local/lib/qt5/plugins/platforms/libqxcb.so, metadata= { "IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3", "MetaData": { "Keys": [ "xcb" ] }, "archreq": 2, "className": "QXcbIntegrationPlugin", "debug": false, "version": 331520 } Got keys from plugin meta data ("xcb") loaded library "/usr/local/lib/qt5/plugins/platforms/libqxcb.so" loaded library "Xcursor" QFactoryLoader::QFactoryLoader() checking directory path "/usr/local/bin/platformthemes" ... QFactoryLoader::QFactoryLoader() checking directory path "/usr/local/bin/platforminputcontexts" ... QFactoryLoader::QFactoryLoader() checking directory path "/usr/local/bin/styles" ... QFactoryLoader::QFactoryLoader() checking directory path "/usr/local/bin/iconengines" ... QFactoryLoader::QFactoryLoader() checking directory path "/usr/local/bin/imageformats" ... QFactoryLoader::QFactoryLoader() checking directory path "/usr/local/bin/xcbglintegrations" ... QFactoryLoader::QFactoryLoader() checking directory path "/usr/local/bin/accessible" ... QFactoryLoader::QFactoryLoader() checking directory path "/usr/local/bin/accessiblebridge" ... [0000000828af2be0] main playlist: playlist is empty
Are there any environment variables defined? "env | grep QT"
(In reply to Tijl Coosemans from comment #24) % env | grep QT QT_FONT_DPI=143 QT_IM_MODULE=fcitx QT_QPA_PLATFORMTHEME=qt5ct QT_SCALE_FACTOR=2
Are there any other XDG_* environment variables? Because your vlc has not reached the following console output. [0000000801059060] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-tatsuki' [000000080115ebe0] main playlist: playlist is empty
(In reply to Tatsuki Makino from comment #26) Strangely, environment variables are unchanged (at least manually) for years. But here we go. Host FQDN andUUID are displayed but hidden here. % env | grep XDG XDG_CURRENT_DESKTOP=MATE XDG_RUNTIME_DIR=/var/run/user/1001 XDG_SESSION_COOKIE=(FQDN)-(UUID)
(In reply to Tomoaki AOKI from comment #27) > XDG_RUNTIME_DIR=/var/run/user/1001 Some programs will behave incorrectly if XDG_RUNTIME_DIR is set. It is safer not to set this value manually.
(In reply to Tatsuki Makino from comment #28) I've never set it manually, if I recall correctly. So any of daemons/apps sets it automatically on starting up Mate DE.
... environment variables may not be so relevant. However, we continue to look at things that are less relevant but often missed. First, make sure that the file named qt.conf is not found anywhere in ${LOCALBASE}. Then reinstall qt5-qmake. It should be built in the cleanest possible environment or from official package. After that, rebuild qt5-gui and qt5-*.
(In reply to Tatsuki Makino from comment #30) Found code that sets XDG_RUNTIME_DIR in ~/.xinitrc, but the value was different, so it should be overridden. And no such variable set on vty, which invoked startx. Confirmed there's no qt.conf under /usr/local/. # bfs /usr/local/ -name "qt*.conf" # To be sure, rebuilt qt5-qmake, qt5-gui, then qt5-* as you pointed, rebooted, without luck. % env QT_DEBUG_PLUGINS=1 vlc VLC media player 3.0.18 Vetinari (revision fb4ef23dde67) [0000000828a7a060] main libvlc: vlcはデフォルトのインターフェースで実行しています。インターフェースのない vlc を使用するには'cvlc'を使用してください。 QFactoryLoader::QFactoryLoader() checking directory path "/usr/local/bin/platforms" ... qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in "" This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. zsh: abort (core dumped) env QT_DEBUG_PLUGINS=1 vlc % lldb --core ~/vlc.core --file /usr/local/bin/vlc (lldb) target create "/usr/local/bin/vlc" --core "/home/junchoon/vlc.core" Core file '/home/junchoon/vlc.core' (x86_64) was loaded. (lldb) bt * thread #1, name = 'vlc', stop reason = signal SIGABRT * frame #0: 0x00000008216966fa libc.so.7`__sys_thr_kill + 10 frame #1: 0x000000082160b624 libc.so.7`__raise + 52 frame #2: 0x00000008216c161c libc.so.7`abort + 76 frame #3: 0x0000000869467679 libQt5Core.so.5`___lldb_unnamed_symbol7134 + 9 frame #4: 0x000000086946c1e2 libQt5Core.so.5`QMessageLogger::fatal(char const*, ...) const + 216 frame #5: 0x0000000867746d49 libQt5Gui.so.5`QGuiApplicationPrivate::createPlatformIntegration() + 6681 frame #6: 0x0000000867746d70 libQt5Gui.so.5`QGuiApplicationPrivate::createEventDispatcher() + 32 frame #7: 0x00000008696353a6 libQt5Core.so.5`QCoreApplicationPrivate::init() + 1510 frame #8: 0x000000086774136a libQt5Gui.so.5`QGuiApplicationPrivate::init() + 42 frame #9: 0x0000000866c97dde libQt5Widgets.so.5`QApplicationPrivate::init() + 14 frame #10: 0x00000008644beaf0 libqt_plugin.so`___lldb_unnamed_symbol4088 + 208 frame #11: 0x00000008644be9b6 libqt_plugin.so`___lldb_unnamed_symbol4086 + 38 frame #12: 0x00000008213da9ae libthr.so.3`___lldb_unnamed_symbol556 + 318 (lldb) Note that the symlink I've mentioned on Comment 23 is already removed. As www/qt5-webkit is installed as an dependency, rebuilding qt5-* requires a fair amount of time, so the turn-around time to answer becomes long.
(In reply to Tomoaki AOKI from comment #31) > Found code that sets XDG_RUNTIME_DIR in ~/.xinitrc, but the value was different, so it should be overridden. And no such variable set on vty, which invoked startx. If XDG_RUNTIME_DIR is set in .xinitrc, there is a value that prevents dconf from working properly. I don't think dconf is involved... Also, there is *-qt5-*. (e.g. qscintilla2-qt5) In addition, make sure that /usr/local/lib/compat/pkg/* has not accumulated too many unnecessary libraries. This seems to be set by ldconfig_paths in {/etc,/etc/defaults}/rc.conf and is used at high priority.
(In reply to Tatsuki Makino from comment #32) Commenting out the whole block related with XDG_RUNTIME_DIR in .xinitrc made no differense. (The same value, which is different with the one in .xinitrc is set.) I didn't think the files in /usr/local/lib/compat/pkg/ are affecting, as % find -s /usr/local/lib/qt5/plugins/plat* -not -type d -exec ldd -a {} + | fgrep compat showed nothing. But possibly worth considering. The problem here is that determining which files are really safe to delete would not be easy. (Some deleted-in-tree ports are kept locked.)
(In reply to Tomoaki AOKI from comment #33) Widening the scope as % find -s /usr/local/lib/qt5/plugins/ -not -type d -exec ldd -a {} + | fgrep compat showed up libDiscoverCommon.so => /usr/local/lib/compat/pkg/libDiscoverCommon.so (0x21c0643c9000) /usr/local/lib/compat/pkg/libDiscoverCommon.so: libboost_python39.so.1.80.0 => /usr/local/lib/compat/pkg/libboost_python39.so.1.80.0 (0x3be66a11f000) /usr/local/lib/compat/pkg/libboost_python39.so.1.80.0: Looking into whole output from ldd, these indicates that pulling in above are /usr/local/lib/qt5/plugins/discover/kns-backend.so and /usr/local/lib/qt5/plugins/kf5/parts/kigpart.so respectively. According to pkg which, these 2 libraries are installed by sysutils/plasma5-discover and math/kig respectively. Now I'm still on process rebuilding *-qt5* ports. I'll try rebuilding the 2 ports once current ones finishes and without luck.
(In reply to Tomoaki AOKI from comment #34) Rebuilding sysutils/plasma5-discover math/kig, libboost_python39.so.1.80.0 no longer loaded from /usr/local/lib/compat/pkg/. But libDiscoverCommon.so is still loaded from there. Renaming /usr/local/lib/compat/pkg/libDiscoverCommon.so made the lib "libDiscoverCommon.so => not found (0)", although plist entry on FreshPorts [1] lists the file as lib/plasma-discover/libDiscoverCommon.so and the file actually exists. Rebuilding sysutils/plasma5-discover again resulted in the same situation. Now rebuilding sysutils/plasma5-discover with its direct dependencies.
(In reply to Tomoaki AOKI from comment #35) Oops! [1] https://www.freshports.org/sysutils/plasma5-discover/
(In reply to Tomoaki AOKI from comment #35) Finished without luck. I've happen to suspect that any of build tools sets erroneous parameters, and rebuilt *make* devel/samurai devel/ninja devel/meson devel/autoconf* devel/libtool and then qt5-qmake, then qt5-gui, then qt5-*, then finally *-qt5*, and rebooted. Without luck, but now % find -s /usr/local/lib/qt5/ -not -type d -exec ldd -a {} + 2>/dev/null | fgrep compat shows nothing. *Intentionally not rebuilt sysutils/plasma5-discover again, as it could cause /usr/local/lib/compat/pkg/libDiscoverCommon.so to be recreated.
This may not be a very relevant matter, but the following command in my problem-free environment returns the following results. Looking in /usr/local/bin seems to be the next best thing when /usr/local/lib/qt5/* is not found. To begin with, I think the resulting binary doesn't have /usr/local/lib/qt5, which is why it is behaving that way. Command: strings /usr/local/bin/qmake-qt5 | less "+/file to open is a directory" Result: file to open is a directory Platforms share/doc/qt5 include/qt5 lib/qt5 libexec/qt5 lib/qt5/bin lib/qt5/plugins lib/qt5/imports lib/qt5/qml lib/qt5 share/qt5 share/qt5/translations share/examples/qt5 share/qt5/tests false lib/qt5/bin lib/qt5 lib/qt5 freebsd-clang freebsd-clang Prefix Documentation Headers
(In reply to Tatsuki Makino from comment #38) Looks matches as yours, except for additional lines before garbages. file to open is a directory Platforms share/doc/qt5 include/qt5 lib/qt5 libexec/qt5 lib/qt5/bin lib/qt5/plugins lib/qt5/imports lib/qt5/qml lib/qt5 share/qt5 share/qt5/translations share/examples/qt5 share/qt5/tests false lib/qt5/bin lib/qt5 lib/qt5 freebsd-clang freebsd-clang Prefix Documentation Headers include Libraries LibraryExecutables libexec Binaries Plugins plugins Imports imports Qml2Imports ArchData Data Translations translations Examples examples Tests tests Sysroot SysrootifyPrefix HostBinaries HostLibraries HostData TargetSpec HostSpec HostPrefix
(In reply to Tomoaki AOKI from comment #39) The strings seems fine. What does the following command output? pkg-config --variable=exec_prefix Qt5Core pkg-config --variable=host_bins Qt5Core In my environment, it is as follows > pkg-config --variable=exec_prefix Qt5Core /usr/local > pkg-config --variable=host_bins Qt5Core /usr/local/lib/qt5/bin
(In reply to Tatsuki Makino from comment #40) The outputs are just as yours. % pkg-config --variable=exec_prefix Qt5Core /usr/local % pkg-config --variable=host_bins Qt5Core /usr/local/lib/qt5/bin
(In reply to Tomoaki AOKI from comment #41) I'm very confused but the problem disappeared by updating base (stable/13,amd64) from: commit 16dd69d46577bea5807d49340d894a68f8ea7d3a to : commit c84ec3076e7de10d7475fd9694ad64603e264d88. To confirm, several reboots and retry would be needed. What cofuses me is that affected 3 apps worked fine on previous base before updating ports (main) from: commit 885e50f344100a4ee6c5829ef87effef378d4f70 to : commit 2d00178fd4d952c698d3413800c3bd1b6cfc98a9 which is after commit 1fe9749d833c521b518e1190086ef02c7f3e31da. In the meantime, updated Qt5 port installed was libreoffice (excluding what was updated by commit 1fe9749d833c521b518e1190086ef02c7f3e31da itself). What I did until previous post was as follows. 1. Rebuilt again qt5-qmake. 2. Rebuilt again qt5-gui. 3. Rebuilt kf5-* 4. Rebuilt again qt5-* except too heavy qt5-webkit. 5. Rebuilt again *-qt5*. 6. Rebuilt again vlc. 7. Rebooted and tried vlc without luck. 8. Updated base (weekly update). This includes 2 reboots before and after installworld. 9. Tried vlc, which succeeded. 10. Uninstalled gtk2-flavored audacious[-plugins] 11. Reinstalled qt5-flavored audacious[-plugins] 12. Tried audacious, whiche succeeded. I'm now rebuilding editors/libreoffice, changing option from gtk3 to qt5. Will report back when finished and tested.
(In reply to Tomoaki AOKI from comment #42) Rebuilt libreoffice starts up and runs fine. Updating ports tree to main commit 4b02b30706b21f3986cc67f44888c267809266dc, rebuilt updated ports and rebooted, vlc, audacious and libreoffice still start up and run fine. I'll see a few more updates (both base and ports) and close this as "Overcome By Events" if this problem does not reappear. Thanks for everyone here for yor assistance! Note: Just a possibility, base stable/13 at commit 16dd69d46577bea5807d49340d894a68f8ea7d3a was on a state that Qt5.15.8 dislikes but Qt5.15.7 was permissive. Or world built on pre-commit 16dd69d46577bea5807d49340d894a68f8ea7d3a kernel was problematic that Qt5.15.8 dislikes but Qt5.15.7 was permissive. My pre-commit 16dd69d46577bea5807d49340d894a68f8ea7d3a was at commit 0d5776f4adb894b16390bad5b2a33034225f75e3. If anyone noticed the cause of this problem, recording it here or new PR woudld be nice for the future.
The good news is that we have lost an environment that can reproduce this :) Another point of concern is the order of rebuilds. It is possible that qt5-qmake, qt5-buildtools and something else did not build first. There are ports that install shared libraries in /usr/local/lib or in the paths contained in /usr/local/libdata/ldconfig/{qscintilla2-qt5,qt5-core} but don't have USE_LDCONFIG=yes to run service ldconfig restart. However, if ldconfig is related, why a reboot did not improve the problem is not clear.
(In reply to Tatsuki Makino from comment #44) Exactly. :-) Hope this can be never reproducible forever. Possibly, we may need *hints for build order, something alike rc.d scripts with rcorder. *Make USE_LDCONFIG=yes default and only disabled in conjunction with EXTRACT_ONLY or NO_BUILD, or forcibly run ldconfig if plist (regardless auto-plist or pkg-plist) contains *.so.* files. *hardcode /usr/local/lib/compat/pkg in /etc/rc.d/ldconfig like /lib and /usr/lib, but always handled as the last component. in ports framework and base.
(In reply to Tomoaki AOKI from comment #45) > *hardcode /usr/local/lib/compat/pkg in /etc/rc.d/ldconfig like /lib and /usr/lib, Nope. Compat libs (lib/compat/pkg) collection is only temporary support trashbin while live upgrade process goes and should not be present on a clean work environment. If you hit state while some apps after finished upgrade still call something in compat/pkg -- you have a borked semiupgraded setup
I have a bad news, guys. portupgrade/portmaster are dead nowadays due to use a polluted local hier and bad resolving of deps order if something old present in pkg compat dir. Best way to prevent a such situation -- use local pkg repo build with poudriere or synth. It always will be built in a clean environment with proper order of dependencies.
(In reply to Dima Panov from comment #46) In ideal world, exactly. But in real world, no. There are cases that *Any port is updated, *Most of ports relying on it are updated to adapt it, but some are not yet, *Upgrade at the moment. This cause the situation that you said "borked". ${LOCALBASE}/lib/compat/pkg is mostly mandatory in this situation, until all remaining and installed ports are updated. pkg also should support this situation. But the kept old libraries should be used only when it's actually needed, so the entry on ldconfig shall be always at the last one.
(In reply to Dima Panov from comment #47) Ah, I've forgot to mention. The first attempt to update Qt5 to 5.15.8 was by building them with poudriere, install them by copying built packages to /usr/ports/packages/All/ and actually updating with `pkg_replace -a -PP`, which forces to use pre-built packages. As problem happenes AFTER that, reopened and reported at comment 9. After that, I've let pkg_replace to handle both forced-rebuild and reinstall.
(In reply to Tomoaki AOKI from comment #49) Why, why, WHY you have to copy repo use and use third-party tool instead of native pkg ability while you already have a valid repo in poudriere? # cat > /usr/local/etc/pkg/repos/local.conf <<EOF local: { url: "file:///usr/local/poudriere/data/packages/${ABI}" } EOF # cat > /usr/local/etc/pkg/repos/FreeBSD.conf <<EOF FreeBSD: { enabled: NO } EOF
(In reply to Dima Panov from comment #50) There ares some reasons, inteltional and non-intentional. The intentional reasons are *I don't want old packages deleted to easily switch back to old version. This is useful when updated port is consisted with a few packages and updated version doesn't work as expected. Poudriere deletes old package first not to pull them in as dependencies. *I don't know enogh for pkg repo hierarchy and its local cache, especially metadata. The non-intentional reason is that I didn't notice the configuration you first noted is in the handbook at the moment. I could find the example using local web server on poudriere website. And the second configuration is not my option, as for some cases I want to use official pkg, especially ones pulling in some monster like electron* that only one port to try requires. When I wanted to try vscode, it requires electron to build, but not to run. (If multiple apps require the same version of electron, I would not hesitate to build it on poudriere jail. Electron doesn't build with `make` or `pkg_replace` if default node is installed.) `pkg_replace -PP` handles this situation well, first looks for /usr/ports/packages/All/ as local cache, and if none, try official repo.
(In reply to Tomoaki AOKI from comment #51) And as fact you have already shoot your leg by mixing packages and local builds. It is an extreme awful state of co-exist binaries and libraries of different ABI namespaces but with expected names which leads to such situations as you're already hit.
(In reply to Dima Panov from comment #52) stable and releng should keep API/ABI stability. And more, I'm using the same base both on live system and poudriere. I've created poudriere jail as below. And when I upgrade base, update poudriere jail, too. So they should match at least base OS side. And more, currently, official pkg I've installed is editors/vscode only. # poudriere jail -c -v stable/13 -a amd64 -j 13amd64 -m src=/usr/src # poudriere ports -c -f none -M /usr/ports -m null # ln -s /var/db/ports /usr/local/etc/poudriere.d/options And every update on base, # poudriere jail -u -v stable/13 -a amd64 -j 13amd64 -m src=/usr/src This causes massive rebuilds on poudriere when __FreeBSD_version is bumped, which is overkill except for src/main environment. As described above, I'm using the same base, same ports tree, and same options, if I read poudriere documents correctly. The differense is that it's clean-room build or not. This discussion would be better closed here (stop or move to better place elsewhere), as this is not Qt5-specific.
(In reply to Dima Panov from comment #47) At least portmaster does not cause problems with the build order, including BUILD_DEPENDS. Only very rare patterns of ports, such as japanese/xpdf, are the only ones that fail to build. The feature to save libraries to lib/compat/pkg of portmaster is limited to the pattern /\.so\.[0-9]+$/ file name, and files with the same name as lib/*.so.* will be deleted. Therefore, the presence of lib/compat/pkg/libfoo.so.1 will not affect lib_depends as follows. LIB_DEPENDS= libfoo.so:category/foo libfoo.so.2:category/foo If poudriere uses -n when bulk and makes sure that the required packages are not built, there will be no funny dependency problems. By the way, what is the path related to qt5 embedded in the binaries related to qt5? The root of the installation is ${LOCALBASE}, the library is lib/qt5/ and the plug-ins are plugins/ . I am assuming qt5-qmake is doing this... :)
Created attachment 239696 [details] Binaries containing lib/qt5 under /usr/local/bin/ Not sure this is what is wanted, but uploading outputs of below. /usr/local/bin/ part. % grep --exclude-dir compat -r -n "lib/qt5" /usr/local/bin | cut -f 3 -w | rg "/usr/local/bin" | xargs strings -f | grep "[a-zA-Z0-9/.]*: [a-zA-Z0-9/.:]*lib/qt5[a-zA-Z0-9/.:]*" > /var/tmp/embedded-qt5-usr_local_bin.lst2
Created attachment 239697 [details] Binaries containing lib/qt5 under /usr/local/lib/ Not sure this is what is wanted, but uploading outputs of below. /usr/local/lib/ part. % grep --exclude-dir compat -r -n "lib/qt5" /usr/local/lib | cut -f 3 -w | rg "/usr/local/lib" | xargs strings -f | grep "[a-zA-Z0-9/.]*: [a-zA-Z0-9/.:]*lib/qt5[a-zA-Z0-9/.:]*" > /var/tmp/embedded-qt5-usr_local_lib.lst3
(In reply to Tomoaki AOKI from comment #56) That method would include those embedded by -rpath. It seems that this is the code that will be the reason why the application binary will eventually look for the plugin library in /usr/local/bin. https://github.com/qt/qtbase/blob/75ae8869fb171493e4d5163910ef3a2034902c7d/src/corelib/kernel/qcoreapplication.cpp#L2869 It seems that this is the path check for the library. https://github.com/qt/qtbase/blob/75ae8869fb171493e4d5163910ef3a2034902c7d/src/corelib/plugin/qfactoryloader.cpp#L139 It seems that this is the cause of a piece of the path string being embedded. https://github.com/qt/qtbase/blob/75ae8869fb171493e4d5163910ef3a2034902c7d/src/corelib/global/qlibraryinfo.cpp#L449 The reason for the fall down to /usr/local/bin/ is being sought when /usr/local/bin/vlc is launched. Was /usr/local/lib/qt5/plugins/ included in the search path or not? Where is it embedded and used?
(In reply to Tatsuki Makino from comment #57) Well, /var/run/ld-elf.so.hints contains below. % strings /var/run/ld-elf.so.hints Ehnt /lib:/usr/lib:/usr/lib/compat:/usr/local/lib:/usr/local/lib/compat/pkg:/usr/local/lib/alsa-lib:/usr/local/lib/carla:/usr/local/lib/chaiscript:/usr/local/lib/e2fsprogs:/usr/local/lib/gcc10:/usr/local/lib/gcc12:/usr/local/lib/graphviz:/usr/local/lib/libgig:/usr/local/lib/linuxsampler:/usr/local/lib/mysql:/usr/local/lib/mysql/plugin:/usr/local/lib/opencollada:/usr/local/lib/perl5/5.32/mach/CORE:/usr/local/lib/qt5:/usr/local/lib/samba4:/usr/local/lib/signon:/usr/local/lib/signon/extensions:/usr/local/llvm13/lib:/usr/local/llvm15/lib:/usr/local/share/chromium:/usr/local/share/code-oss /usr/local/lib/qt5 is included, but /usr/local/lib/qt5/plugins doesn't. This would be generated by /etc/rc.d/ldconfig. % grep -r -n "ldconfig_paths" /etc/ /etc/defaults/rc.conf:671:ldconfig_paths="/usr/lib/compat ${_localbase}/lib ${_localbase}/lib/compat/pkg" /etc/rc.d/ldconfig:31: ldconfig_paths="${ldconfig_paths} `cat ${_files} | sort -u`" /etc/rc.d/ldconfig:35: for i in ${ldconfig_paths} /etc/ld-elf.so.conf; do /etc/ld-elf.so.conf does not exist. % grep -r -n "ldconfig_paths" /usr/local/etc/ showed nothing. Error outputs (permission) are omitted. PATH environment variable doesn't contain any library paths.
(In reply to Tomoaki AOKI from comment #58) The values are scraped from /usr/local/libdata/ldconfig/* files. I don't know when and how they are used :) In this case, the problem is during the dynamic loading of the plugin, so it is likely that the correct path is not in the results in the following. https://github.com/qt/qtbase/blob/4ee4fc18b4067b90efa46ca9baba74f53b54d9ec/src/corelib/plugin/qfactoryloader.cpp#L191 So I'm curious about the behavior of this part. https://github.com/qt/qtbase/blob/4ee4fc18b4067b90efa46ca9baba74f53b54d9ec/src/corelib/kernel/qcoreapplication.cpp#L2705 This is where realpath comes in. https://github.com/qt/qtbase/blob/4ee4fc18b4067b90efa46ca9baba74f53b54d9ec/src/corelib/io/qfilesystemengine_unix.cpp#L709 What were the conditions under which a non-privileged user could run this and it would fail?
I also faced this issue. For the time being, the same bug occurred in mixxx.
Just a FYI. This problem resurrected by updating from commit 59beb5740e59a6ae50fa6c0fc9c1079d744b9089 to commit 100f2890786bdfa8df021654b530b0f749be46da within which contains commit f1f1a8be887ee2c5d75bec33cb8f8a89454e606b that updates devel/icu to 73.1 and massive bumps, including devel/qt5-core and www/qt5-webkit. Strangely, this happened for updates using poudriere-built pkgs on stable/13, amd64 but on main, amd64, which is updated using pkg_replace for both build and install has no problem. As before, finally, updating base helped on stable/13. Other possible workarounds described in previous comments didn't help just as before. Possibly, some wrong infos are cleared and reconstructed on installworld? As a record, this time, I've updated main environment by pkg_replace -R devel/icu pkg_replace -f devel/qt5-qmake devel/qt5-buildtools devel/autotoos\* devel/libtool pkg_replace -a shutdown -r I was planning, if the problem happenes, to forcibly updating qt5-*, x11/libxkbcommon and *xcb*, but fortunately, these were not needed.
(In reply to Tatsuki Makino from comment #59) Sorry for looooong delay, but I've been stuck how I can confirm this myself.
I think it's a matter of checks like this one. -> bug 270389 It would mean that we would have to update from the qt port/package, which is not affected by such a comparison. And, there seems to be a tool to update FreeBSD packages by Qt, but I am wondering what happened to those who were unable to use that tool due to a QT version mismatch and went silent :) (bug 269929)
There is an update to the current port tree that may cause this problem again :) In poudriere, the build was performed in the following order qt5-qmake-5.15.10p156 qt5-buildtools-5.15.10p156 qt5-core-5.15.10p156 qt5-* (dbus, network, etc...) qmake, buildtools and core were not built in parallel. If problems occur, it may be necessary to investigate whether the above sequence was followed.
(In reply to Tatsuki Makino from comment #64) Ah, thanks to the HEADS UP. Fortunately, this time, I've not be bitten with this on stable/14, built using poudriere-devel. main, which I don't currently using (and not at all planning to using) poudiriere[-devel], is not yet updated to the commit after and including qt5 upgrade. Maybe I'll try poudriere[-devel] on main if it starts ignoring last 3 digits of __FreeBSD_version (OSVERSION in ports framework) and leave it handled by each ports.
Forgot to post the result on main (not using poudriere, but pkg_replace on bare metal environment). The issue happened again here. Forcibly rebuilt Qt components as Tatsuki described on comment #64 before everything others. Next, forcibly rebuilt known-to-be problematic and reproduced audacious[-plugins], without luck. So as vlc. Ommitted libreoffice here, as it't too large to test. Rebuilt/reinstalled base. Without luck. Forcibly rebuilt libxkbcommon, then, forcibly rebuilt Qt5 components again, without luck. What helped this time (not always helps, though) was to move *[Qq]t* under /usr/local/lib/compat/pkg to other directory outside any of libpath. audacious[-plign], vlc and libreoffice worked fine. Note that libreoffice is not at all rebuilt (delayed updating).
About the following https://cgit.freebsd.org/ports/tree/Mk/Uses/qt-dist.mk#n255 PATCHDIR and FILESDIR are set from MASTERDIR, which is set from .CURDIR:tA. If PORTSDIR is set and it differs from the .CURDIR prefix, these patches may not apply. If so, does make patch stop? Is this relevant?
(In reply to Tatsuki Makino from comment #67) In my case, both poudriere build on stable/14 and bare-metal build with pkg_replace on main successfully applied patches. No build failures on patch phase. If I understand correctly, assuming ports tree are extracted into non-default /ports/build/, For Qt component FOO/qt5-BAR, ${PORTSDIR} is manually set as /ports/build (otherwise, basically, /usr/ports is used) ${.CURDIR} is expanded as /ports/build/FOO/qt5-BAR ${.CURDIR} is the directory where the running make is invoked from unless otherwise overridden by -C option. Not the directory where the most-recently read (included) Makefile (or *.mk) are read from. So I think it should properly work. Am I mis-understanding?
(In reply to Tomoaki AOKI from comment #68) > ${PORTSDIR} is manually set as /ports/build (otherwise, basically, /usr/ports is used) > ${.CURDIR} is expanded as /ports/build/FOO/qt5-BAR This means that if the value set in PORTSDIR is the same as the value at the beginning of .CURDIR, there is no problem. It was a check to see if the patch file shown in "make -C /usr/ports/devel/qt5-qmake/ -V EXTRA_PATCHES" result could be reached. ... I have had a number of people here confirm what I have come up with regarding possible matters. So I tried to reproduce the procedure for updating from the old version to the new version :) The procedure is roughly as follows (but that may be wrong :) ) git revert --no-commit 2a5c778173f13a057551b4284269b82f6faa077f poudriere bulk -j ... multimedia/vlc multimedia/audacious-plugin ports-mgmt/pkg_replace poudriere jail -s -j ... jexec jailname-porttree-n env -i "TERM=$TERM" /usr/bin/login -f -p root make -C /usr/ports/multimedia/vlc pkg-depends install-package make -C /usr/ports/multimedia/audacious-plugin install-package make -C /usr/ports/ports-mgmt/pkg_replace install-package exit git restore --source=HEAD --worktree --staged :/ jexec jailname-porttree-n env -i "TERM=$TERM" /usr/bin/login -f -p root pkg_replace -B -a This completed audacious, which did not start well :) Errors like this. ERROR ../src/libaudcore/plugin-load.cc:70 [plugin_load]: /usr/local/lib/audaciou s/General/albumart-qt.so could not be loaded: /usr/local/lib/libaudqt.so.2: Undefined symbol "_ZN11QToolButton13checkStateSetEv@Qt_5" This operation led to one clear difference between the package created by poudriere and the update by pkg_replace. The following unified diff. --- /usr/local/lib/qt5/mkspecs/qmodule.pri 2023-09-25 23:38:37.000000000 +0000 +++ /usr/local/poudriere/data/.m/src-null-1/ref/usr/local/lib/qt5/mkspecs/qmodule.pri 2023-10-07 09:56:52.000000000 +0000 @@ -1,11 +1,13 @@ QT_CPU_FEATURES.x86_64 = mmx sse sse2 -QT.global_private.enabled_features = sse2 alloca_malloc_h alloca avx2 dlopen network posix_fallocate reduce_exports reduce_relocations relocatable sql system-zlib testlib xml -QT.global_private.disabled_features = alloca_h android-style-assets private_tests dbus dbus-linked gc_binaries gui intelcet libudev release_tools stack-protector-strong widgets zstd +QT.global_private.enabled_features = sse2 alloca_malloc_h alloca avx2 dlopen libudev network posix_fallocate reduce_exports reduce_relocations relocatable sql system-zlib testlib xml zstd +QT.global_private.disabled_features = alloca_h android-style-assets private_tests dbus dbus-linked gc_binaries gui intelcet release_tools stack-protector-strong widgets PKG_CONFIG_EXECUTABLE = pkgconf QMAKE_LIBS_LIBDL = +QMAKE_LIBS_LIBUDEV = -L/usr/local/lib -ludev QT_COORD_TYPE = double QMAKE_LIBS_ZLIB = -lz +QMAKE_LIBS_ZSTD = -L/usr/local/lib -lzstd CONFIG -= precompile_header CONFIG += sse2 aesni sse3 ssse3 sse4_1 sse4_2 avx avx2 avx512f avx512bw avx512cd avx512dq avx512er avx512ifma avx512pf avx512vbmi avx512vl compile_examples f16c largefile rdrnd rdseed shani x86SimdAlways QT_BUILD_PARTS += libs tools -QT_HOST_CFLAGS_DBUS += +QT_HOST_CFLAGS_DBUS += -I/usr/local/include/dbus-1.0 -I/usr/local/lib/dbus-1.0/include It seems that this is a file installed by qt5-qmake, but it looks like there may be ports that should not be installed when it is built.
(In reply to Tatsuki Makino from comment #69) Therefore... Here is how to reproduce this problem Either libudev-devd or zstd, or both, should be installed before building qt5-qmake. Build and install qt5-qmake. Build and install qt5-core using this qt5-qmake. Then, by doing the opposite, this problem is resolved. Remove both libudev-devd and zstd. Rebuild and install qt5-qmake. Rebuild and install qt5-core using this qt5-qmake. In some cases, rebuild and install qt5-widgets as well. This may save you from rebuilding everything in qt5 :)
I wrote like #70, but also remember the around comment #32. #70 does not take into account the behavior when a large amount of garbage is left in /usr/local/lib/compat/pkg. It seems that pkg_replace does not include the behavior that if a library with the same name exists, the one in compat/pkg is removed. portmaster does its work. > Cannot mix incompatible Qt library (5.15.8) with this library (5.15.10) If we get this message, we should check for it first :) Then, Therefore, I will be destroying all the environments I have created to reproduce this problem :)
(In reply to Tatsuki Makino from comment #70) Thanks for digging into. Maybe qmake somehow auto-detect alreay-installed files and automagically set the options (features). And QT_HOST_CFLAGS_DBUS differs, too. Not sure it actually works, but is it possible to explicitly unset those 2 features on devel/qmake or Mk/Uses/qt[-dist].mk? Mk/bsd.options.mk has description (comment) about ${opt}_QMAKE_ON and ${opt}_QMAKE_OFF, and following. _ALL_OPTIONS_HELPERS= ${_OPTIONS_DEPENDS:S/$/_DEPENDS/} \ ${_OPTIONS_DEPENDS:S/$/_DEPENDS_OFF/} \ ${_OPTIONS_FLAGS:S/$/_OFF/} ${_OPTIONS_FLAGS} \ CABAL_FLAGS CMAKE_BOOL CMAKE_BOOL_OFF CMAKE_OFF CMAKE_ON \ CONFIGURE_ENABLE CONFIGURE_OFF CONFIGURE_ON \ CONFIGURE_WITH IMPLIES MESON_ARGS MESON_DISABLED \ MESON_ENABLED MESON_FALSE MESON_OFF MESON_ON MESON_TRUE \ PREVENTS PREVENTS_MSG QMAKE_OFF QMAKE_ON USE USE_OFF \ VARS VARS_OFF But unlike cmake, mk/Uses/qmake.mk doesn't have descriptions about those. FYI: Looing for FreshPorts, libudev-devd and zstd are required by Qt6. zstd is required by qt5-core. So they cannot blindly disabled, but limited to qmake.
(In reply to Tatsuki Makino from comment #71) Of course. :-) But in (hopefully) some rare cases, delete-from-ports softwares are mandatory. For those cases, Old libraries which are mandatory (new one does not work for them) and forced to be kept in /usr/local/lib/compat/pkg. We can lock installed ports, but it is not desirable not to update common libraries for some old locked ports. It would be nice if there is any efficient tool to delete only really safe to delete libraries from /usr/local/lib/compat/pkg. FYI: pkg_replace basically works as oldest port upgrading tool, portupgrade. It keeps old libraries into /usr/local/lib/compat/pkg by default, unlike portmaster. This behaviour helps using applications in half-done state, some of required libraries are updated but others are not yet, for example, build failures. Default of portmaster would be focus on security. But it assumes that... *All ports are ALWAYS BUILT AND RUN SUCCESSFULLY, unless marked as BROKEN. *ALL ports works 100% fine with old and updated ports. that is not at all realistic assumption. portupgrade was much more realistic. Unfortunately, portupgrade[-devel] is not well maintained for years, so pkg_replace popped in and maintained well by current maintainer.
I was a little curious and tried a follow-up test, but could not reproduce comment #69 through #71. Perhaps they are wrong. Sorry. And the workaround for this problem is to add the -u option to pkg_replace. I just finished updating with pkg_replace -B -u -a, and in this case there is no problem starting audacious, probably because /usr/local/lib/compat/pkg is kept empty. The next issue will describe the results of a more precise search for the cause of the problem by reproducing it :)
Created attachment 245540 [details] unified diff of `grep / truss.log | grep -v ^poll` (In reply to Tatsuki Makino from comment #74) The difference between "pkg_replace -B -a" and "pkg_replace -B -u -a". If -u was not used, the following files are backed up in /u*/l*/lib/compat/pkg. Attached is a truss log that varies with and without the following set of files. ^- is when there is a backup of the old library and ^\+ is when there is no backup. Are the next two lines worth noting? -access("/usr/local/lib/lib/qt5/plugins",F_OK) ERR#2 'No such file or directory' +access("/usr/local/lib/qt5/plugins",F_OK) = 0 (0x0) I guess this is a relative path following ../../lib/qt5 from dirname of libQt5*.so*. It seems that the failure of this has not even resulted in the subsequent loading of the plugin. It would then display "qt.qpa.plugin: Could not find the Qt platform plugin ...". In the case of audacious, of the libraries that may contain code for this, the file it is trying to load is /usr/local/lib/compat/pkg/libQt5Core.so.5, so removing it is the quickest solution. In the case of portmaster, it does not fundamentally back up the library unless -w is used. When the library is backed up using -w, the library of the same name is also deleted in the following area. https://github.com/freebsd/portmaster/blob/edb3fe64a9e1bd137045877e0981f49be1bf1a22/portmaster#L3893 ==== From here down, only a list of backed up file names is available. libQt5Core.so libQt5Core.so.5 libQt5Core.so.5.15 libQt5Core.so.5.15.8 libQt5DBus.so libQt5DBus.so.5 libQt5DBus.so.5.15 libQt5DBus.so.5.15.8 libQt5Gui.so libQt5Gui.so.5 libQt5Gui.so.5.15 libQt5Gui.so.5.15.8 libQt5Multimedia.so libQt5Multimedia.so.5 libQt5Multimedia.so.5.15 libQt5Multimedia.so.5.15.8 libQt5MultimediaGstTools.so libQt5MultimediaGstTools.so.5 libQt5MultimediaGstTools.so.5.15 libQt5MultimediaGstTools.so.5.15.8 libQt5MultimediaQuick.so libQt5MultimediaQuick.so.5 libQt5MultimediaQuick.so.5.15 libQt5MultimediaQuick.so.5.15.8 libQt5MultimediaWidgets.so libQt5MultimediaWidgets.so.5 libQt5MultimediaWidgets.so.5.15 libQt5MultimediaWidgets.so.5.15.8 libQt5Network.so libQt5Network.so.5 libQt5Network.so.5.15 libQt5Network.so.5.15.8 libQt5OpenGL.so libQt5OpenGL.so.5 libQt5OpenGL.so.5.15 libQt5OpenGL.so.5.15.8 libQt5Qml.so libQt5Qml.so.5 libQt5Qml.so.5.15 libQt5Qml.so.5.15.8 libQt5QmlModels.so libQt5QmlModels.so.5 libQt5QmlModels.so.5.15 libQt5QmlModels.so.5.15.8 libQt5QmlWorkerScript.so libQt5QmlWorkerScript.so.5 libQt5QmlWorkerScript.so.5.15 libQt5QmlWorkerScript.so.5.15.8 libQt5Quick.so libQt5Quick.so.5 libQt5Quick.so.5.15 libQt5Quick.so.5.15.8 libQt5QuickParticles.so libQt5QuickParticles.so.5 libQt5QuickParticles.so.5.15 libQt5QuickParticles.so.5.15.8 libQt5QuickShapes.so libQt5QuickShapes.so.5 libQt5QuickShapes.so.5.15 libQt5QuickShapes.so.5.15.8 libQt5QuickWidgets.so libQt5QuickWidgets.so.5 libQt5QuickWidgets.so.5.15 libQt5QuickWidgets.so.5.15.8 libQt5Sql.so libQt5Sql.so.5 libQt5Sql.so.5.15 libQt5Sql.so.5.15.8 libQt5Widgets.so libQt5Widgets.so.5 libQt5Widgets.so.5.15 libQt5Widgets.so.5.15.8 libQt5X11Extras.so libQt5X11Extras.so.5 libQt5X11Extras.so.5.15 libQt5X11Extras.so.5.15.8 libQt5XcbQpa.so libQt5XcbQpa.so.5 libQt5XcbQpa.so.5.15 libQt5XcbQpa.so.5.15.8 libcomposeplatforminputcontextplugin.so libdeclarative_audioengine.so libdeclarative_multimedia.so libgstaudiodecoder.so libgstcamerabin.so libgstmediacapture.so libgstmediaplayer.so libibusplatforminputcontextplugin.so liblabsanimationplugin.so liblabsmodelsplugin.so libmodelsplugin.so libparticlesplugin.so libqbsdfb.so libqbsdkeyboardplugin.so libqbsdmouseplugin.so libqevdevkeyboardplugin.so libqevdevmouseplugin.so libqevdevtabletplugin.so libqevdevtouchplugin.so libqgenericbearer.so libqgif.so libqico.so libqjpeg.so libqminimal.so libqmldbg_debugger.so libqmldbg_inspector.so libqmldbg_local.so libqmldbg_messages.so libqmldbg_native.so libqmldbg_nativedebugger.so libqmldbg_preview.so libqmldbg_profiler.so libqmldbg_quickprofiler.so libqmldbg_server.so libqmldbg_tcp.so libqmlfolderlistmodelplugin.so libqmllocalstorageplugin.so libqmlplugin.so libqmlsettingsplugin.so libqmlshapesplugin.so libqmlwavefrontmeshplugin.so libqoffscreen.so libqquicklayoutsplugin.so libqtaudio_alsa.so libqtmultimedia_m3u.so libqtqmlstatemachine.so libqtquick2plugin.so libqtuiotouchplugin.so libqvnc.so libqxcb-egl-integration.so libqxcb-glx-integration.so libqxcb.so libsharedimageplugin.so libwindowplugin.so libworkerscriptplugin.so
There is an update to the current port tree that may cause this problem again again :) The existence of libudev-devd and zstd makes a difference in what qmake installs, but is not relevant to this problem. Thus, there is absolutely no need to delete them when updating. When updating, do not perform operations that break the order as noted in comment #64. This would work well if done automatically. When updating to avoid this problem, use -u option for pkg_replace. To reproduce this problem, update by pkg_replace without -u option. After confirming that the problem reproduces, also confirm that the problem is resolved by deleting the following files. /usr/local/lib/compat/pkg/libQt5Core.so.5 /usr/local/lib/compat/pkg/libQt5*.so.5 The following is unrelated. I sometimes delete files in /usr/local/lib/compat/pkg with the following command. find -L -d -s -x -- /usr/local/lib/compat/pkg/ \( -type d -empty -or -type l -or -not -type d -atime +4w \) -exec rm -i -r -v -- {} \; This is exactly what I am using, but in this case even the directory of ...lib/compat/pkg is deleted, so -mindepth 1 may be necessary :)
(In reply to Tatsuki Makino from comment #76) Thanks for heads-up. This time, fortunately, I've not bitten. For the record, what I've performed this time (after updating ports tree) are: For stable/14 poudriere build (to be paranoid): *Fetch distfiles with `pkg_replace -a -c -m 'WITH+="NVIDIA,NVIDIA_GL" \ DISABLE_VULNERABILITIES=yes' -F -k` *Build qt5-qmake with `poudriere bulk -j jailname -J 6 -S devel/qt5-qmake`. *Build qt5-buildtools with `poudriere bulk -j jailname -J 6 -S \ devel/qt5-buildtools`. *Build qt5-core with `poudriere bulk -j jailname -J 6 -S devel/qt5-core`. *Created list of remaining Qt5 components as /poudriere/pkglist.qt5. *Build remaining Qt5 components with `poudriere bulk -f /poudriere/pkglist.qt5 \ -j 14amd64 -J 6 -S`. *Single port (sorry, forgot to take memo) failed complaining graphics/vulkan-loader is missing (maybe poudriere missed the dependency, although it was deleted before actual builds were started), so built it like others. *Redo remaining Qt5 components builds. *Build all other updated ports as usual. For main pkg_replace build: *Update qt5-qmake with `pkg_replace -c -v -m 'DISABLE_VULNERABILITIES=yes' \ -u -b devel/qt5-qmake`. *Update qt5-buildtools with `pkg_replace -c -v -m 'DISABLE_VULNERABILITIES=yes' \ -u -b devel/qt5-buildtools`. *Update qt5-core with `pkg_replace -c -v -m 'DISABLE_VULNERABILITIES=yes' \ -u -b devel/qt5-core`. *Update remaining Qt5 components with `pkg_replace -c -v \ -m 'DISABLE_VULNERABILITIES=yes' -u -b qt5-\*`. *Update everything else as usual.
(In reply to Tatsuki Makino from comment #76) Comment for this separately. :=) > The following is unrelated. > I sometimes delete files in /usr/local/lib/compat/pkg with the following command. > > find -L -d -s -x -- /usr/local/lib/compat/pkg/ \( -type d -empty -or -type l -or -not -type d -atime +4w \) -exec rm -i -r -v -- {} \; This time, I've moved Qt5-related remnants in /usr/local/lib/compat/pkg manually, so not tested, but what about below limited to Qt* components? find -L -d -s -x -- /usr/local/lib/compat/pkg/ \( -type d -empty -or -type l -or -not -type d -atime +4w \) -iname \*qt\* -exec rm -i -r -v -- {} \; Or if deletion is not wanted and /usr/local/lib/compat/pkg.qt5 is not in library path, find -L -d -s -x -- /usr/local/lib/compat/pkg/ \( -type d -empty -or -type l -or -not -type d -atime +4w \) -iname \*qt\* -exec mv -i -v {} /usr/local/lib/compat/pkg.qt5 \; would work, if I understand man pages correctly.
(In reply to Tomoaki AOKI from comment #77) This time, as the saying "百聞は一見に如かず" says, I gave advice based on my own experience, so I am glad that I did not have any problems. The build order of qt5-qmake, qt5-buildtools, and qt5-core was followed, so there should be no "Cannot mix incompatible Qt library (5.15.x) with this library (5.15.y)" failures. Since the -u option was used for pkg_replace, there will be no failure to 'qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in ""'. However, this time, the old version of backup does not exist. (In reply to Tomoaki AOKI from comment #78) Since this find is for the question of when to delete the backed up library, there is no need to modify it. For example, run the following ls > ls -ATlrtu -- /usr/local/lib/compat/pkg/ total 1088 -rwxr-xr-x 1 root wheel 485264 Sep 21 07:05:17 2023 libsodium.so.26 -rwxr-xr-x 1 root wheel 550288 Oct 12 07:30:11 2023 libimagequant.so.0 In the case of portmaster, the backup will be as shown above. If this is older than the time of startup, > sysctl -n kern.boottime { sec = 1691537044, usec = 941220 } Wed Aug 9 08:24:04 2023 daemons that run at the same time as startup are not affected and can be removed. If the time is updated close to the current time, then the library is still linked to something. Problem binaries are relatively easy to find with pkg check -dna. If the problem is not found by it, it is rather tricky :) This find is a somewhat automated version of deleting backup libraries that have not been accessed for a certain period of time. However, since rm has a -i option, it is manual to some extent :) The -s option in find is to make the order somewhat understandable, and the -x option is to avoid hassle if something like crossing mount points is backed up. Then remove the libraris and etc. under 3 conditions. "find -d ... -type d -empty" immediately deletes empty directories. I think -mindepth 1 is necessary because it also deletes the pkg directory when the contents are completely empty :) "find -L ... -type l" deletes unpointed symlinks. The -L option treats symlinks whose target is not a symlink as non-symlink. "find ... -not -type d -atime +4w" is deleting anything other than directories that haven't been accessed in over 4 weeks. I think the libraries backed up to ${LOCALBASE}/compat/pkg are still to rescue binaries linked to the old library, not to roll back when bugs exist in the new library. So, if pkg_replace is used that does not implement the function to delete a library of the same name from backup, such as portmaster written in comment #75, it should be done manually immediately. Rather than creating a command or tool that can be done in one shot, it is a function that should be implemented on pkg_replace side depending on the backup philosophy.
MARKED AS SPAM