On Mon, Nov 30, 2015 at 12:07 AM, Anthony G. Basile <bluen...@gentoo.org> 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
g...@be-evil.net
