gcc-config generates duplicate entries in /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf when there are several gcc profiles which point to the same compiler. Fix idea: add `sort -u` to the gcc-config script (if it doesn't break the desired effect of `tac`?) Reproducible: Always Steps to Reproduce: 1. Switch to a Gentoo profile that provides several gcc profiles, such as hardened. 2. Switch to whichever profile using gcc-config. ~ # gcc-config -l [1] x86_64-pc-linux-gnu-4.9.3 * [2] x86_64-pc-linux-gnu-4.9.3-hardenednopie [3] x86_64-pc-linux-gnu-4.9.3-hardenednopiessp [4] x86_64-pc-linux-gnu-4.9.3-hardenednossp [5] x86_64-pc-linux-gnu-4.9.3-vanilla ~ # gcc-config 1 * Switching native-compiler to x86_64-pc-linux-gnu-4.9.3 ... [ ok ] Actual Results: ~ # cat /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/32 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/32 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/32 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/32 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/32 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3 Expected Results: ~ # cat /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/32 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3 I traced this behaviour down to /usr/bin/gcc-config line 427, here is the excerpt: # Regardless of the profile selected, keep the runtime lookup # paths stable. Otherwise, all the apps that were built with # a new compiler will start trying to use older versions of # the libs, and life gets sad. We work off the assumption # that every shared library gcc ships is ABI compatible (as # is the point of SONAMEs). We don't have to worry about # static libraries here as gcc itself will take care of # linking against its own internal paths first. #297685 local MY_LDPATH MY_LDPATH=$(${SED} -n \ -e '/^LDPATH=/{s|LDPATH=||;s|"||g;s|:|\n|g;p}' \ "${GCC_ENV_D}"/${CHOST}-* | tac ) I am not sure whether the above results are intended, but this code seems to explicitly generate them.
pretty sure it's always been this way as long as minispecs have been around gcc-config has to be careful of sorting as the quoted comment covers (bug 297685)
We should be able to close this now that gcc-4 and earlier is masked. AFAIK the mechanism is completely different in current stable gcc-6 and gcc-7.
