Bugzilla Bug 182601

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.