Bug 606094 – revdep-rebuild confused by SYMLINK_LIB=yes and flags orphaned files in sys-devel/gcc

• Product: Gentoo Linux
• Status: UNCONFIRMED ---

[Description Toralf Förster 2017-01-17 14:36:22 UTC]

When I switch at a fresh new tinderbox image from installed GCC from stage3 to the freshly emerged (unstable) GCC, then revdep-rebuild always remarks the following :


tinderbox@mr-fox ~ $ cat run/desktop-unstable_20170117-114911/tmp/task.log 
 * Switching native-compiler to x86_64-pc-linux-gnu-5.4.0 ...>>> Regenerating /etc/ld.so.cache...
 [ ok ]

 * If you intend to use the gcc from the new profile in an already
 * running shell, please remember to do:

 *   . /etc/profile

 * This is the new python coded version
 * Please report any bugs found using it.
 * The original revdep-rebuild script is installed as revdep-rebuild.sh
 * Please file bugs at: https://bugs.gentoo.org/
 * Collecting system binaries and libraries
 * Checking dynamic linking consistency
 * Assign files to packages

 !!! Dependant orphaned files: No installed package was found for the following:
        * /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.4/32/libubsan.so.0.0.0
        * /usr/lib64/gcc/x86_64-pc-linux-gnu/5.4.0/plugin/libcc1plugin.so.0.0.0
        * /usr/lib64/gcc/x86_64-pc-linux-gnu/5.4.0/32/libubsan.so.0.0.0
        * /usr/lib64/gcc/x86_64-pc-linux-gnu/5.4.0/liblsan.so.0.0.0
        * /usr/lib64/gcc/x86_64-pc-linux-gnu/5.4.0/32/libasan.so.2.0.0
        * /usr/lib64/gcc/x86_64-pc-linux-gnu/5.4.0/libtsan.so.0.0.0
        * /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.4/libubsan.so.0.0.0
        * /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.4/libtsan.so.0.0.0
        * /usr/lib64/gcc/x86_64-pc-linux-gnu/5.4.0/libcc1.so.0.0.0
        * /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.4/libasan.so.1.0.0
        * /usr/lib64/gcc/x86_64-pc-linux-gnu/5.4.0/libasan.so.2.0.0
        * /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.4/liblsan.so.0.0.0
        * /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.4/32/libasan.so.1.0.0
        * /usr/lib64/gcc/x86_64-pc-linux-gnu/5.4.0/libubsan.so.0.0.0

emerge --exclude gcc --oneshot --complete-graph=y sys-libs/ncurses:0/6 sys-devel/gettext:0 app-text/openjade:0 sys-libs/db:6.0 dev-libs/gmp:0/10.4 dev-libs/elfutils:0 dev-util/gperf:0 app-text/opensp:0 sys-libs/db:5.3 sys-apps/groff:0 dev-libs/libpcre:3

These are the packages that would be merged, in reverse order:





I do wonder, why those files are orphaned ?

[Comment 1 Toralf Förster 2017-01-17 14:36:57 UTC]

AH - and this is a type, or ? : "Dependant"

[Comment 2 SpanKY 2017-02-15 08:27:47 UTC]

where exactly are you getting that report ?  gcc doesn't generate it.

my guess is you have a SYMLINK_LIB=yes system and you're getting a mismatch in paths due to gcc installing into /usr/lib/gcc/.

[Comment 3 Toralf Förster 2017-02-15 08:48:37 UTC]

(In reply to SpanKY from comment #2)
gcc-config --nocolor
outputs this AFAICT

[Comment 4 Toralf Förster 2017-02-15 08:48:58 UTC]

(In reply to Toralf Förster from comment #3)
$> gcc-config --nocolor <new version>
I meant

[Comment 5 SpanKY 2017-02-15 09:03:42 UTC]

(In reply to Toralf Förster from comment #4)

err, i don't think so.  i don't recall ever writing that kind of message, or having gcc-config do orphan file detection (it has no reason to).  grepping its files shows no hits either.

gcc-config shows the first few lines of that output, but it stops at the ". /etc/profile" line.  everything after that is not gcc-config.

if revdep-rebuild is confused by SYMLINK_LIB=yes, then it's not really a problem with gcc.

[Comment 6 Toralf Förster 2017-02-15 13:01:18 UTC]

(In reply to SpanKY from comment #5)
indeed, it comes from :

%revdep-rebuild --ignore --library libstdc++.so.6 -- --exclude gcc

which has this string:

revdep_rebuild/rebuild.py: yellow('This is the new python coded version'))

[Comment 7 SpanKY 2017-02-15 15:39:00 UTC]

prob just sit on it until we kill SYMLINK_LIB=yes