Re: [gentoo-dev] impending c++11 clusterfuck?

[Greg Turner]

Actually, come to think of it, there's an even dumber, easier
approach: just have some "is it c++" heuristics like, does it
dynamically link to a libstdc++?  Did it inhert qt.eclass?  etc.  So
we have a boolean "is it probably a c++ package" heuristic boolean (or
maybe a vector of per-compiler maybe booleans).  It'd be ok to have
some false positives, and pretty bad to have false negatives.

Now for each "probably c++" package merged, just store away the global
(per-compiler?) c++abi value (for false positives this would be
meaningless noise).

Now when we eselect c++abi set some-new-value, we could just take all
those maybe meaningless -- but presumptively not
meaningful-but-incorrect -- values in the vdb, and queue up rebuild
nags for all the ones that don't match.
-gmt

Greg Turner
gmt@×××××××.net


On Mon, Nov 30, 2015 at 2:16 AM, Greg Turner <gmt@×××××××.net> wrote:
> On Mon, Nov 30, 2015 at 12:07 AM, Anthony G. Basile <blueness@g.o> wrote:
>> If we record enough information at build time (eg. gcc version or
>> libcxx/clang) then we can build tools that intelligently predict if
>> there's an abi incompatibility.
>
> Yes, exactly the type of thing I'm thinking of. As you go on to note,
>
>> Unfortunately gcc doesn't bump soname
>> and/or version-info when it changes c++11 abi.
>
> So, maybe kludge #1 we require is some kind of made-up section header
> injected into object files... let's say, hypothetically, a tuple from
> the cartesian cross-product of something vaguely like:
>
> <
> compiler={gcc34,gcc47,gcc49,gcc52,clang}
> arch={$(< profiles/arch.list)} or maybe {(gnu target triplets)}
> abi={c++03,c++11,gnu++11,plain-ol'-c}
>>
>
> i.e.: gcc52-amd64-gnu++11. Probably the arch is redundant -- hell,
> maybe the compiler too -- and could be dropped... but you get the
> idea.
>
> So then, some agent digs this out from executables, and, like you say,
> caches it in the vdb somewhere.
>
> Meanwhile, suppose there's a global eselect c++abi setting.  Once it's
> changed, we could just zip through the vdb and, say, "maybe some of
> these are false positives, but, to be safe, here's a nag to rebuild
> these so-and-so packages, which seem to have been built against some
> c++ abi other than the current one."
>
> No depgraph required, easy to implement magically-fix-it.sh.  Might
> spin its wheels a bit but how often would you change this setting?
> Almost never...
>
> Well just thinking out loud, I probably have horrible thinkos above,
> but ya gotta start somewhere...
>
> -gmt
>
> Greg Turner
> gmt@×××××××.net