Running ldconfig on a uclibc system gives some warnings; they are apparently caused by a conflict with the baselayout (see below) Reproducible: Always Steps to Reproduce: 1. On a uclibc-based system, run /sbin/ldconfig Actual Results: ldconfig: You should remove '/lib' from '/etc/ld.so.conf' ldconfig: You should remove '/usr/lib' from 'etc/ld.so.conf' Expected Results: No complaints. Apparently, it happens due to this line in /etc/env.d/00basic LDPATH='/lib:/usr/lib:/usr/local/lib' On a glibc-based system, ldconfig does not complain. So, is this a uclibc bug? Or a baselayout bug?
It can be safely ignored but it is annoying and people have been asking about it. I'm not sure where the best place is to put the fix, but I'm leaning towards fixing up portage's pym/portage/util/env_update.py and having it check for a uclibc system and not adding /lib or /usr/lib (around line 194). Alternatively a patch against uclibc's ldconfig could just silently ignore those entries. Mike?
(In reply to comment #1) > It can be safely ignored but it is annoying and people have been asking > about it. I'm not sure where the best place is to put the fix, but I'm > leaning towards fixing up portage's pym/portage/util/env_update.py and > having it check for a uclibc system and not adding /lib or /usr/lib (around > line 194). > > Alternatively a patch against uclibc's ldconfig could just silently ignore > those entries. > > Mike? Actually, I just poked around a bit and its sufficient to just reduce the line in evn.d/00basic to LDPATH='/usr/local/lib'. I can't find anything but pym/portage/util/env_update.py which reads that file.
Nothing should be reading the env files directly ( as far as I know ). Their only purpose is to set the environment correctly. I believe this is not a uClibc bug because /lib and /usr/lib are being searched by ldconfig anyway so there is no reason to put them in /etc/ld.so.conf. I am reassigning this bug to baselayout maintainers where the 00basic env file belongs to.
Created attachment 350878 [details, diff] Patch against baselayout-2.2.ebuild While a minor warning, this bug has bugged me long enough. This will skip /lib and /usr/lib if USE=uclibc. It is actually set up for multilib with $(get_all_libdirs) and uclibc isn't (natively) multilib, but it doesn't hurt.
Actually, I can confirm that doing what ldconfig said and removing those, I ran into problems so I had to put them back. I had an old note(~1 month) about this: " Actually, those warnings are a lie of sorts, because if removed, revdep-rebuild will keep rebuilding stuff ad infinitum. This warning doesn't appear on non-hardened yet they are included. " This is what happens before and after: xxx env.d # revdep-rebuild * Configuring search environment for revdep-rebuild * Checking reverse dependencies * Packages containing binaries and libraries broken by a package update * will be emerged. * Collecting system binaries and libraries * Generated new 1_files.rr * Collecting complete LD_LIBRARY_PATH * Generated new 2_ldpath.rr * Checking dynamic linking consistency [ 100% ] * Dynamic linking on your system is consistent... All done. xxx env.d # env-update >>> Regenerating /etc/ld.so.cache... /sbin/ldconfig: You should remove `/lib' from `/etc/ld.so.conf' /sbin/ldconfig: You should remove `/usr/lib' from `/etc/ld.so.conf' xxx env.d # vim 00basic (edit out the /lib and /usr/lib) so it looks like this now: LDPATH='/usr/local/lib:/usr/lib/man-db/' xxx env.d # env-update >>> Regenerating /etc/ld.so.cache... xxx env.d # . /etc/profile xxx env.d # revdep-rebuild * Configuring search environment for revdep-rebuild * Checking reverse dependencies * Packages containing binaries and libraries broken by a package update * will be emerged. * Collecting system binaries and libraries * Generated new 1_files.rr * Collecting complete LD_LIBRARY_PATH * Generated new 2_ldpath.rr * Checking dynamic linking consistency [ 39% ] * broken /usr/lib/gcc/x86_64-gentoo-linux-uclibc/4.9.2/libcilkrts.la (requires -lpthread) * broken /usr/lib/gcc/x86_64-gentoo-linux-uclibc/4.9.2/libcilkrts.la (requires -ldl) [ 53% ] * broken /usr/lib/libdb-6.0.la (requires -lpthread) [ 54% ] * broken /usr/lib/libdb_cxx-6.0.la (requires -lpthread) * broken /usr/lib/libdb_sql-6.0.la (requires -lpthread) * broken /usr/lib/libdb_stl-6.0.la (requires -lpthread) * broken /usr/lib/libdb_tcl-6.0.la (requires -lpthread) [ 55% ] * broken /usr/lib/libltdl.la (requires -ldl) [ 100% ] * Generated new 3_broken.rr * Assigning files to packages * /usr/lib/gcc/x86_64-gentoo-linux-uclibc/4.9.2/libcilkrts.la -> sys-devel/gcc * /usr/lib/libdb-6.0.la -> sys-libs/db * /usr/lib/libdb_cxx-6.0.la -> sys-libs/db * /usr/lib/libdb_sql-6.0.la -> sys-libs/db * /usr/lib/libdb_stl-6.0.la -> sys-libs/db * /usr/lib/libdb_tcl-6.0.la -> sys-libs/db ^C * ...terminated. Removing incomplete 4_raw.rr 4_owners.rr.
Created attachment 421828 [details, diff] fix verbosity in ldconfig The easiest fix is to bring uclibc's ldconfig into line with glib'c ldconfig. I'm not sure how to interpret the intention of the verbose variable in utils/ldconfig.c. In many places it simply does (verbose > 0) to be verbose and (verbose <= 0) to not be verbose, but for these warnings, it has (verbose >= 0). So this looks like a bug, but then in main() where getopt() there's case 'q': if (verbose <= 0) verbose = -1; /* quiet mode */ break; so is there supposed to be a different meaning to verbose > 0, == 0 and == -1 ??? Maybe some bad logic creeped in. Anyhow this patch should go upstream.
