Looks like google perftools got two version bumps recently.
Both are breaking library abi, and with 2.0 and forward, the library actually changes name. Perhaps it would be wiser to introduce 2.0 as a new package (library includes being different and all)? There is somewhat backwards compatibility, though.
*** Bug 411113 has been marked as a duplicate of this bug. ***
Created attachment 316615 [details]
Added static-libs use flag and fixed URLs.
Created attachment 316617 [details]
Added static-libs use flag, fixed URLs, renamed, and blocked google-perftools.
I've done only very limited testing (they install), but nevertheless those two ebuilds I attached seem to work for amd64.
Note that I went ahead and added support for USE=static-libs; if I should have filed a separate bug for that, let me know.
Okay working on it finally. I'm not really convinced about static-libs; reason being that the tcmalloc library brings in so many things (pthreads, libstdc++, ...) that if it's mixed in the wrong way it's more than likely to explode in your face.
So unless you have a specific use case for using the static libs I'd prefer not having them _at all_.
Also, the includes are the same (at least in name) so for now I'll keep it the same package. I'll decide later whether to pkgmove it when I unmask version 2, or when we mark that stable, I don't want to use blockers, and this is just a name change, it's not a fork or something like that that warrant the co-existence of two packages.
As you can tell from what I just said, I intend to mask version 2.0 until I can test it out on the tinderbox, with all its reverse dependencies — it might take a while since some dependencies are not currently building between glibc and gcc.
FWIW the whole "changed includes" is that they decided to get rid of "google" in the name wherever possible, but for the moment they keep the old paths around — the problem is going to be in version 2.1 or whenever they'll drop the old includes.