Hi, after I installed a second tool chain with crossdev, revdep-rebuild wants to recompile the new generated gcc. Reproducible: Always Steps to Reproduce: 1. Build a tool chain (i686-pc-linux-uclibc) with crossdev 2. run revdep-rebuild -p Actual Results: hive ~ # revdep-rebuild -p Configuring search environment for revdep-rebuild Checking reverse dependencies... Packages containing binaries and libraries broken by a package update will be emerged. Collecting system binaries and libraries... done. (/root/.revdep-rebuild.1_files) Collecting complete LD_LIBRARY_PATH... done. (/root/.revdep-rebuild.2_ldpath) Checking dynamic linking consistency... broken /usr/lib/gcc/i686-pc-linux-uclibc/4.1.2/libgcc_s.so.1 (requires libc.so.0) broken /usr/lib/gcc/i686-pc-linux-uclibc/4.1.2/libstdc++.so.6.0.8 (requires libc.so.0 libm.so.0) done. (/root/.revdep-rebuild.3_rebuild) Assigning files to ebuilds... done. (/root/.revdep-rebuild.4_ebuilds) Evaluating package order... Warning: Failed to resolve package order. Will merge in "random" order! Possible reasons: - An ebuild is no longer in the portage tree. - An ebuild is masked, use /etc/portage/packages.keyword and/or /etc/portage/package.unmask to unmask it ..... done. (/root/.revdep-rebuild.5_order) All prepared. Starting rebuild... emerge --oneshot -p =cross-i686-pc-linux-uclibc/gcc-4.1.2 These are the packages that would be merged, in order: Calculating dependencies | emerge: there are no ebuilds to satisfy "=cross-i686-pc-linux-uclibc/gcc-4.1.2". revdep-rebuild failed to emerge all packages you have the following choices: - if emerge failed during the build, fix the problems and re-run revdep-rebuild or - use -X or --package-names as first argument (trys to rebuild package, not exact ebuild) or - set ACCEPT_KEYWORDS="~<your platform>" and/or /etc/portage/package.unmask (and remove /root/.revdep-rebuild.5_order to be evaluated again) or - modify the above emerge command and run it manually or - compile or unmerge unsatisfied packages manually, remove temporary files and try again (you can edit package/ebuild list first) To remove temporary files, please run: rm /root/.revdep-rebuild*.?_* Expected Results: revdep-rebuild should not care about tool chains, build with crossdev. A possible solution is to add the directory of generated cross tool chain to SEARCH_DIRS_MASK of revdep-rebuild. Of course it would be nice, if revdep-rebuild would realize on it's own, that this is a second tool chain, which it should leave alone.
funny, you get the same answer as when you asked on the mailing list ... revdep-rebuild is broken, not crossdev
(In reply to comment #1) > funny, you get the same answer as when you asked on the mailing list ... > revdep-rebuild is broken, not crossdev Well, I did not state it explicitly as a crossdev bug. I wrote: "Expected Results: revdep-rebuild should not care about tool chains, build with crossdev." So I'm with you (and Mike), that this is a problem of revdep-rebuild. All I'm saying is, that crossdev can get around this by stating the cross-build tool chains as forbidden for revdep-rebuild, by adding their directories to SEARCH_DIRS_MASK of revdep-rebuild. This is in my view a simple solution, until revdep-rebuild is fixed (if ever). To the revdep-rebuild developers: please fix this. Regards, Marc
How is revdep-rebuild broken? It has done exactly what it was supposed to do, which is identify an executible with unsatisfied dynamic links on the system. The solution is SEARCH_DIRS_MASK and the reason that variable exists.
revdep-rebuild should not be analyzing ELFs which are not for the host system
Okay, can I get a pointer to what software/commands I need to use to determine if a particular ELF belongs or doesn't belong to a host system?
well, if you got around to converting revdep-rebuild to scanelf, it'd be much much easier ;) otherwise you'll have to parse the output of `readelf -h` ... in particular, you'll need to filter based on Class: and Machine: ... you'll also have to take into account multilib for valid host Class/Machine combo's, i'd inspect like /lib*/libc.so.*
On the other and, there's an other case for which having crossdev to set it's own SEARCH_DIRS_MASK would be nice. Currently, when you have some crossdev toolchains installed, they can hide some breakages of the host system: - you have "/usr/bin/memprof" which needs "libbfd-2.17.so" (compiled with an old binutils) - your host version is now "/usr/lib/binutils/i686-pc-linux-gnu/2.18/libbfd-2.18.so" - you still have "/usr/lib/binutils/powerpc-gentoo-linux-uclibc/2.17/libbfd-2.17.so" (older binutils) in a crossdev toolchain - revdep-rebuild (at least without the --no-ld-path option) adds "/usr/lib/binutils/powerpc-gentoo-linux-uclibc/2.17/" to its "full LD_LIBRARY_PATH" - because of this path, `ldd` doesn't report that "/usr/bin/memprof" is broken Here, there's not much revdep-rebuild can do alone, but to expect that such paths get masked. Sure, one could also argue that it's this whole "full LD_LIBRARY_PATH" thing which should be blamed (i won't comment on that, i've not really understood its purpose yet), but it's still on crossdev's side that the obvious workaround is (or in toolchain ebuilds maybe).
i dont have a problem with crossdev creating entries to mask /usr/CTARGET/ because those are all binaries native to CTARGET. however, masking the dirs you refer to is incorrect because those should be checked -- they're binaries that run on your host system and need to work.
*** Bug 299346 has been marked as a duplicate of this bug. ***
crossdev-20110310 now masks the sysroot http://git.overlays.gentoo.org/gitweb/?p=proj/crossdev.git;a=commitdiff;h=5ff69347681dee9ce6f76cf91671cdcab56bfe6b
I am more interested in seeing revdep-rebuild just alert that cross-[target]/gcc, etc needs a rebuild than actually seeing it attempt to do so (which sometimes fails). This way I know I'm just going to run `crossdev -t [target]` again just to ensure everything is in order.
Just wanting to pitch in, the new python based revdep-rebuild seems to be confused about crossbuilds in general (or crossdev is broken). valexia ~ # crossdev -S -t arm-pc-linux-gnueabi gawk: cmd. line:8: (FILENAME=- FNR=1) warning: gensub: third argument `' treated as 1 gawk: cmd. line:8: (FILENAME=- FNR=5) warning: gensub: third argument `' treated as 1 gawk: cmd. line:8: (FILENAME=- FNR=11) warning: gensub: third argument `' treated as 1 ------------------------------------------------------------------------------------------------------------------------------------ * crossdev version: 20150716 * Host Portage ARCH: amd64 * Target Portage ARCH: arm * Target System: arm-pc-linux-gnueabi * Stage: 4 (C/C++ compiler) * ABIs: default * binutils: binutils-[stable] * gcc: gcc-[stable] * headers: linux-headers-[stable] * libc: glibc-[stable] * CROSSDEV_OVERLAY: /var/lib/layman/gamerlay * PORT_LOGDIR: /var/log/portage * PORTAGE_CONFIGROOT: * Portage flags: _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - * leaving metadata/layout.conf alone in /var/lib/layman/gamerlay _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - _ - ~ - gawk: cmd. line:8: (FILENAME=- FNR=1) warning: gensub: third argument `' treated as 1 gawk: cmd. line:8: (FILENAME=- FNR=5) warning: gensub: third argument `' treated as 1 gawk: cmd. line:8: (FILENAME=- FNR=11) warning: gensub: third argument `' treated as 1 * Log: /var/log/portage/cross-arm-pc-linux-gnueabi-binutils.log * Emerging cross-binutils ... [ ok ] * Log: /var/log/portage/cross-arm-pc-linux-gnueabi-linux-headers-quick.log * Emerging cross-linux-headers-quick ... [ ok ] * Log: /var/log/portage/cross-arm-pc-linux-gnueabi-glibc-headers.log * Emerging cross-glibc-headers ... [ ok ] * Log: /var/log/portage/cross-arm-pc-linux-gnueabi-gcc-stage1.log * Emerging cross-gcc-stage1 ... [ ok ] * Log: /var/log/portage/cross-arm-pc-linux-gnueabi-linux-headers.log * Emerging cross-linux-headers ... [ ok ] * Log: /var/log/portage/cross-arm-pc-linux-gnueabi-glibc.log * Emerging cross-glibc ... [ ok ] * Log: /var/log/portage/cross-arm-pc-linux-gnueabi-gcc-stage2.log * Emerging cross-gcc-stage2 ... [ ok ] valexia ~ # revdep-rebuild -i * 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 files bugs at: https://bugs.gentoo.org/ * Collecting system binaries and libraries * Checking dynamic linking consistency * Assign files to packages !!! Broken orphaned files: No installed package was found for the following: * /usr/lib64/gcc/arm-pc-linux-gnueabi/4.9.3/libatomic.so.1.1.0 * /usr/lib64/gcc/arm-pc-linux-gnueabi/4.9.3/libstdc++.so.6.0.20 * /usr/lib64/gcc/arm-pc-linux-gnueabi/4.9.3/libasan.so.1.0.0 * /usr/lib64/gcc/arm-pc-linux-gnueabi/4.9.3/libitm.so.1.0.0 * /usr/lib64/gcc/arm-pc-linux-gnueabi/4.9.3/libubsan.so.0.0.0 * /usr/lib64/gcc/arm-pc-linux-gnueabi/4.9.3/libgomp.so.1.0.0 There is nothing to emerge. Exiting. valexia ~ # revdep-rebuild.sh -i * Configuring search environment for revdep-rebuild * Checking reverse dependencies * Packages containing binaries and libraries broken by a package update * will be emerged. * Collecting system binaries and libraries * Generated new 1_files.rr * Collecting complete LD_LIBRARY_PATH * Generated new 2_ldpath.rr * Checking dynamic linking consistency [ 100% ] * Dynamic linking on your system is consistent... All done. valexia ~ # equery belongs /usr/lib64/gcc/arm-pc-linux-gnueabi/4.9.3/libatomic.so.1.1.0 * Searching for /usr/lib64/gcc/arm-pc-linux-gnueabi/4.9.3/libatomic.so.1.1.0 ... valexia ~ # equery files cross-arm-pc-linux-gnueabi/gcc * Searching for gcc in cross-arm-pc-linux-gnueabi ... * Contents of cross-arm-pc-linux-gnueabi/gcc-4.9.3: <snip> /usr/lib/gcc/arm-pc-linux-gnueabi/4.9.3/libatomic.la /usr/lib/gcc/arm-pc-linux-gnueabi/4.9.3/libatomic.so -> libatomic.so.1.1.0 /usr/lib/gcc/arm-pc-linux-gnueabi/4.9.3/libatomic.so.1 -> libatomic.so.1.1.0 /usr/lib/gcc/arm-pc-linux-gnueabi/4.9.3/libatomic.so.1.1.0 valexia ~ # ls -laF /usr/lib lrwxrwxrwx 1 root root 5 11 nov 22:27 /usr/lib -> lib64/ While granted, /usr/lib is a symlink, that still shouldn't confuse revdep (and equery for that matter, as belongs also is equally confused.
*** Bug 571088 has been marked as a duplicate of this bug. ***
*** Bug 687760 has been marked as a duplicate of this bug. ***
*** Bug 608934 has been marked as a duplicate of this bug. ***
*** Bug 627438 has been marked as a duplicate of this bug. ***
The content of /etc/revdep-rebuild/05cross-aarch64-unknown-linux-gnu is SEARCH_DIRS_MASK=/usr/aarch64-unknown-linux-gnu This is ignored because it is not the value of SEARCH_DIRS_MASK is not enclosed in double quotes. Thus, it should become SEARCH_DIRS_MASK="/usr/aarch64-unknown-linux-gnu" I don't know which program created /etc/revdep-rebuild/05cross-aarch64-unknown-linux-gnu
Typo: it is not the value of SEARCH_DIRS_MASK -> SEARCH_DIRS_MASK
Is it fixed now?
Cross gcc is still broken: revdep-rebuild -d -ip * 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/ main(), _libs_to_check = set() all_masks: /lib/modules /lib32/modules /lib64/modules /usr/powerpc-g2.20-linux-gnu /usr/powerpc-softfloat_4.9.3-linux-gnu libjava.so libjvm.so libodbc.so libodbcinst.so * Collecting system binaries and libraries analyse(), bin directories: /bin /lib /lib64 /opt/bin /sbin /usr/bin /usr/lib /usr/lib/llvm/8/bin /usr/lib64 /usr/libexec /usr/local/bin /usr/local/sbin /usr/sbin analyse(), lib directories: /bin /lib /lib32 /lib64 /sbin /usr/bin /usr/lib /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0 /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/32 /usr/lib/llvm/8/lib64 /usr/lib32 /usr/lib64 /usr/libexec /usr/local/lib /usr/local/lib32 /usr/local/lib64 /usr/sbin analyse(), masked directories: /lib/modules /lib32/modules /lib64/modules /usr/powerpc-g2.20-linux-gnu /usr/powerpc-softfloat_4.9.3-linux-gnu analyse(), masked files: libjava.so libjvm.so libodbc.so libodbcinst.so time to complete task: 3 milliseconds * Collecting dynamic linking informations Exception collecting libraries: [Errno 2] No such file or directory: b'/usr/lib32' Exception collecting libraries: [Errno 2] No such file or directory: b'/lib32' time to complete task: 5414 milliseconds analyse(), Found 5981 libraries (+1297 symlinks) and 5813 binaries * Scanning files scan(), scanelf params = ['-BF', '%F;%f;%S;%n;%M'], # files: 6014 scan(), final output length: 4720 scan_files(); total time to get scanelf data is 294 milliseconds scan_files(); total filenames found: 4720 in 197 milliseconds * Checking dynamic linking consistency analyse(), Searching for 6014 libs, bins within 7278 libraries and links LibCheck.__init__(), new searchlibs: ['32', '64'] LibCheck.search(), Checking for broken 32 bit libs LibCheck.search(); FOUND: 32bit, ld.so.1, /usr/lib/gcc/powerpc-g2.20-linux-gnu/4.9.3/libasan.so.1.0.0 LibCheck.search(); FOUND: 32bit, ld.so.1, /usr/lib/gcc/powerpc-softfloat_4.9.3-linux-gnu/4.9.3/libasan.so.1.0.0 LibCheck.search(); FOUND: 32bit, ld.so.1, /usr/lib/gcc/powerpc-g2.20-linux-gnu/4.9.3/libstdc++.so.6.0.20 LibCheck.search(); FOUND: 32bit, ld.so.1, /usr/lib/gcc/powerpc-softfloat_4.9.3-linux-gnu/4.9.3/libstdc++.so.6.0.20 LibCheck.search(), Checking for broken 64 bit libs LibCheck.search(); Total found: 1 libs, 4 files in 217 milliseconds * Broken files that require: ld.so.1 (32 bits) * /usr/lib/gcc/powerpc-g2.20-linux-gnu/4.9.3/libasan.so.1.0.0 * /usr/lib/gcc/powerpc-g2.20-linux-gnu/4.9.3/libstdc++.so.6.0.20 * /usr/lib/gcc/powerpc-softfloat_4.9.3-linux-gnu/4.9.3/libasan.so.1.0.0 * /usr/lib/gcc/powerpc-softfloat_4.9.3-linux-gnu/4.9.3/libstdc++.so.6.0.20 LibCheck.process_results(); total filepaths found: 4 in 0 milliseconds * Assign files to packages * /usr/lib/gcc/powerpc-g2.20-linux-gnu/4.9.3/libasan.so.1.0.0 -> cross-powerpc-g2.20-linux-gnu/gcc-4.9.3-r2 * /usr/lib/gcc/powerpc-g2.20-linux-gnu/4.9.3/libstdc++.so.6.0.20 -> cross-powerpc-g2.20-linux-gnu/gcc-4.9.3-r2 * /usr/lib/gcc/powerpc-softfloat_4.9.3-linux-gnu/4.9.3/libasan.so.1.0.0 -> cross-powerpc-softfloat_4.9.3-linux-gnu/gcc-4.9.3-r2 * /usr/lib/gcc/powerpc-softfloat_4.9.3-linux-gnu/4.9.3/libstdc++.so.6.0.20 -> cross-powerpc-softfloat_4.9.3-linux-gnu/gcc-4.9.3-r2 assign_packages(); assigned 2 packages, 0 orphans in 1405 milliseconds
Since https://gitweb.gentoo.org/proj/crossdev.git/commit/?id=5295ec128ea4e588322240c97a650a4394508e2e, it's quoted.
