Created attachment 918938 [details] emerge--info I was having trouble emerging sys-apps/util-linux-2.40.4 because of missing symbols, specifically ``` libtool: link: x86_64-pc-linux-gnu-gcc -fsigned-char -fno-common -Wall -Wextra -Waddress-of-packed-member -Wdiscarded-qualifiers -Wformat-security -Wimplicit-function-declaration -Wmissing-declarations -Wmissing-parameter-type -Wmissing-prototypes -Wnested-externs -Wno-missing-field-initializers -Wold-style-definition -Wpointer-arith -Wredundant-decls -Wsign-compare -Wstrict-prototypes -Wtype-limits -Wuninitialized -Wunused-but-set-parameter -Wunused-but-set-variable -Wunused-parameter -Wunused-result -Wunused-variable -Wvla -Walloca -Werror=sequence-point -I./libsmartcols/src -march=native -O3 -fgraphite-identity -floop-nest-optimize -fdevirtualize-at-ltrans -fipa-pta -fno-semantic-interposition -flto=4 -fuse-linker-plugin -pipe -Wl,-O1 -Wl,-z -Wl,pack-relative-relocs -Wl,-O1 -Wl,-z -Wl,pack-relative-relocs -march=native -O3 -fgraphite-identity -floop-nest-optimize -fdevirtualize-at-ltrans -fipa-pta -fno-semantic-interposition -flto=4 -fuse-linker-plugin -pipe -o .libs/lscpu sys-utils/lscpu-lscpu.o sys-utils/lscpu-lscpu-cputype.o sys-utils/lscpu-lscpu-cpu.o sys-utils/lscpu-lscpu-topology.o sys-utils/lscpu-lscpu-virt.o sys-utils/lscpu-lscpu-arm.o sys-utils/lscpu-lscpu-dmi.o -Wl,--as-needed ./.libs/libcommon.a ./.libs/libsmartcols.so -Wl,-rpath -Wl,/cvmfs/software.dumont.ca/2021.02/compat/linux/x86_64/usr/lib64 /cvmfs/software.dumont.ca/2021.02/compat/linux/x86_64/usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld: /cvmfs/software.dumont.ca/2021.02/compat/linux/x86_64/usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../lib64/libncursesw.so: undefined reference to symbol 'stdscr' /cvmfs/software.dumont.ca/2021.02/compat/linux/x86_64/usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld: /cvmfs/software.dumont.ca/2021.02/compat/linux/x86_64/cvmfs/software.dumont.ca/2021.02/compat/linux/x86_64/usr/lib64/libtinfow.so.6: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status ``` Looking at config.log, it seems that NCURSES_LIBS does not contain -ltinfow, erroring with ``` Package tinfow was not found in the pkg-config search path. Perhaps you should add the directory containing `tinfow.pc' to the PKG_CONFIG_PATH environment variable Package 'tinfow' not found configure:31520: $? = 1 configure:31534: $PKG_CONFIG --exists --print-errors "tinfow" Package tinfow was not found in the pkg-config search path. Perhaps you should add the directory containing `tinfow.pc' to the PKG_CONFIG_PATH environment variable ``` Here's the crux of the issue, I think: ``` valandil /cvmfs/software.dumont.ca/2021.02/compat/linux/x86_64/var/db/repos/gentoo/sys-process/procps $ /cvmfs/software.dumont.ca/2021.02/compat/linux/x86_64/usr/bin/x86_64-pc-linux-gnu-pkgconf --libs tinfow Package tinfow was not found in the pkg-config search path. Perhaps you should add the directory containing `tinfow.pc' to the PKG_CONFIG_PATH environment variable Package 'tinfow' not found valandil /cvmfs/software.dumont.ca/2021.02/compat/linux/x86_64/var/db/repos/gentoo/sys-process/procps $ which pkg-config /cvmfs/software.dumont.ca/2021.02/compat/linux/x86_64/usr/bin/pkg-config valandil /cvmfs/software.dumont.ca/2021.02/compat/linux/x86_64/var/db/repos/gentoo/sys-process/procps $ readlink -f $(which pkg-config) /cvmfs/software.dumont.ca/2021.02/compat/linux/x86_64/usr/bin/x86_64-pc-linux-gnu-pkgconf valandil /cvmfs/software.dumont.ca/2021.02/compat/linux/x86_64/var/db/repos/gentoo/sys-process/procps $ /cvmfs/software.dumont.ca/2021.02/compat/linux/x86_64/usr/bin/pkg-config --libs tinfow -ltinfow ``` There seems to be a difference in search paths from calling the same binary from different symlinks, which seems very weird to me. I managed to work around it by manually shoving -ltinfow in the autotools setup for util-linux, but this doesn't address the root cause, only sidesteps it. I'll attach the ugly patches for context.
Created attachment 918940 [details, diff] util-linux ebuild patch
Created attachment 918941 [details, diff] util-linux-2.40.4-tinfo.patch
might be good to attach the config.log
Created attachment 918943 [details] config.log
Comment on attachment 918940 [details, diff] util-linux ebuild patch >--- util-linux-2.40.4.ebuild 2025-01-14 21:46:29.882727886 -0500 >+++ util-linux-2.40.4-r1.ebuild 2025-02-12 09:50:19.897900932 -0500 >@@ -296,7 +301,7 @@ > --enable-rename > --enable-rfkill > --enable-schedutils >- --with-systemdsystemunitdir="$(systemd_get_systemunitdir)" >+ --with-systemdsystemunitdir="${EPREFIX}/$(systemd_get_systemunitdir)" > --with-tmpfilesdir="${EPREFIX}"/usr/lib/tmpfiles.d > $(use_enable caps setpriv) > $(use_enable cramfs) systemd_get_systemunitdir already applies EPREFIX to the path, so this change is pointless and broken.
Please also attach a the full build log.
I suspect pkg-config is picking up settings from systemd.pc on the host system rather than from the Gentoo Prefix installation.
Created attachment 918991 [details] build.log
(In reply to Mike Gilbert from comment #5) > Comment on attachment 918940 [details, diff] [details, diff] > util-linux ebuild patch > > >--- util-linux-2.40.4.ebuild 2025-01-14 21:46:29.882727886 -0500 > >+++ util-linux-2.40.4-r1.ebuild 2025-02-12 09:50:19.897900932 -0500 > >@@ -296,7 +301,7 @@ > > --enable-rename > > --enable-rfkill > > --enable-schedutils > >- --with-systemdsystemunitdir="$(systemd_get_systemunitdir)" > >+ --with-systemdsystemunitdir="${EPREFIX}/$(systemd_get_systemunitdir)" > > --with-tmpfilesdir="${EPREFIX}"/usr/lib/tmpfiles.d > > $(use_enable caps setpriv) > > $(use_enable cramfs) > > systemd_get_systemunitdir already applies EPREFIX to the path, so this > change is pointless and broken. Without it, the prefix qa complained about files not installed in the prefix.
(In reply to Joey Dumont from comment #9) > Without it, the prefix qa complained about files not installed in the prefix. That indicates pkg-config or a pkgconfig file is broken on your system. Patching the util-linux ebuild is not the solution.
Comment on attachment 918991 [details] build.log Please do not use 'tar' when compressing single files.
Looking more closely at the error message, it is complaining about a symbol reference in libncursesw, not in the irqtop sources. libncursesw has a DT_NEEDED entry on libtinfow. It should not be necessary to name libtinfow explicitly on the link command line. I think your toolchain is broken, or your CFLAGS/LDFLAGS are breaking something here.
Also, I think your split ncurses/tinfo install is somehow messed up. Do the following libraries? ${EPREFIX}/usr/lib64/libncursesw.so ${EPREFIX}/usr/lib64/libtinfow.so How about the pkgconfig files? If so, please attach them to this bug for inspection. ${EPREFIX}/usr/lib64/pkgconfig/tinfow.pc ${EPREFIX}/usr/lib64/pkgconfig/ncursesw.pc
(In reply to Mike Gilbert from comment #13) > Do the following libraries? This should say "do the following libraries exist?"
Created attachment 919101 [details] ncursesw.pc
Created attachment 919102 [details] tinfow.pc
(In reply to Mike Gilbert from comment #10) > (In reply to Joey Dumont from comment #9) > > Without it, the prefix qa complained about files not installed in the prefix. > > That indicates pkg-config or a pkgconfig file is broken on your system. > Patching the util-linux ebuild is not the solution. I do acknowledge that shoving -ltinfow manually is a dumb workaround. I did so when I originally posted the patches too. I don't understand how a broken pkgconfig leads to /urs/lib/systemd files in the image directory though. This feels like a separate issue to me. Ack on not using tar for a single file. > libncursesw has a DT_NEEDED entry on libtinfow. It should not be necessary to name libtinfow explicitly on the link command line. Yep, this really confused me too. Ack on my weird CFLAGS/LDFLAGS breaking things. I'm fine with this being the resolution if I'm the only one hitting this. As for the libraries, they do exist, as do the pkgconfig files. I've attached them both. valandil ~ $ ls -ltra ${EPREFIX}/usr/lib64/libncursesw.so ${EPREFIX}/usr/lib64/libtinfow.so lrwxrwxrwx 1 valandil valandil 14 Jan 26 16:28 /cvmfs/software.dumont.ca/2021.02/compat/linux/x86_64//usr/lib64/libtinfow.so -> libtinfow.so.6 lrwxrwxrwx 1 valandil valandil 16 Jan 26 16:28 /cvmfs/software.dumont.ca/2021.02/compat/linux/x86_64//usr/lib64/libncursesw.so -> libncursesw.so.6
I see this in config.log: configure:31510: checking for tinfow configure:31517: $PKG_CONFIG --exists --print-errors "tinfow" Package tinfow was not found in the pkg-config search path. Perhaps you should add the directory containing `tinfow.pc' to the PKG_CONFIG_PATH environment variable Package 'tinfow' not found configure:31520: $? = 1 configure:31534: $PKG_CONFIG --exists --print-errors "tinfow" Package tinfow was not found in the pkg-config search path. Perhaps you should add the directory containing `tinfow.pc' to the PKG_CONFIG_PATH environment variable Package 'tinfow' not found configure:31537: $? = 1 configure:31551: result: no Package 'tinfow' not found So, pkg-config is not finding that tinfow.pc file you attached. That leads me to believe that something is wrong with pkg-config on your system: the wrong pkg-config binary is being invoked, or the wrong search path has been compiled into the binary.
Run this to see what pkg-config is using for the search path: /cvmfs/software.dumont.ca/2021.02/compat/linux/x86_64/usr/bin/x86_64-pc-linux-gnu-pkg-config --dump-personality Also, please check permissions on the pkgconfig-related paths and files to ensure that pkg-config can actually read them.
(In reply to Mike Gilbert from comment #18) > I see this in config.log: > > configure:31510: checking for tinfow > configure:31517: $PKG_CONFIG --exists --print-errors "tinfow" > Package tinfow was not found in the pkg-config search path. > Perhaps you should add the directory containing `tinfow.pc' > to the PKG_CONFIG_PATH environment variable > Package 'tinfow' not found > configure:31520: $? = 1 > configure:31534: $PKG_CONFIG --exists --print-errors "tinfow" > Package tinfow was not found in the pkg-config search path. > Perhaps you should add the directory containing `tinfow.pc' > to the PKG_CONFIG_PATH environment variable > Package 'tinfow' not found > configure:31537: $? = 1 > configure:31551: result: no > Package 'tinfow' not found > > So, pkg-config is not finding that tinfow.pc file you attached. > > That leads me to believe that something is wrong with pkg-config on your > system: the wrong pkg-config binary is being invoked, or the wrong search > path has been compiled into the binary. Yep, I quoted this in my original bug description. I did forget to show that PKG_CONFIG was set to x86_64-pc-linux-gnu-pkg-config, which is a symlink to x86_64-pc-linux-gnu-pkgconf. $EPREFIX/usr/bin/pkg-config is also a symlink to x86_64-pc-linux-gnu-pkgconf. Calling the binary from the different symlinks seems to result in a different search path being used. This is also in my original comment, but looking back at it it should have been made clearer.
(In reply to Mike Gilbert from comment #19) > Run this to see what pkg-config is using for the search path: > > /cvmfs/software.dumont.ca/2021.02/compat/linux/x86_64/usr/bin/x86_64-pc- > linux-gnu-pkg-config --dump-personality > > Also, please check permissions on the pkgconfig-related paths and files to > ensure that pkg-config can actually read them. Ah, there it is! This is a fun one, I did not expect that. Both are symlinks to $EPREFIX/usr/bin/x86_64-pc-linux-gnu-pkgconf. valandil ~ $ /cvmfs/software.dumont.ca/2021.02/compat/linux/x86_64/usr/bin/x86_64-pc-linux-gnu-pkg-config --dump-personality Triplet: x86_64-pc-linux-gnu SysrootDir: / DefaultSearchPaths: /usr/lib/pkgconfig /usr/share/pkgconfig SystemIncludePaths: /usr/include SystemLibraryPaths: /usr/lib valandil ~ $ /cvmfs/software.dumont.ca/2021.02/compat/linux/x86_64/usr/bin/pkg-config --dump-personality Triplet: default DefaultSearchPaths: /cvmfs/software.dumont.ca/2021.02/compat/linux/x86_64/usr/lib64/pkgconfig /cvmfs/software.dumont.ca/2021.02/compat/linux/x86_64/usr/share/pkgconfig SystemIncludePaths: /cvmfs/software.dumont.ca/2021.02/compat/linux/x86_64/usr/include SystemLibraryPaths: /cvmfs/software.dumont.ca/2021.02/compat/linux/x86_64/lib64 /cvmfs/software.dumont.ca/2021.02/compat/linux/x86_64/usr/lib64
Ah, my apologies for skimming comment 0. I think this weird pkgconf behavior warrants additional investigation, but I'm not sure I want to attempt that via bug commentary.
(In reply to Joey Dumont from comment #21) > Both are symlinks to $EPREFIX/usr/bin/x86_64-pc-linux-gnu-pkgconf Are you absolutely certain of that? It's really behaving like an entirely different program.
I just noticed this: Triplet: x86_64-pc-linux-gnu Do you have a personality override file under one of these locations? ${EPREFIX}/etc/pkgconfig/personality.d ${EPREFIX}/usr/share/pkgconfig/personality.d
(In reply to Mike Gilbert from comment #22) > Ah, my apologies for skimming comment 0. > > I think this weird pkgconf behavior warrants additional investigation, but > I'm not sure I want to attempt that via bug commentary. Joey, could you perhaps come onto IRC?
Sorry for disappearing, I was dealing with personal issues. Yes, I can jump onto IRC. I'm usually available 2030-2200EST on weekdays, and EST afternoons on weekends. What's a convenient time for you?
Please have a look at comment 24 first.
Reopening for visibility for now as someone else hit it on IRC.
Reopening the bug without any additional info does not seem useful.
