| Summary: | sys-devel/gcc-config-1.8-r1: binary wrappers are orphaned files, not in vdb | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Floyd Anderson <bts+gentoo> |
| Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | amd-1600, bts+gentoo, jstein, slyfox |
| Priority: | Low | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/gcc-config.git/commit/?id=9b907ef80bc421df23515afc4c306e4d96c67649 commit 9b907ef80bc421df23515afc4c306e4d96c67649 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2018-08-24 17:36:57 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-08-24 18:09:17 +0000 Convert binary wrapper to a symlink wrapper. Before the change: /usr/bin/gcc and friends were a copy of /usr/$(libexecdir)/misc/gcc-config After the change: /usr/bin/gcc is a symlink to a real compiler binary. Examples: /usr/${CTARGET}/gcc-bin/${GCC_VER}/gcc (native) /usr/${CHOST}/${CTARGET}/gcc-bin/${GCC_VER}/gcc (cross) gcc-config is a binary wrapper that does (or did) a few things: - [removed in 2011] injects additional CFLAGS_${ABI} Removed in commit 7ac40f3eb8434961f70485247d883f5b3009dcf2 "Stop auto appending CFLAGS_<abi> from the env." - traverses PATH for real compiler binary and reexecutes it. - reads /etc/env.d/05gcc-${CTARGET} as a fallback if PATH is empty. Today binary wrapper does only PATH resolution and re-execution. This change has a few minor benefits: - PATH will not contain explicit /usr/${CHOST}/${CTARGET}/gcc-bin/${GCC_VER} entry. This will make PATH shorter for those who have mavy cross-compilers installed. - compiler switch will not require sourcing '. /etc/profile' as changes are applied as soon an symlink is switched. - ccache will see gcc binary changes directly and react accordingly. Previously in default configuration ccache cache depended on state of /usr/$(libexecdir)/misc/gcc-config See bug #640958 where ccache did not notice USE=-pie -> USE=pie switch. - Reasoning about PATH ordering is straightforward: all available binaries (as symlinks) are in /usr/bin. See bug #255695 where PATH ordering changed and bug #626606 where people get confused on what is in /usr/bin/gcc binary. Bug: https://bugs.gentoo.org/626606 Bug: https://bugs.gentoo.org/255695 Bug: https://bugs.gentoo.org/640958 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> .gitignore | 3 - Makefile | 8 +- README | 69 +---- gcc-config | 33 +-- tests/rw-multi-native-configs/test.select | 4 +- .../usr/lib/gcc-config/wrapper | 0 tests/source/test.whitespace | 2 +- wrapper.c | 323 --------------------- 8 files changed, 28 insertions(+), 414 deletions(-) With gcc-config-2 /usr/bin/gcc is still an orphan but at least now it's a symlink to owned file. Should be not as bad. |
In my opinion it’s more an issue than a bug but nonetheless the bin wrapper, copied by the atomic_cp() function (in gcc-config script), should be discoverable by average users. The wrapper for gcc, cc, c++, g++ et cetera, is treated as orphaned by: $ equery belongs /usr/bin/gcc $ portageq owners / /usr/bin/gcc $ qfile /usr/bin/gcc because /usr/bin/gcc isn’t recorded in /var/db/pkg/sys-devel/gcc-${PV}/CONTENTS. A quick ’n dirty test with (a copy of) the CONTENTS file: # gcc_atom="sys-devel/gcc-5.4.0" # print-record() { stat -c "obj $2 $1 %Y" $2; } # print-record $(md5sum /usr/bin/gcc) >> /var/db/pkg/${gcc_atom}/CONTENTS # unset -v gcc_atom # unset -f print-record let equery/portageq/qfile discover the package where /usr/bin/gcc belongs to. To be honest the consequences of this approach are over my head: • Is the white lie that sys-devel/gcc owns /usr/bin/gcc acceptable, even when the latter just wraps the former binary? • Is /var/db/pkg/* checksummed somewhere? • Are there side effects when it comes to re- or unmerging? • … Maybe an einfo message after a profile switch about copied wrappers would help if this issue cannot be solved. But just having not easily identifiable executable binaries in a base directory is a little bit odd. Thank you for your time