| Summary: | sys-devel/gcc: minispecs duplicate LDPATHs which induces gcc-config to generate duplicate ld.so.conf.d entries | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | calimeroteknik |
| Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | trivial | CC: | alexander, hardened, hydrapolic |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
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. |
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.