Running updates I suddenly encountered errors occurring such as /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/librhash.so: error adding symbols: file in wrong format After various attempts to solve the issue it appeared to me that the path was wrong and cmake was attempting to link a 32 bit library to a 64 bit application. So I went into the failed ebuild work directory and changed the path in the make files and sure enough the ebuild completed. Since the 32 bit environment I was keeping alive was a leftover legacy thing I decided I might just as well get rid of it, which turned out to be easier said then done because I also have some legacy 64 bit stuff that needs to stay but was masked in the profile. So today I pretty much got all done with removal of ABI_X86_32 except for four remaining packages including poppler and fontforge. Fontforge still turned out to trip over a 32 bit library that is impossible to remove because it is part of glibc which has multilib enforced. Poppler however showed a very different issue, being that cmake searched for its own inclusion modules (qt5core, libjpeg) in /usr/lib while they are in fact installed in /usr/lib64. So it turns out it would have helped if this site had been available yesterday (it was being moved to a different server) as today I found bug #890967 which stated similar issues with compile jobs though the subject implies a different cause. It included a hack to the cmake.eclass but while that solved the issue of linking to 32 bit libraries it did not solve the cmake module loading problem. Reverting to the bin package of my previous stable (3.24.3) turned out to solve all the issues. Reproducible: Always
Please provide exact steps to reproduce the issue(s). Also provide emerge --info.
Portage 3.0.44 (python 3.10.10-final-0, default/linux/amd64/17.1/desktop/gnome/systemd, gcc-12, glibc-2.36-r7, 5.15.41-gentoo x86_64) ================================================================= System uname: Linux-5.15.41-gentoo-x86_64-Intel-R-_Core-TM-_i7-2600K_CPU_@_3.40GHz-with-glibc2.36 KiB Mem: 8127644 total, 959940 free KiB Swap: 16777212 total, 16776700 free Timestamp of repository gentoo: Tue, 28 Mar 2023 08:45:01 +0000 Head commit of repository gentoo: ad5707fba9c252fc42b25b19487199ba38920e3e sh bash 5.1_p16-r2 ld GNU ld (Gentoo 2.39 p5) 2.39.0 app-misc/pax-utils: 1.3.5::gentoo app-shells/bash: 5.1_p16-r2::gentoo dev-java/java-config: 2.3.1::gentoo dev-lang/perl: 5.36.0-r2::gentoo dev-lang/python: 3.9.16_p3::gentoo, 3.10.10_p3::gentoo, 3.11.2_p2::gentoo dev-lang/rust: 1.66.1::gentoo dev-util/cmake: 3.24.3::gentoo dev-util/meson: 1.0.1::gentoo sys-apps/baselayout: 2.13-r1::gentoo sys-apps/sandbox: 2.29::gentoo sys-apps/systemd: 252.7::gentoo sys-devel/autoconf: 2.13-r7::gentoo, 2.71-r5::gentoo sys-devel/automake: 1.16.5::gentoo sys-devel/binutils: 2.39-r4::gentoo sys-devel/binutils-config: 5.4.1::gentoo sys-devel/gcc: 12.2.1_p20230121-r1::gentoo sys-devel/gcc-config: 2.8::gentoo sys-devel/libtool: 2.4.7-r1::gentoo sys-devel/llvm: 14.0.6-r2::gentoo, 15.0.7::gentoo sys-devel/make: 4.3::gentoo sys-kernel/linux-headers: 6.1::gentoo (virtual/os-headers) sys-libs/glibc: 2.36-r7::gentoo Repositories: gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://rsync.europe.gentoo.org/gentoo-portage priority: -1000 volatile: True sync-rsync-verify-max-age: 24 sync-rsync-verify-jobs: 1 sync-rsync-verify-metamanifest: yes sync-rsync-extra-opts: sattvik location: /var/lib/layman/sattvik masters: gentoo priority: 50 volatile: True user_defined location: /usr/local/portage/user_defined masters: gentoo priority: 50 volatile: True Installed sets: @system ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="@FREE freedist" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=native -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /etc/conf.d /etc/init.d /usr/share/config/kdm /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/skel /etc/terminfo /etc/vmware-installer" CXXFLAGS="-O2 -march=native -pipe" DISTDIR="/usr/portage/distfiles" ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GDK_PIXBUF_MODULE_FILE GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR XDG_STATE_HOME" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs buildpkg buildpkg-live config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms splitdebug strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="rsync://mirror.leaseweb.com/gentoo/ rsync://ftp.snt.utwente.nl/gentoo" LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LEX="flex" LINGUAS="en en_US en_GB nl" MAKEOPTS="-j4 -s" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" SHELL="/bin/bash" USE="X a52 aac acl acpi alsa amd64 bash-completion bidi bluetooth branding bzip2 cairo cdda cdr cjk cli colord crypt cups dbus dga dri dts dv dvd dvdr eds encode evo exif fat flac fortran gcj gd gdbm gif gles2 glitz gnome gnome-keyring gnome-online-accounts gnutls gpm gstreamer gtk gtk2 gui hal hfs iconv icu inotify introspection ipv6 jfs jpeg kerberos lame lcms libav libglvnd libnotify libsecret libtirpc lm_sensors lzo mad matroska mng mp3 mp4 mpeg multilib nautilus ncurses nls nptl nsplugin ntfs ogg opengl openmp pam pango pcre pdf png policykit ppds python qt5 rar readline real reiserfs samba sdl seccomp sound spell split-usr sqlite ssl startup-notification stream svg sysfs sysprof systemd test-rust threads tiff tracker truetype udev udisks unicode upower usb vorbis wayland win32codecs wxwidgets x264 xattr xcb xcomposite xfs xft xinerama xml xorg xscreensaver xv xvid zlib" ABI_X86="64" ADA_TARGET="gnat_2021" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" APACHE2_MPMS="prefork" CALLIGRA_FEATURES="karbon sheets words" CAMERAS="canon samsung pentax" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx mmxext sse sse2" CURL_SSL="openssl" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev void" KERNEL="linux" L10N="en en-US en-GB nl" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-4 php8-0" POSTGRES_TARGETS="postgres12 postgres13" PYTHON_SINGLE_TARGET="python3_10" PYTHON_TARGETS="python3_10" RUBY_TARGETS="ruby30" USERLAND="GNU" VIDEO_CARDS="fbdev nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq proto steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: ADDR2LINE, AR, ARFLAGS, AS, ASFLAGS, CC, CCLD, CONFIG_SHELL, CPP, CPPFLAGS, CTARGET, CXX, CXXFILT, ELFEDIT, EMERGE_DEFAULT_OPTS, EXTRA_ECONF, F77FLAGS, FC, GCOV, GPROF, INSTALL_MASK, LC_ALL, LD, LFLAGS, LIBTOOL, MAKE, MAKEFLAGS, NM, OBJCOPY, OBJDUMP, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, RANLIB, READELF, RUSTFLAGS, SIZE, STRINGS, STRIP, YACC, YFLAGS
Steps to reproduce: 1: install cmake-3.25.2 (stable) 2: attempt install of a package that either: - a) loads external cmake modules (e.g. poppler) - b) links to a library that also exists as a 32 bit library
Just reviewing #890967 Noticed that reporter had in his emerge --info cmake-3.25.1 (~amd64). So The fact that >=cmake-3.25 favors /usr/lib over /usr/lib64 could have been picked up on almost three months ago.
(In reply to Gordon Bos from comment #4) > Just reviewing #890967 > > Noticed that reporter had in his emerge --info cmake-3.25.1 (~amd64). So The > fact that >=cmake-3.25 favors /usr/lib over /usr/lib64 could have been > picked up on almost three months ago. Not as simple as that. If you look at the See Also'd bugs, you'll see he ended up finding junk in /etc/* which was causing his issues: https://bugs.gentoo.org/889822#c24 You'll also see we tried to in depth (on IRC as well) to investigate his problem.
(In reply to Gordon Bos from comment #3) > Steps to reproduce: > > 1: install cmake-3.25.2 (stable) > 2: attempt install of a package that either: > - a) loads external cmake modules (e.g. poppler) > - b) links to a library that also exists as a 32 bit library I'm willing to bet that if you try this in a clean stage3, it won't happen.
Didn't get a hit on that bug ID. As said, bad timing with Gentoo moving servers precisely after marking cmake-3.25.2 stable. The post you refer to sadly doesn't mention *what* supposedly bad content was in /etc and of course the point remains that <cmake-3.25 does not have an issue with that content. Regarding that thing about a fresh stage 3, that's not why I run a rolling release.
(In reply to Gordon Bos from comment #7) > Didn't get a hit on that bug ID. As said, bad timing with Gentoo moving > servers precisely after marking cmake-3.25.2 stable. The post you refer to > sadly doesn't mention *what* supposedly bad content was in /etc and of > course the point remains that <cmake-3.25 does not have an issue with that > content. Can you bisect CMake at least then so we can see what triggers it? > > Regarding that thing about a fresh stage 3, that's not why I run a rolling > release. My point is that there's something special about the environment people are hitting this in and we don't yet know what. It's not as simple as newer CMake (or newer Portage) given plenty of people, including me, have many ABI_X86_32 without hitting this. Trying to reproduce this in a clean stage3 and incrementally making it more like your normal environment would go a long way in helping with understanding the problem.
(In reply to Sam James from comment #8) > > Trying to reproduce this in a clean stage3 and incrementally making it more > like your normal environment would go a long way in helping with > understanding the problem. (The idea being you would do it in a chroot in /tmp/ or some other temporary location you can throw away. Not reinstall your system, of course.)
Well, it's not even about having ABI 32 enabled because after I deleted it since I really don't need it any more the trouble with /usr/lib being favored over /usr/lib64 the issue still hits me. The main puzzling bit here actually not even being that cmake links 32 bit libraries to 64 bit code but attempting to fetch its own loadable modules from an incorrect path.
Just a thought... How about I attach the bin package that was created when I installed cmake-3.25.2? That might at least enable you to determine if the issue is related to the runtime environment only (as you appear to suspect) or somehow becomes part of cmake's internal code.
Okay, so today I did a full reinstall of 3.24.3 rather than rely on the previous bin package and it still resulted in a working dev environment. I then did a full reinstall of 3.52.2 and it is still broken, favoring /usr/lib over /usr/lib64 even for its own modules. It is truly mind staggering that any person could have a running version of Gentoo on a 64 bit platform where this version of cmake runs correctly.
You still have not provided sufficient instructions to reproduce the problem. Please provide exact steps, including the specific packages you attempt to build.
(In reply to Gordon Bos from comment #12) > Okay, so today I did a full reinstall of 3.24.3 rather than rely on the > previous bin package and it still resulted in a working dev environment. I > then did a full reinstall of 3.52.2 and it is still broken, favoring > /usr/lib over /usr/lib64 even for its own modules. Can you try bisect CMake then? That would be a big help in trying to identify what suddenly made things break for you. > It is truly mind > staggering that any person could have a running version of Gentoo on a 64 > bit platform where this version of cmake runs correctly. I know, but they do. And I suspect if you tried it in a fresh chroot in /tmp or similar, it'd work. That's not to say you're to blame, it's to say there's some specific environmental factor we're missing thus far.
(A build.log in full and the CMake logs from a broken package would also help a bit.)
Created attachment 859502 [details] cmake-3.24.3-build.log
Created attachment 859503 [details] cmake-3.25.2-build.log
Created attachment 859504 [details] fontforge-20230101-build-cmake-3.24.3.log
Created attachment 859505 [details] fontforge-20230101-build-cmake-3.25.2.log
Created attachment 859506 [details] poppler-23.01.0-cmake-3.24.3.log
Created attachment 859507 [details] poppler-23.01.0-cmake-3.25.2.log
Could Mike Gilbert please stop marking a confirmed issue as resolved? Also, could Mike Gilbert please stop asking for info that was already provided and if he really does want redundant info be more specific in what form he would like to receive this pointless mountain of log lines so that he doesn't have to nag about not being understood?
@Sam While Mike is attempting to plough through all the useless log files here's a simple test case showing the issue: CMakeLists.txt ====================== cmake_minimum_required(VERSION 3.5) project(test) find_library(MathLib_LIBRARIES NAMES m DOC "math library") message("Target architecture is ${CMAKE_HOST_SYSTEM_PROCESSOR}") message("Cmake system prefix path ${CMAKE_SYSTEM_PREFIX_PATH}") message("Cmake system library path ${CMAKE_SYSTEM_LIBRARY_PATH}") message("Found Mathlib at ${MathLib_LIBRARIES}") find_package(GtkDoc) if(GtkDoc_FOUND) message("Found GtkDoc version ${GtkDoc_VERSION}") else() message("Did not find GtkDoc") endif() find_package(Boost) ====================== Result with cmake-3.24.3: ====================== #cmake . -- The C compiler identification is GNU 12.2.1 -- The CXX compiler identification is GNU 12.2.1 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /usr/bin/cc - skipped -- Detecting C compile features -- Detecting C compile features - done -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done Target architecture is x86_64 Cmake system prefix path /usr/local;/usr;/;/usr;/usr/local;/usr/X11R6;/usr/pkg;/opt Cmake system library path /usr/x86_64-pc-linux-gnu/lib//gcc;/usr/x86_64-pc-linux-gnu/lib/;/usr/lib64;/usr/libx32;/usr/lib32;/usr/lib;/lib Found Mathlib at /usr/lib64/libm.so Found GtkDoc version 1.33.1 -- Found Boost: /usr/lib64/cmake/Boost-1.81.0/BoostConfig.cmake (found suitable version "1.81.0", minimum required is "1.71.0") -- Configuring done -- Generating done -- Build files have been written to: ====================== Result with cmake-3.25.2: ====================== #cmake . -- The C compiler identification is GNU 12.2.1 -- The CXX compiler identification is GNU 12.2.1 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /usr/bin/cc - skipped -- Detecting C compile features -- Detecting C compile features - done -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done Target architecture is x86_64 Cmake system prefix path /usr/local;/usr;/;/usr;/usr/local;/usr/X11R6;/usr/pkg;/opt Cmake system library path /usr/x86_64-pc-linux-gnu/lib//gcc;/usr/x86_64-pc-linux-gnu/lib/;/usr/lib64;/usr/libx32;/usr/lib32;/usr/lib;/lib Found Mathlib at /usr/lib/libm.so CMake Warning at CMakeLists.txt:13 (find_package): By not providing "FindGtkDoc.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "GtkDoc", but CMake did not find one. Could not find a package configuration file provided by "GtkDoc" with any of the following names: GtkDocConfig.cmake gtkdoc-config.cmake Add the installation prefix of "GtkDoc" to CMAKE_PREFIX_PATH or set "GtkDoc_DIR" to a directory containing one of the above files. If "GtkDoc" provides a separate development package or SDK, be sure it has been installed. Did not find GtkDoc -- Found Boost: /usr/include (found suitable version "1.81.0", minimum required is "1.71.0") -- Configuring done -- Generating done -- Build files have been written to: ====================== The latter can be corrected by setting CMAKE_PREFIX_PATH as suggested in the error: #cmake -DCMAKE_PREFIX_PATH="/usr/lib64;/usr/lib64/cmake" . Which is rubbish of course because even if this could be enforced by portage that will still cause the issue to affect stand alone projects.
(In reply to Gordon Bos from comment #22) > Could Mike Gilbert please stop marking a confirmed issue as resolved? I'm marking it as RESOLVED/NEEDINFO because we require more information to do anything useful with this bug report. > Also, could Mike Gilbert please stop asking for info that was already > provided and if he really does want redundant info be more specific in what > form he would like to receive this pointless mountain of log lines so that > he doesn't have to nag about not being understood? I did not ask you for a "pointless mountain of log lines". I asked you for exact steps so that I may attempt to reproduce the issue on my own system(s). What you have provided thus far is insufficient for me to do so.
To be able to reproduce the issue, I need exact steps to perform within a chroot environment with a freshly unpacked stage3 tarball. This would include: 1. Any settings you apply in /etc/portage. 2. Any packages that must be installed before attempting to reproduce the issue. 3. Examples of packages that should fail once 1 and 2 are satisfied.
(In reply to Gordon Bos from comment #23) I tried running your example on my amd64 multilib system with cmake-3.26.1. Here is the resulting output: % cmake .. -- The C compiler identification is GNU 12.2.1 -- The CXX compiler identification is GNU 12.2.1 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /usr/bin/cc - skipped -- Detecting C compile features -- Detecting C compile features - done -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done Target architecture is x86_64 Cmake system prefix path /usr/local;/usr;/;/usr;/usr/local;/usr/X11R6;/usr/pkg;/opt Cmake system library path /usr/x86_64-pc-linux-gnu/lib//gcc;/usr/x86_64-pc-linux-gnu/lib/;/usr/lib64;/usr/libx32;/usr/lib32;/usr/lib;/lib Found Mathlib at /usr/lib64/libm.so Found GtkDoc version 1.33.1 -- Found Boost: /usr/lib64/cmake/Boost-1.81.0/BoostConfig.cmake (found version "1.81.0") -- Configuring done (1.3s) -- Generating done (0.0s) -- Build files have been written to: /home/floppym/devel/bug903564/build
Good Lord! I found the culprit. It is in this change between 3.24 and 3.25 ============================================================================== --- a/Modules/Platform/Linux.cmake 2022-11-01 15:55:49.000000000 +0100 +++ b/Modules/Platform/Linux.cmake 2023-01-19 15:32:19.000000000 +0100 @@ -1,3 +1,4 @@ +set(LINUX 1) set(CMAKE_DL_LIBS "dl") set(CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG "-Wl,-rpath,") set(CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG_SEP ":") @@ -86,7 +87,12 @@ # Debian has lib32 and lib64 paths only for compatibility so they should not be # searched. -if(NOT CMAKE_CROSSCOMPILING AND EXISTS "/etc/debian_version") - set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB32_PATHS FALSE) - set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS FALSE) +if(NOT CMAKE_CROSSCOMPILING) + if (EXISTS "/etc/debian_version") + set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB32_PATHS FALSE) + set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS FALSE) + endif() + if (EXISTS "/etc/arch-release") + set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS FALSE) + endif() endif() ============================================================================== Now for the million dollar question: how on earth did /etc/arch-release get on my system? I've never had Arch. According to the timestamp on the file it's been there since 2013 and there's no package that owns it.
(In reply to Gordon Bos from comment #27) Ah ha! Thanks for closing the loop on this; in the future we can ask people to check for odd release files in /etc if similar problems are reported.
(In reply to Mike Gilbert from comment #24) > I did not ask you for a "pointless mountain of log lines". I asked you for > exact steps so that I may attempt to reproduce the issue on my own > system(s). What you have provided thus far is insufficient for me to do so. Yes and I told you that the only step involved is installing cmake-3.25.x which is something you were not willing to accept even though a previous report stating the exact same thing already turned out to exist. As it stands it would be impossible to replicate this on a newly installed system or in fact by any recent user as this turned out to be the result of a ten year old bug that just now showed its teeth.
(In reply to Gordon Bos from comment #29) The only step was not "install cmake-3.25.x". Additionally, we would have needed to create /etc/arch-release. You really can't expect us to troubleshoot an issue we cannot reproduce with the instructions you gave. I get that you are annoyed with me, but I don't see what you expected me to do given the weirdness on your system.
I think we could add a warning on this in pkg_postinst. It may still affect prefix users but it's more expected there.
(In reply to Mike Gilbert from comment #30) > (In reply to Gordon Bos from comment #29) > > The only step was not "install cmake-3.25.x". Additionally, we would have > needed to create /etc/arch-release. > > You really can't expect us to troubleshoot an issue we cannot reproduce with > the instructions you gave. I get that you are annoyed with me, but I don't > see what you expected me to do given the weirdness on your system. From my point of view it was. Either way it would not have made any difference if I had stated step 1 to be to `install Gentoo twelve years ago` because you could never replicate this on a new system, be it bare metal, chroot or VM. Am I annoyed with you? Well yes and no. It's not specifically you. What I do notice with respect to bug reports in general is that you guys like to challenge the initial findings of the reporter. Like in this case you want to discover yourself that the actual error is not in the link line but happens way earlier during configure, which was already in the report. So yes I don't really get why you would want to redo all the legwork already done. And then of course there is this thing that you want to be able to replicate it on a brand new install which you refer to as `need info` and effectively states that your stance is that everybody should reformat their drives and do a reinstall every week just like you make pretend to do. As I said earlier, that's not why I run a rolling release and it is most definitely not why I don't have tilde in my default accepted keywords. Or to put it more bluntly, you guys seem more eager to kill the messenger than attacking any issues. Which is a shame.
I will state again: I was simply asking for more information about the problem. That's what RESOLVED/NEEDINFO is meant to convey: that we don't have enough information to confirm or disprove that a bug exists. Don't read more into it than that. If I challenge your initial findings, that's generally because the information isn't specific enough to be useful. There are really only two ways for us to move forward on a bug report like this: 1. You give us enough information to actually diagnose and fix the issue. 2. We reproduce the issue and diagnose it ourselves. I tend to rely on the second option because I have no direct control over the first option. In the end, the first option turned out to be the path forward because you were able to figure out the problem yourself.
Hate to say it, but I don't think you really get what Gentoo is about. Every user has a history, be it one day, a week, a month, a year, or ten years and beyond. Simply assuming every bug to be reproducible in a fresh system is effectively denying that Gentoo is a rolling release. Defaulting your solution to be that people should re-install their system is not what they want to hear, especially since you're no handing out any guarantees that this will in fact solve the bug encountered. You say you were simply asking for more information, but that's not actually what you did. You were pushing for a guide how to reproduce this on a fresh system but you didn't really ask for it and you sure weren't ready for the answer that this particular issue seemed intrinsic to cmake (which it is, be it that it only affects systems that have been running for a significant time and we still don't know how long and what package wrote the offending file) and you made an issue about it that your (untold) prerequisites were not met. At the same time it became clear that the issue reported here was in fact a known issue and devs should have expected follow up issues to be reported when they went ahead and mark cmake-3.25.2 stable regardless. That was the point where for me you lost your credibility and since you still hadn't told what you really wanted I buried you under a shipload of logs that showed nothing other than what was already told, being that the newer cmake ignored the lib64 paths for no apparent reason. It was only then when you made clear that you were aiming to receive the impossible in response to `need info`. In contrast, Sam made some useful comments be it that the info he provided did not make much sense at first. The problem of course being that the person that had first reported this issue (over three months ago) had not logged what files he had removed from /etc that apparently had solved the issue for him. I actually went in there and did in fact delete a bunch of obsolete stuff but it's not like if it isn't owned by a package it's safe to delete. There are a lot of auto generated files in there and I'm not risking wrecking my system by deleting one wrong file. Eventually I did what apparently nobody thought of doing in the past three months and pulled a diff between the source of the last working version of cmake and the one that didn't work. Not really knowing what to look for I just happened to stumble over that partial that I quoted above. And yes I know, you hate that because you want to see the full diff. Right? Do note that the outcome here does not actually solve the issue. As the status tells, the resolution is that it works for me as I manually deleted the offending file. It is still up to you to figure out where the file came from in the first place and/or how to handle its possible presence in future. Because however much you like to question my competence, you can take my word for it that I never felt any urge to run `touch <whatever-distro>-release` in /etc.
(In reply to Gordon Bos from comment #34) Nowhere did I say that people should re-install their system when things go wrong. I asked for steps to reproduce the problem from a clean environment. It's a fundamental technique for narrowing the scope of a problem. Sam suggested that you try this in a chroot, and you seemed to be unwilling to even attempt that. Had you attempted to reproduce it from a clean environment and failed, that would have provided a useful data point, and I would have stopped asking. Spamming the bug with irrelevant logs I didn't ask for out of spite certainly wasn't helpful. In the future, I will try to be more explicit in why I am asking for information to prevent misunderstandings.
If you would like to continue this conversation, let's move to email or IRC. I don't want to dismiss you, but I don't think adding more comments to this bug is a good idea.
You're skipping the part that Sam also said that since the report in January there had been multiple attempts to replicate the issue on a fresh system and that he believed I would not be able to do so either. There's two elements to what Sam said. The first is I'm putting you on a wild goose chase but unlike Mike I'm not running around the bush about it. The second is you're best option to resolve this issue is to restart from new. Like I said before, it's not about you, Mike. It's all of you. It's your general stance that if you can't replicate the issue in the latest release of Debian it doesn't exist. Yes that annoys me, because I run Gentoo, which is what this site is suppose to be about. And that's the last I will comment on what for me turned out to become a seriously frustrating topic.
So there is no way to update and fix existing system?
(In reply to Oleg from comment #38) > So there is no way to update and fix existing system? The way to fix is to delete /etc/arch-release Which shouldn't be there but for some obscure reason was created some time in the past by a package that will likely remain unknown forever.
