too long lines were shrinked: x86_64-pc-linux-gnu-g++ -c -O2 -pipe -march=native -fno-diagnostics-color -std=c++1z -fvisibility=hidden -fvisibility-inlines-hidden -fno-exceptions -Wall -Wextra -Wvla -Wdate-time -Wshift-overflow=2 -Wduplicated-cond -Wno-stringop-overflow -Wno-format-overflow -D_REENTRANT -fPIC -DQT_NO_LINKED_LIST /usr/lib64/qt5/bin/moc -DQT_NO_LINKED_LIST -DQT_NO_FOREACH -DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_LINKED_LIST -DLINK_LIBUDEV -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_SERIALPORT_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_D x86_64-pc-linux-gnu-g++ -c -O2 -pipe -march=native -fno-diagnostics-color -std=c++1z -fvisibility=hidden -fvisibility-inlines-hidden -fno-exceptions -Wall -Wextra -Wvla -Wdate-time -Wshift-overflow=2 -Wduplicated-cond -Wno-stringop-overflow -Wno-format-overflow -D_REENTRANT -fPIC -DQT_NO_LINKED_LIST rm -f libQt5SerialPort.so.5.15.13 libQt5SerialPort.so libQt5SerialPort.so.5 libQt5SerialPort.so.5.15 x86_64-pc-linux-gnu-g++ -Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,--defsym=__gentoo_check_ldflags__=0 -Wl,--undefined-version -Wl,--no-undefined -Wl,--version-script,QtSerialPort.version -Wl,--enable-new-dtags -shared -Wl,-Bsymbolic-functions -Wl,-soname,libQt5SerialPort.so.5 -o libQt5 /usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld: .obj/qserialportinfo_unix.o: in function `availablePortsByUdev(bool&)': qserialportinfo_unix.cpp:(.text+0xdc7): undefined reference to `udev_new' /usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld: qserialportinfo_unix.cpp:(.text+0xddf): undefined reference to `udev_enumerate_new' /usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld: qserialportinfo_unix.cpp:(.text+0xdfa): undefined reference to `udev_enumerate_add_match_subsystem' ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 23.0_desktop_plasma_test-20240419-193003 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-14 * clang/llvm (if any): clang version 18.1.4 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/18/bin Configuration file: /etc/clang/x86_64-pc-linux-gnu-clang.cfg /usr/lib/llvm/18 18.1.4 Python 3.11.9 Available Rust versions: [1] rust-bin-1.77.1 * The following VMs are available for generation-2: *) Eclipse Temurin JDK 21.0.2_p13 [openjdk-bin-21] Available Java Virtual Machines: [1] openjdk-bin-21 system-vm The Glorious Glasgow Haskell Compilation System, version 9.2.8 php cli (if any): go version go1.22.2 linux/amd64 HEAD of ::gentoo commit d288e00c26c57271f87899298b2aae7947c62e54 Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Wed Apr 24 06:04:25 2024 +0000 2024-04-24 06:04:25 UTC emerge -qpvO dev-qt/qtserialport [ebuild N ] dev-qt/qtserialport-6.7.0 USE="test"
Created attachment 891617 [details] emerge-info.txt
Created attachment 891618 [details] dev-qt:qtserialport-5.15.13:20240424-071348.log
Created attachment 891619 [details] emerge-history.txt
Created attachment 891620 [details] environment
Created attachment 891621 [details] etc.clang.tar.xz
Created attachment 891622 [details] etc.portage.tar.xz
Created attachment 891623 [details] logs.tar.xz
Created attachment 891624 [details] qlist-info.txt
Created attachment 891625 [details] temp.tar.xz
paul: do you mind if I ask if you've hit this after upgrading to gcc 14, or just hit it otherwise?
(In reply to Sam James from comment #10) > paul: do you mind if I ask if you've hit this after upgrading to gcc 14, or > just hit it otherwise? Hi Sam - You can always ask! I have come across this bug on a completely new install on my laptop. After following the handbook installation process, I installed kde plasma. Then I wanted to install freecad, and hit this issue. I have gcc 13 installed, so it isn't related to updating to gcc 14. After hitting this problem on the laptop, I installed freecad including qtserialport on my desktop system without any issues - again using gcc 13. udev versions seem to match on both systems, but the kernel versions differ. The desktop is on 6.8.6, while the new install on the laptop is on 6.6.30. I am planning to get everything working as I like before moving to the unstable kernel. If you want me to check anything - just ask!
I would still like to resolve this issue, as qtserialport:5 is a dependency for media-radio/wsjtx (or at least the currently available version in portage). I now have gentoo-sources-6.14.3 installed, and gcc v14.2.1 enabled. I recompiled systemd-utils, but I still get the same error when compiling qtserialport-5.15.16. Any tips on what to try next? My other laptop has no issue, and is on the same software components level. Thanks!
Let me have a look but no promises (Qt 5 is so moldy...).
OK, so.. src_prepare has: ``` # make sure we link against libudev sed -i -e 's/:qtConfig(libudev)//' \ src/serialport/serialport-lib.pri || die ``` which controls LINK_LIBUDEV, and LINK_LIBUDEV appears at: https://github.com/qt/qtserialport/blob/43e0d68d2784e73eeefc918bafea943d215f8332/src/serialport/CMakeLists.txt#L30
When I try to build it, -ludev appears indeed. Paul, can you give me your build.log?
(In reply to Sam James from comment #14) > which controls LINK_LIBUDEV, and LINK_LIBUDEV appears at: > https://github.com/qt/qtserialport/blob/ > 43e0d68d2784e73eeefc918bafea943d215f8332/src/serialport/CMakeLists.txt#L30 Ignore this part. gh search doesn't respect branch/tags. ``` unix { DEFINES += LINK_LIBUDEV INCLUDEPATH += $$QMAKE_INCDIR_LIBUDEV LIBS_PRIVATE += $$QMAKE_LIBS_LIBUDEV } ``` So, what populates QMAKE_LIBS_LIBUDEV?
On my system, I see: ``` $ rg QMAKE_LIBS_LIBUDEV /usr/ /usr/lib64/qt6/mkspecs/qmodule.pri 13:QMAKE_LIBS_LIBUDEV = -ludev /usr/lib64/qt5/mkspecs/qmodule.pri 27:QMAKE_LIBS_LIBUDEV = -ludev /usr/lib64/qt5/mkspecs/gentoo/qmodule-qtcore.pri 27:QMAKE_LIBS_LIBUDEV = -ludev [...] ``` Maybe it depends on whether udev was installed when dev-qt/qtcore was emerged but that doesn't seem right, as it surely was. I feel like it's not worth spending time on fixing this properly and we should just try jam in -ludev here.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6eb6abd03595e182f69888ed45b2537afbe144eb commit 6eb6abd03595e182f69888ed45b2537afbe144eb Author: Sam James <sam@gentoo.org> AuthorDate: 2025-04-24 08:34:10 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-04-24 08:34:10 +0000 dev-qt/qtserialport: substitute -ludev unconditionally Apparently sometimes QMAKE_LIBS_LIBUDEV isn't populated and it's not worth spending time to figure out why for Qt 5. Bug: https://bugs.gentoo.org/673532 Closes: https://bugs.gentoo.org/930543 Signed-off-by: Sam James <sam@gentoo.org> dev-qt/qtserialport/qtserialport-5.15.16.ebuild | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Many thanks Sam - that indeed resolves the problem for me (as expected :)). I will look to make a new ebuild for the latest version of wsjtx (or rather wsjt-x-improved - it's a long story!). That should remove the qt5 requirement in this particular case.
Excellent, thanks! FWIW, I'd get your skates on. We're really trying to prune Qt 5 as much as possible.
