You are not logged in.
@abaumann - i'm going to attempt an i686 rebuild of libc++ and see if that resolves that second issue. it's getting pretty annoying every time i try to build anything.
Edit: rebuilding didn't help. same errors:
-- Build files have been written to: /distro/repository/calamares-plasma-bluestar/src/calamares-3.2.61/build
Consolidate compiler generated dependencies of target txload
[ 0%] Linking CXX executable txload
/usr/bin/ld: /usr/lib/libQt5Xml.so.5.15.8: undefined reference to `std::__throw_bad_array_new_length()@GLIBCXX_3.4.29'
/usr/bin/ld: /usr/lib/libQt5Core.so.5.15.8: undefined reference to `std::__exception_ptr::exception_ptr::_M_release()@CXXABI_1.3.13'
/usr/bin/ld: /usr/lib/libicuuc.so.72: undefined reference to `std::condition_variable::wait(std::unique_lock<std::mutex>&)@GLIBCXX_3.4.30'
/usr/bin/ld: /usr/lib/libQt5Core.so.5.15.8: undefined reference to `std::__exception_ptr::exception_ptr::_M_addref()@CXXABI_1.3.13'
/usr/bin/ld: /usr/lib/libQt5Xml.so.5.15.8: undefined reference to `std::__glibcxx_assert_fail(char const*, int, char const*, char const*)@GLIBCXX_3.4.30'
collect2: error: ld returned 1 exit statuslooking at these linker errors, obviously it's looking for version-specific functions within libc++ and glibc.
I had been seeing the following message recently:
ldconfig: /usr/lib/libbfd.so is not an ELF file - it has the wrong magic bytes at the startso I checked out /usr/lib/libbfd.so and it turns out it's a text file, containing the following:
[root@bslxhp32 lib]# cat libbfd.so
INPUT( /usr/lib/libbfd.a -lsframe -liberty -lz -lzstd -ldl )I double-checked this file against the 64-bit version, and archlinux's libbfd.so is exactly the same, so the package build is right (which I confirmed with my own rebuild), but I don't see the linker warning on my 64-bit archlinux system (I'm assuming it's a warning since so far it hasn;t seemed to crash anything). Any thoughts as to why the difference between the 2 systems, and is there any way to silence the warnings (the 2 questions may have the same answer)?
@abaumann - i'll let you know once it appears in my updates.
@abaumann - i'm actually seeing these kinds of link errors everywhere right now. seems every other thing i try to build throws the same *kind* of errors. here are the ones thrown while building mixxx:
/usr/bin/ld: /usr/lib/libicuuc.so.72: undefined reference to `std::condition_variable::wait(std::unique_lock<std::mutex>&)@GLIBCXX_3.4.30'
/usr/bin/ld: /usr/lib/libprotobuf-lite.so: undefined reference to `std::__glibcxx_assert_fail(char const*, int, char const*, char const*)@GLIBCXX_3.4.30'
/usr/bin/ld: /usr/lib/libQt5Core.so.5.15.8: undefined reference to `std::__exception_ptr::exception_ptr::_M_release()@CXXABI_1.3.13'
/usr/bin/ld: /usr/lib/libchromaprint.so: undefined reference to `std::__throw_bad_array_new_length()@GLIBCXX_3.4.29'
/usr/bin/ld: /usr/lib/libQt5Core.so.5.15.8: undefined reference to `std::__exception_ptr::exception_ptr::_M_addref()@CXXABI_1.3.13'been trying for some time now to do a calamares build and am getting the libicuuc.so error (as above). rebuilding icu makes no difference.
is there something y'all are building against that hasn;t been released yet?
Many kde time management apps, like korganizer, knotes, kaddressbook, etc, require kdepim-runtime as a dependency, but kdepim-runtime stilll has a dependency on kalarmcal, which no longer exists. This info dump is actually on the version in staging which I installed assuming the dependency was resolved (this issue exists in the current official version). It wasn't. Note the existence of kalarmcal in the list of dependencies.
pacman -Qi kdepim-runtime
Name : kdepim-runtime
Version : 21.12.3-1.0
Description : Extends the functionality of kdepim
Architecture : i686
URL : https://kontact.kde.org
Licenses : GPL LGPL FDL
Groups : None
Provides : None
Depends On : libkolabxml kdav akonadi-calendar knotifyconfig kalarmcal kmbox pimcommon akonadi-notes akonadi qca-qt5 qt5-networkauth
Optional Deps : libetebase: EteSync resource [installed]
Required By : kaddressbook knotes korganizer
Optional For : None
Conflicts With : None
Replaces : None
Installed Size : 13.57 MiB
Packager : Andreas Baumann <mail@andreasbaumann.cc>
Build Date : Thu 03 Mar 2022 11:41:28 PM EST
Install Date : Wed 04 Jan 2023 09:05:17 PM EST
Install Reason : Installed as a dependency for another package
Install Script : No
Validated By : SHA-256 SumI'd go ahead and rebuild it, but I'm getting a build error:
-- Found Gettext: /usr/bin/msgmerge (found version "0.21.1")
CMake Error at CMakeLists.txt:139 (find_package):
Could not find a configuration file for package "KF5Akonadi" that is
compatible with requested version "5.22.1".
The following configuration files were considered but not accepted:
/usr/lib/cmake/KF5Akonadi/KF5AkonadiConfig.cmake, version: 5.21.2
/lib/cmake/KF5Akonadi/KF5AkonadiConfig.cmake, version: 5.21.2
-- Configuring incomplete, errors occurred!
See also "/home/bslx/repository/kdepim-runtime/tmp/src/build/CMakeFiles/CMakeOutput.log".
See also "/home/bslx/repository/kdepim-runtime/tmp/src/build/CMakeFiles/CMakeError.log".
==> ERROR: A failure occurred in build().
Aborting...so... akonadi?
Two "invalid symlink" errors came up during a mkinitcpio - for libnss_files.so.2 and libnss_dns.so.2. I don't have a copy of it because I fixed it and the error message scrolled well off my screen, but to fix it, I had to do the following:
mv /usr/lib/libnss_dns.so.2 /usr/lib/libnss_dns.so
ln -sf /usr/lib/libnss_dns.so /usr/lib/libnss_dns.so.2
mv /usr/lib/libnss_files.so.2 /usr/lib/libnss_files.so
ln -sf /usr/lib/libnss_files.so /usr/lib/libnss_files.so.2The glibc package includes libnss_files.so.2, but not libnss_files.so. Same with libnss_dns. To fix it, you have to move the .so.2 file to a .so, then create a symlink to the .so, with filename ending in .so.2 (ln -sf libnss_files.so libnss_files.so.2).
There are other issues with glibc - like this interesting build error:
-- Configuring done
-- Generating done
-- Build files have been written to: /distro/repository/calamares-plasma-bluestar/src/calamares-3.2.61/build
[ 0%] Building CXX object lang/CMakeFiles/txload.dir/txload.cpp.o
[ 0%] Linking CXX executable txload
/usr/bin/ld: /usr/lib/libQt5Xml.so.5.15.7: undefined reference to `std::__throw_bad_array_new_length()@GLIBCXX_3.4.29'
/usr/bin/ld: /usr/lib/libQt5Core.so.5.15.7: undefined reference to `std::__exception_ptr::exception_ptr::_M_release()@CXXABI_1.3.13'
/usr/bin/ld: /usr/lib/libicuuc.so.72: undefined reference to `std::condition_variable::wait(std::unique_lock<std::mutex>&)@GLIBCXX_3.4.30'
/usr/bin/ld: /usr/lib/libQt5Core.so.5.15.7: undefined reference to `std::__exception_ptr::exception_ptr::_M_addref()@CXXABI_1.3.13'
/usr/bin/ld: /usr/lib/libQt5Xml.so.5.15.7: undefined reference to `std::__glibcxx_assert_fail(char const*, int, char const*, char const*)@GLIBCXX_3.4.30'
collect2: error: ld returned 1 exit status
make[2]: *** [lang/CMakeFiles/txload.dir/build.make:99: lang/txload] Error 1
make[1]: *** [CMakeFiles/Makefile2:2031: lang/CMakeFiles/txload.dir/all] Error 2
make: *** [Makefile:166: all] Error 2
==> ERROR: A failure occurred in build().
Aborting...Note the undefined references which, I know, are happening because qt5 and everything that depends on glibc needs to be rebuilt.
Edit: here's the error output from mkinitcpio:
==> Starting build: 6.1.2-arch1-1.0
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [memdisk]
-> Running build hook: [archiso]
-> Running build hook: [archiso_loop_mnt]
-> Running build hook: [archiso_pxe_common]
==> ERROR: invalid symlink: /usr/lib/libnss_files.so.2
==> ERROR: invalid symlink: /usr/lib/libnss_dns.so.2
-> Running build hook: [archiso_pxe_nbd]
-> Running build hook: [archiso_pxe_http]
-> Running build hook: [archiso_pxe_nfs]
-> Running build hook: [archiso_kms]
-> Running build hook: [bslx_kms]
-> Running build hook: [block]
-> Running build hook: [pcmcia]
-> Running build hook: [filesystems]
-> Running build hook: [keyboard]
-> Running build hook: [bslx_live_desktop]
==> Generating module dependencies
==> Creating xz-compressed initcpio image: /boot/archiso.imgThere is a known bug with dkms-3.0.5-1 where unsigned modules are concerned (most dkms modules are unsigned). There is also a valid bug fix for this attached to the upstream archlinux.org dkms package entry. I've applied the patch, personally, and it is the only one out there that actually fixes this issue. You can find it here:
https://bugs.archlinux.org/task/75212
The patch is attached near the bottom of the ticket. Reading the ticket entries will give you some understanding of the confusion over the issue.
@abaumann - i went ahead and closed this post since your linux-5.18.3 release seems to have resolved the problem. i *would* like to know what fixed it, though. was it baking the rule into the buildmaster, so that toolchain/linux updates happen in sync? or did you find a single point of mis-versioned something somewhere?
@abaumann - so. what'd you do to fix it, bud? linux-5.18.3 installed perfectly along with its dkms modules, so something got realigned somewhere. i had had to rebuild 5.18.1, so something happened between versions 5.18.1 and 5.18.3...
@abaumann - definitely worth a try, bud.
i was setting up a build and noticed too that the r8168 and r8101 dkms packages wouldn;t build under my rebuilt 5.18.1 kernel. although an updated version of r8168 was available (and which *does* build - i used it as a template to modify r8101 which also builds now), i found it really strange that neither of those modules needed *any* updating under arch64... as if the core 5.18.x kernel api was different between the 2 platforms, which should never happen under normal circumstances. is it possible that one or more config flags either are being set when they shouldn;t be, or aren;t being set when they should be? i can look into this if you want. i have older 32-bit live system images i can boot up and grab a /proc/config.gz and compare it, but i can't say for sure i can recognize a possible discrepancy unless it's obvious.
i'm beginning to think i should just do a pacman dump on all my installed packages and let you do a version comparison against your build system. we're out of sync somewhere...
@abaumann - same issue with 5.18.1. about to rebuild.
@abaumann - just to stay with the thread, i got the same result, again. have already rebuilt and the rebuild works fine. if there's any information we can provide to help figure out where the disconnect is happening, just let us know.
plugin_default_version_check comes with gcc, which i think you've already figured out.
hm. well, wth. what are we missing? the only deviations i use from stock arch32 are go-2:1.17.2-1, kdecoration-5.24.3-1.0, kismet-2022_02_R1-1.1 and mixxx-2.3.2-1.2. i don;t see any of those making any difference to the kernel build...
@abaumann - what version of glibc are you using? i'm using glibc-2.35-3.0
@abaumann - yup. you have the right compiler and linker versions. my rebuild works as expected using the same versions.
CONFIG_GCC_VERSION=110200
CONFIG_CLANG_VERSION=0
CONFIG_AS_VERSION=23800
CONFIG_LD_VERSION=23800
CONFIG_LLD_VERSION=0
i'm using the same config (+config.i686) you are. what else could be causing a mismatch?
@nateewy - i'm seeing a date of 04/16 on the 5.17.3 kernel from the arch32 core repository.
am having to do another kernel rebuild, this time with 5.17.3.
@abaumann - thanks much. that *should* fix things up. i did check structleak_plugin.c and a couple of things caught my eye that follow back to include/linux/compiler.h - which did change between gcc 11.1 and 11.2 (02/02/22). it's not a file that's changed often, but apparently one to keep an eye on.
@abaumann - i think the problem comes down to the structleak_plugin.so object file. there were 95 bug and regression fixes that differentiate gcc 11.1 and 11.2 which *shouldn't* cause any problems, but my thought is that one of those fixes affected structleak_plugin. i didn't immediately think it could be the compiler version either. it's normal to be able to run software compiled with one version of gcc across a good number of gcc updates, and certainly across any minor updates within a major version, so it's not that i don;t understand where you're coming from. i have a few quickie C programs i've coded up over time as utilities that i haven't ever recompiled, and they still work perfectly, despite the fact that gcc has been updated many times since they were first compiled/linked. however, even the name of the plugin suggests it was created to patch over some kind of odd, leaking structure issue to begin with, and i have to wonder if one (or more) of the 95 fixes fundamentally changed the compiler output for that module specifically (or, possibly, other modules too, but we haven;t come across them yet). so, this might be a one-off issue.
IMHO a compiler should expose a stable enough API, so that any specific range of compilers can build the same kernel. This is not a nice thing if the kernel starts to depend on specific gcc versions.
i concur. i didn't open this thread because i thought someone was doing something wrong, but because it was anomalous behaviour. it took a couple of rebuilds to start me thinking it might be a compiler problem. when i started rebuilding 5.17.1 i noticed the config's GCC setting was 11.1 and, even though the build resets GCC to the version you're actually using, it made me wonder if y'all are using 11.1 to build the stable version of the kernel even though the stable compiler version is 11.2.
i'll take a look at structleak_plugin.cpp (and .h) and see if there's anything obvious, even though i'm not really sure what i'm looking for.
@abaumann - aaaand we're back. 5.17.1 has the same issue. having to rebuild it. i see in the config file that gcc is defined as 11.1. you aren;t using gcc-11.1 to build the kernel are you? gcc-11.2 has been in the stable repository for a while now.
haven't seen any issues with python-3.10. yet.
Edit: apparently, it's not just my system going through dkms issues with the "stable" kernels - @nateewy is reporting the same error.
Edit2: it's extremely interesting that i opened this thread the very day my system updated gcc from 11.1 to 11.2 - 03/11/22.
[2022-03-11T19:37:52-0500] [ALPM] upgraded gcc (11.1.0-3.0 -> 11.2.0-3.4)
@abaumann - i have no issue with long explanations, Andreas. was a software engineer for 30 years (until the 2008 recession and my age conspired to leave me unemployed for the past 11 years), so i do have a pretty good idea just how much work you 2 guys are doing, and i appreciate getting some details on the issues you're facing. i don't envy you, bud.
i do use the shims whenever i find i have to. the icu ones seem to crop up pretty often, but aren;t the only ones i occasionally have to use. as you described, though, i don;t see them being used effectively for the current issues. between the emerging assumption of sse2 support and the dance you have to do to release coherent packaging, you're obviously facing an enormous task.
for now i'll be patient and let my users know that they might want to hold onto whatever works for them right now until you're able to resolve things - whatever the resolution turns out to be. most of my users are running arch64 anyway.
i have no 32-bit hardware either, btw. i have a headless intel duo laptop running arch32 i use for building, and a VM i use for testing. i'd be happy to post any issues i come across, if that helps.
i think we have a bigger issue here with boost, and perhaps other packages built against python-3.10. first, these packages all require boost:
alembic boost clucene codeblocks cpp-hocon facter glom hugin kig kmymoney leatherman libappimage libcmis libetonyek libixion
libkolabxml libphonenumber librevenge librime libtorrent-rasterbar libwhereami maeparser mapnik openimageio openshadinglanguage openvdb python2-tagpy
scantailor-advanced scribus source-highlightthe surprise was that gdb also relies on boost-libs:
ldd /usr/bin/gdb
linux-gate.so.1 (0xb7f06000)
libreadline.so.8 => /usr/lib/libreadline.so.8 (0xb7541000)
libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0xb74cc000)
libdl.so.2 => /usr/lib/libdl.so.2 (0xb74c7000)
libguile-2.2.so.1 => /usr/lib/libguile-2.2.so.1 (0xb737c000)
libpython3.9.so.1.0 => /usr/lib/libpython3.9.so.1.0 (0xb6fc5000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0xb6fc0000)
libm.so.6 => /usr/lib/libm.so.6 (0xb6eb6000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb6e86000)
liblzma.so.5 => /usr/lib/liblzma.so.5 (0xb6e59000)
libmpfr.so.6 => /usr/lib/libmpfr.so.6 (0xb6d94000)
libgmp.so.10 => /usr/lib/libgmp.so.10 (0xb6d08000)
libsource-highlight.so.4 => /usr/lib/libsource-highlight.so.4 (0xb6c53000)
libdebuginfod.so.1 => /usr/lib/libdebuginfod.so.1 (0xb6c4a000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb6a2a000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb6a0b000)
libc.so.6 => /usr/lib/libc.so.6 (0xb6812000)
libgc.so.1 => /usr/lib/libgc.so.1 (0xb67bb000)
libffi.so.8 => /usr/lib/libffi.so.8 (0xb67b0000)
libunistring.so.2 => /usr/lib/libunistring.so.2 (0xb662d000)
libltdl.so.7 => /usr/lib/libltdl.so.7 (0xb6621000)
libcrypt.so.2 => /usr/lib/libcrypt.so.2 (0xb65ea000)
/lib/ld-linux.so.2 => /usr/lib/ld-linux.so.2 (0xb7f08000)
libutil.so.1 => /usr/lib/libutil.so.1 (0xb65e3000)
libboost_regex.so.1.78.0 => not found
libcurl.so.4 => /usr/lib/libcurl.so.4 (0xb6533000)
libnghttp2.so.14 => /usr/lib/libnghttp2.so.14 (0xb6504000)
libidn2.so.0 => /usr/lib/libidn2.so.0 (0xb64e1000)
libssh2.so.1 => /usr/lib/libssh2.so.1 (0xb6497000)
libpsl.so.5 => /usr/lib/libpsl.so.5 (0xb6484000)
libssl.so.1.1 => /usr/lib/libssl.so.1.1 (0xb63f0000)
libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1 (0xb6178000)
libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xb611b000)
libzstd.so.1 => /usr/lib/libzstd.so.1 (0xb6074000)
libbrotlidec.so.1 => /usr/lib/libbrotlidec.so.1 (0xb6066000)
libz.so.1 => /usr/lib/libz.so.1 (0xb604c000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb5f66000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb5f33000)
libcom_err.so.2 => /usr/lib/libcom_err.so.2 (0xb5f2e000)
libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xb5f1d000)
libkeyutils.so.1 => /usr/lib/libkeyutils.so.1 (0xb5f15000)
libresolv.so.2 => /usr/lib/libresolv.so.2 (0xb5f02000)
libbrotlicommon.so.1 => /usr/lib/libbrotlicommon.so.1 (0xb5edf000)note the reference to libboost_regex.so.1.78.0 in the middle of all that.
so, without python-3.10, boost and libboost 1.78 don't work and need to be downgraded to 1.76 with python-3.9. but without boost 1.78, a whole lot of software that's been pushed to stable doesn;t work. i think we're in a catch-22 here and i have no idea how many packages actually have a dependency on boost-1.78 - they're linked against 1.78 even though they don;t have an explicitly listed dependency (PKGBUILD depends=).
@abaumann - i am very aware of the fact that there are only 2 of you keeping this going, and the amount of work it takes to keep everything straight. if i didn;t, my posts would fill your forum. but i don;t do that, and instead i take the time to find the right pieces from the testing repos, or build them as i need them. i even leave posts for my users that despite my grumblings over arch32, the job of maintaining it is being handled by only 2 people and it's an eye-wateringly huge job for 2 people.
i'll take a look at the uvesafb source and push a fix. since i have the source code locally, i didn;t notice the git change.
however, having to rebuild the kernel is a big enough pain in the butt to prompt a forum post. since you've been able to build the modules against your own system's kernel, i will take a look at everything i have installed in case i installed something into my own system from testing or staging that still may be ahead of where you're at in the stable repos. nothing comes to mind, but that doesn;t mean i haven;t forgotten something. pacman usually tells me what's out of sync and installed locally and the only thing it's telling me is that archiso is behind the current version.
however i do know exactly what makes it into my archiso builds (where uvesafb is a critical module to provide support for the intel gma500 family of graphics processors) and only the packages i listed are out of sync with the stable repos.
as for python, i wouldn;t want you to push 3.10 until it's ready. just please be careful what you're building against it right now. as i pointed out, you built boost against 3.10 and pushed it to the stable repository. boost should have been left at v1.76 with python 3.9 until 3.10 was ready to go. that's just one example. i also maintain a repository for my users that i need to keep updated and i run into version incompatibilities all the time. it's time consuming on my side to have to deal with that. it gets really bad when you're pushing a new version of kde/plasma/qt5 and the versions of everything are all over the board. but, i know there are only 2 of you maintaining things - i just do what i have to to solve the puzzle.
so, this is not so much a complaint than a wtf. the kernel installation should be able to build dynamic modules, otherwise it's missing a big part of its functionality.
I have:
dkms 3.0.3-1.0
linux-headers 5.16.15.arch1-1.1 (rebuild)
gcc 11.2.0-3.4
r8101-dkms 1.035.03-2.0
r8168-dkms 8.049.02-1
uvesafb-dkms 1.0.4-1
I should be able to do a pacman query to identify anything locally installed using 'pacman -U'.
as for go, i'll just rebuild when i need to.
I'm using the uvesafb, r8101, and r8168 dkms modules, all 3 of which fail to compile - they're pretty standard. I'm on an i686 system using the stable repos with the following exceptions - go-1.17.2, mixxx-2.3.2, kdecoration-5.24.3. I had to downgrade boost-1.78 to v1.76, since 1.78 was built against python 3.10 which has not yet been released into the stable repository. The boost downgrade also meant a rebuild of libphonenumber, and was necessary to build calamares which has a heavy dependence on boost. So, I'm not seeing anything there that should interfere with the building of kernel modules, but I am seeing more than enough evidence that packages are being built against test or staging software and then released to the stable repository. This isn;t my first rodeo where arch32 is concerned. This type of issue comes up time and time again. I'm constantly having to rebuild, downgrade and plunder packages from the test repos to get a functioning system and a functioning build for my users.
And yes, I know 5.17 is in the works, but will it really solve this issue? arch64 had no issues with 5.16.x where dkms modules were concerned, and I just finished building 5.16.16 which works just fine having been built against a stable system, even though your own build of the same version failed to compile any of the dkms modules when installed. Y'all are missing something...
And it's back with 5.16.15. This is a pretty significant issue. Modules are unbuildable and we shouldn;t have to rebuild the kernel every time y'all release a new version! This needs to be solved at the build/release level, not by individual users.
The error "cc1: error: failed to initialize plugin ./scripts/gcc-plugins/structleak_plugin.so" suggests kernel builds are being made against a library, or libraries, that haven't been released yet. I saw the same issue with boost, which was build against python 3.10, which hasn;t been released yet. These builds shouldn;t be done against unreleased software versions!