rebuild all dependencies for an atom... but how?

[utux]

Hi

I'm trying to solve some weird compile errors which I suspect to have to do with switching from gcc 4 to gcc 5. But I believe that by now, all or at least virtually all of my 1400 packages have been reemerged at least twice so I don't want to try yet another run of 'revdep-rebuild --library 'libstdc++.so.6' -- --exclude gcc' (which by the way doesn't exclude any gcc, it reemerges all gcc versions despite...)

So what I want is to single out one problematic atom, remerge all of its deep dependencies, and then see if there's any improvement. But I can't figure out how to accomplish this...

emerge -o =media-sound/ardour-5.10 fails because the dependencies are already installed and I can't find a way to tell it to reemerge unconditionally.

browsing forums, 'emerge -ea =media-sound/ardour-5.10' is suggested to reemerge an atom and all of its dependencies, but I think --emptytree is very faulty or at the very least trolling me; it reports for example 500(!) dependencies for ardour-5. Or to give a better example, if I try 'emerge -ea glibc' it reports 400 dependencies for glibc... including ridiculous stuff like dev-qt/qtchooser, virtual/mysql and net-print/cups...
Really...? Glibc depends on cups? I think --emptytree has cause and effect reversed...

So... basically, my question is twofold... how can I reemerge all dependencies for one package, and secondly, what is wrong with --emptytree (or my use of it) ? Now it is effectively rather unusable...

regards
maarten

[eccerr0r]

Do you mean dependencies (what a package needs) or reverse dependencies (what packages needs it)?

I can see glibc not really needing as many packages as ardour, but basically all packages need glibc. However glibc does have some "dependencies" in which it needs certain versions of gcc, and gcc's dependencies are now glibc's dependencies.. 400 sounds reasonable.

Revdep-rebuild is indeed the tool to fix packages that need a certain file, and should be sufficient to locate packages that require it.

Perhaps the question that needs to be asked: what is the exact error you're trying to solve?
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[utux]

[NeddySeagoon]

utux,

Lets see if you need a fishing howto or not. Show us a build log or two so we can see what fails and how it fails.
Here, 'revdep-rebuild --library 'libstdc++.so.6 -- --exclude gcc' does what it claims. gcc is not rebuilt.

The gentoo repository does not specify dependences completely. Things in the @system set are assumed to be installed.
The only time dependencies on gcc and glibc are give in ebuilds are when versions are required.
ebuild authors are allowed to assume that @system is always available.

Without this simplifying assumption, it would never be possible to break circular dependencies.
e.g. gcc and glibc really do depend on each other.

A consequence of that is that its not possible to calculate the entire deptree of any package.
I'm unsure if --emptytree includes @system or not.
Notice that

[The Doctor]

emerge -e <atom> is what you are looking for.

This will rebuild every dependency so patience is required. I really do mean everything. It will basically rebuild your entire system.

Glibc needs about 142 packages. Ardour needs about 352. This is all very use flag dependent of course. My system was intended to be minimal. 400 is not unreasonable.

EDIT: Actually, follow NeddySeagoon's suggestion. Our posts collided and his advise is much better than mine. But to clearify, @system is included in --emptytree. It rebuilds in a more or less bottom up approach but not perfectly.
_________________
First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.

[utux]

[utux]

[The Doctor]

[asturm]

No, GCC-5 ABI incompatibility is still the problem.

[utux]

[utux]

[asturm]

Well, if the package rebuilds kept going and you did not check package failures happening in between, such errors may still occur from time to time. But maybe cairo is just the last package on that list, who knows. These kind of ABI errors always look the same though so keep a picture of it in your brain and take future build issues on your system with a grain of salt. If you revisit your forum thread with the build.log, most of the time someone will be able to help you.

[utux]

[asturm]

[utux]

[utux]

[The Doctor]

Looks like changing between major gcc versions is causing the problem. I suggest reading Upgrading GCC would be helpful to you.
_________________
First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.

[Tony0945]

As Asturm hinted above: https://gcc.gnu.org/gcc-5/changes.html#libstdcxx

It looks to me that you are missing a lot of symbols involving the new ABI from various packages.
Where I upgraded from gcc 4 to gcc 5 (and again when going from 5 to 6 and 6 to 7), the last step was "emerge -e @world --keep-going" and I did have to resume, at least twice.
I know the wiki says you don't have to. I did it anyway, being old school. You may have to override one or more pacjages.

[utux]

[asturm]

[utux]

[The Doctor]

BTW, I hope you have discovered the --oneshot option (-1 for short) to prevent these packages from ending up in world. That will give you all kinds of problems down the road.
_________________
First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.

[utux]

[Tony0945]

I'm not understanding why you are emerging every dependency instead of just the libraries that explicitly fail.
Granted, the error messages can be pretty cryptic. I latched onto the ABI because of ASturm's hint, but it's also possible that you need certain useflags set in that dependent package. The ebuild should indicate that, but (clutching pearls) sometimes ebuilds have bugs! A missing reference in a library sure sounds like you need another useflag or it's the ABI. When I went from 6.3 to 7.1 I had to change the /etc/env.d package for one package to set the flag for the std-gnu-98 because it had fatal errors without that (stricter checking in the new ABI).

Don't waste your energy rebuilding what's linking OK and concentrate on the specific error messages. I'm sorry that I can't help more but I don't run ardour or kde.

[utux]