Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 692844 - sys-devel/crossdev should add /usr/lib64/gcc/aarch64-unknown-linux-gnu to SEARCH_DIRS_MASK in /etc/revdep-rebuild/05cross-aarch64-unknown-linux-gnu
Summary: sys-devel/crossdev should add /usr/lib64/gcc/aarch64-unknown-linux-gnu to SEA...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: Gentoo Crossdev team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-08-25 07:41 UTC by anonymous
Modified: 2019-08-25 11:50 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description anonymous 2019-08-25 07:41:00 UTC
Currently, SEARCH_DIRS_MASK contains only /usr/aarch64-unknown-linux-gnu in /etc/revdep-rebuild/05cross-aarch64-unknown-linux-gnu. It also needs to contain /usr/lib64/gcc/aarch64-unknown-linux-gnu.

Reproducible: Always

Actual Results:  
~> sudo revdep-rebuild -pv
Password:
 * 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/
 * Found a valid cache, skipping collecting phase
 * Scanning files
 * Checking dynamic linking consistency
 * Broken files that require: ld-linux-aarch64.so.1 (64 bits)
        * /usr/lib64/gcc/aarch64-unknown-linux-gnu/8.3.0/libasan.so.5.0.0
        * /usr/lib64/gcc/aarch64-unknown-linux-gnu/8.3.0/libatomic.so.1.2.0
        * /usr/lib64/gcc/aarch64-unknown-linux-gnu/8.3.0/libgfortran.so.5.0.0
        * /usr/lib64/gcc/aarch64-unknown-linux-gnu/8.3.0/libgomp.so.1.0.0
        * /usr/lib64/gcc/aarch64-unknown-linux-gnu/8.3.0/libitm.so.1.0.0
        * /usr/lib64/gcc/aarch64-unknown-linux-gnu/8.3.0/liblsan.so.0.0.0
        * /usr/lib64/gcc/aarch64-unknown-linux-gnu/8.3.0/libstdc++.so.6.0.25
        * /usr/lib64/gcc/aarch64-unknown-linux-gnu/8.3.0/libtsan.so.0.0.0
        * /usr/lib64/gcc/aarch64-unknown-linux-gnu/8.3.0/libubsan.so.1.0.0
 * Assign files to packages
        * /usr/lib64/gcc/aarch64-unknown-linux-gnu/8.3.0/libstdc++.so.6.0.25 -> cross-aarch64-unknown-linux-gnu/gcc-8.3.0-r1
        * /usr/lib64/gcc/aarch64-unknown-linux-gnu/8.3.0/liblsan.so.0.0.0 -> cross-aarch64-unknown-linux-gnu/gcc-8.3.0-r1
        * /usr/lib64/gcc/aarch64-unknown-linux-gnu/8.3.0/libasan.so.5.0.0 -> cross-aarch64-unknown-linux-gnu/gcc-8.3.0-r1
        * /usr/lib64/gcc/aarch64-unknown-linux-gnu/8.3.0/libubsan.so.1.0.0 -> cross-aarch64-unknown-linux-gnu/gcc-8.3.0-r1
        * /usr/lib64/gcc/aarch64-unknown-linux-gnu/8.3.0/libtsan.so.0.0.0 -> cross-aarch64-unknown-linux-gnu/gcc-8.3.0-r1
        * /usr/lib64/gcc/aarch64-unknown-linux-gnu/8.3.0/libgfortran.so.5.0.0 -> cross-aarch64-unknown-linux-gnu/gcc-8.3.0-r1
        * /usr/lib64/gcc/aarch64-unknown-linux-gnu/8.3.0/libgomp.so.1.0.0 -> cross-aarch64-unknown-linux-gnu/gcc-8.3.0-r1
        * /usr/lib64/gcc/aarch64-unknown-linux-gnu/8.3.0/libitm.so.1.0.0 -> cross-aarch64-unknown-linux-gnu/gcc-8.3.0-r1
        * /usr/lib64/gcc/aarch64-unknown-linux-gnu/8.3.0/libatomic.so.1.2.0 -> cross-aarch64-unknown-linux-gnu/gcc-8.3.0-r1

emerge  --pretend --verbose --oneshot --complete-graph=y cross-aarch64-unknown-linux-gnu/gcc:8.3.0
[ebuild   R   ] cross-aarch64-unknown-linux-gnu/gcc-8.3.0-r1  USE="cxx fortran nls nptl openmp pch pie sanitize ssp (-altivec) -debug -doc (-fixed-point) -go -graphite -hardened -jit -libssp -mpx -multilib -objc -objc++ -objc-gc -pgo -systemtap -test -vanilla -vtv"

Expected Results:  
revdep-rebuild shouldn't infinitely keep trying to rebuild cross-aarch64-unknown-linux-gnu/gcc
Comment 1 Sergei Trofimovich (RETIRED) gentoo-dev 2019-08-25 08:39:48 UTC
I think that makes sense. Today that line is populated by crossdev. toolchain.eclass might be slightly better place.
Comment 2 Larry the Git Cow gentoo-dev 2019-08-25 09:38:22 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/proj/crossdev.git/commit/?id=5295ec128ea4e588322240c97a650a4394508e2e

commit 5295ec128ea4e588322240c97a650a4394508e2e
Author:     Sergei Trofimovich <slyfox@gentoo.org>
AuthorDate: 2019-08-25 09:36:33 +0000
Commit:     Sergei Trofimovich <slyfox@gentoo.org>
CommitDate: 2019-08-25 09:37:31 +0000

    crossdev: add a comment into revdep-rebuild entry where is comes from.
    
    Bug: https://bugs.gentoo.org/692844
    Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

 crossdev | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)
Comment 3 Larry the Git Cow gentoo-dev 2019-08-25 09:40:25 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=35e71fcd352e9113c55447b66f6a93e164839dd7

commit 35e71fcd352e9113c55447b66f6a93e164839dd7
Author:     Sergei Trofimovich <slyfox@gentoo.org>
AuthorDate: 2019-08-25 09:23:54 +0000
Commit:     Sergei Trofimovich <slyfox@gentoo.org>
CommitDate: 2019-08-25 09:40:18 +0000

    eclass/toolchain.eclass: mask LIBPATH for cross-case, bug #692844
    
    /usr/lib/gcc/${CTARGET}/${GCC_CONFIG_VER} contains libraries
    destined to be used by ${CTARGET}. revdep-rebuild complains
    about missing dependencies against them as we don't populate
    LDPATH (or anything else) for them.
    
    The change populates /etc/revdep-rebuild/05cross-${CTARGET}-${GCC_CONFIG_VER}
    with a single entry:
        SEARCH_DIRS_MASK="/usr/lib/gcc/${CTARGET}/${GCC_CONFIG_VER}"
    
    crossdev will still own root's SEARCH_DIRS_MASK="/usr/${CTARGET}".
    
    Reported-by: crocket
    Closes: https://bugs.gentoo.org/692844
    Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

 eclass/toolchain.eclass | 15 +++++++++++++++
 1 file changed, 15 insertions(+)
Comment 4 anonymous 2019-08-25 11:13:03 UTC
Where is toolchain.eclass used?
Comment 5 Sergei Trofimovich (RETIRED) gentoo-dev 2019-08-25 11:50:52 UTC
(In reply to crocket from comment #4)
> Where is toolchain.eclass used?

Look at any gcc ebuild: https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-devel/gcc/gcc-9.2.0.ebuild#n8