I wanted to emerge -av --depclean sys-devel/gcc:9.2.0 since I successfully merged gcc-9.3.0. The package was unmerged and then the fix_libtool_files.sh took over with the invocation: fix_libtool_files.sh 9.2.0' Its output: setterm: terminal xterm-256color does not support --blank Scanning libtool files for hardcoded gcc library paths... * [1/19] Scanning /lib ... * [2/19] Scanning /usr/lib ... * FIXING: /usr/lib/octave/5.1.0/liboctinterp.la ...[v] * FIXING: /usr/lib/octave/5.1.0/liboctgui.la ...[v] * FIXING: /usr/lib/octave/5.1.0/liboctave.la ...[v] * [3/19] Scanning ${LDPATH} ... After HOURS AND HOURS of running and staying at * [3/19] Scanning ${LDPATH} ... I decided to interrupt it. This is a bug. Reason ------ My /etc/ld.so.cache contains: /usr/lib32/opengl/nvidia/lib /usr/lib64/opengl/nvidia/lib include ld.so.conf.d/*.conf ... various other directories ... /usr/lib64/fltk ${LDPATH} /usr/lib64/octave/5.1.0 You see that there is a line before the last one having ${LDPATH}. Now, the problem is, ${LDPATH} evaluates to the empty string for the root user. And obviously, fix_libtool_files.sh does not check this and starts searching / - which is huge, with all its external disks mounted under it! Now, let's see, is this accusation against fix_libtool_files.sh true? fix_libtool_files.sh actually calls /usr/share/gcc-data/fixlafiles.awk which does all the work. In its function parse_ld_conf(), whose job is to parse the lines of /etc/ld.so.conf, it does check if the line is empty: if (ldsoconf_data ~ /^[[:space:]]*#/) continue if (ldsoconf_data == "") continue but a line ${SOME_ENVIRONMENT_VARIABLE} where $SOME_ENVIRONMENT_VARIABLE is empty will pass the emptiness tests above. This is because the tests do not evaluate the string before they test it for emptiness. Solution -------- Please check each line of /etc/ld.so.conf whether it is some environment variable and, if it is, evaluate it first before you do the emptiness checks and all the other work on it. Of course special care should be given on how to do this exactly, as one could have any variable there, waiting to be evaluated, leading to potential security holes (i.e. fixlafiles.awk executing some arbitrary program with root rights). I guess the right way to parse the lines of /etc/ld.so.cache is just as it is done by the ld program. Reproducible: Always Steps to Reproduce: 1. See above. 2. 3.
Some info: Portage 2.3.99 (python 3.7.6-final-0, default/linux/amd64/17.0/hardened, gcc-9.3.0, glibc-2.30-r8, 4.19.81-gentoo x86_64) ================================================================= System uname: Linux-4.19.81-gentoo-x86_64-Intel-R-_Core-TM-_i7-6700HQ_CPU_@_2.60GHz-with-gentoo-2.6 Timestamp of repository gentoo: Mon, 11 May 2020 00:45:01 +0000 sh bash 4.4_p23-r1 ld GNU ld (Gentoo 2.33.1 p2) 2.33.1 app-shells/bash: 4.4_p23-r1::gentoo dev-java/java-config: 2.2.0-r4::gentoo dev-lang/perl: 5.30.1::gentoo dev-lang/python: 2.7.17-r1::gentoo, 3.6.10::gentoo, 3.7.6::gentoo dev-util/cmake: 3.16.5::gentoo dev-util/pkgconfig: 0.29.2::gentoo sys-apps/baselayout: 2.6-r1::gentoo sys-apps/openrc: 0.42.1::gentoo sys-apps/sandbox: 2.13::gentoo sys-devel/autoconf: 2.13::gentoo, 2.69-r4::gentoo sys-devel/automake: 1.11.6-r3::gentoo, 1.12.6::gentoo, 1.13.4-r2::gentoo, 1.14.1::gentoo, 1.15.1-r2::gentoo, 1.16.1-r1::gentoo sys-devel/binutils: 2.30-r4::gentoo, 2.32-r1::gentoo, 2.33.1-r1::gentoo sys-devel/gcc: 7.3.0-r3::gentoo, 7.4.0-r2::gentoo, 8.3.0-r1::gentoo, 9.2.0-r2::gentoo, 9.3.0::gentoo sys-devel/gcc-config: 2.2.1::gentoo sys-devel/libtool: 2.4.6-r6::gentoo sys-devel/make: 4.2.1-r4::gentoo sys-kernel/linux-headers: 5.4::gentoo (virtual/os-headers) sys-libs/glibc: 2.30-r8::gentoo
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=92e383747ffc633ff6e85a02bf8cdb856eb1bcdc commit 92e383747ffc633ff6e85a02bf8cdb856eb1bcdc Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2020-06-19 18:15:21 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2020-06-19 20:52:43 +0000 toolchain.eclass: drop fix_libtool_files.sh fixlafiles.awk can mangle two things in .la fils: 1. patch reference 'from .../libstdc++.la' to '-lstdc++' 2. change ${CHOST} when user switches CHOST and rebuilds the system [1.] is not relevant since gcc-4 in Gentoo where we started deleting libstdc++.la on gcc installation. Nothing should embed libstdc++.la paths anymore. [2.] is a rare one-off step that has a lot more caveats than just .la file patching. Generally .la files are tracked by package manager and should not be changed after they are installed on disk. 'fix_libtool_files.sh' breaks that invariant. On top of that portage's FEATURES=fixlafiles removes nested .la files references. Let's remove 'fix_libtool_files.sh' and 'fixlafiles.awk' completely. If really needed we can reintroduce it as a separate tool. Closes: https://bugs.gentoo.org/722554 Closes: https://bugs.gentoo.org/657330 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> .../gnat-gpl/files/awk/fixlafiles.awk-no_gcc_la | 334 --------------------- dev-lang/gnat-gpl/files/fix_libtool_files.sh | 66 ---- eclass/toolchain.eclass | 40 +-- sys-devel/gcc/files/awk/fixlafiles.awk | 313 ------------------- sys-devel/gcc/files/awk/fixlafiles.awk-no_gcc_la | 334 --------------------- sys-devel/gcc/files/fix_libtool_files.sh | 66 ---- 6 files changed, 9 insertions(+), 1144 deletions(-)
