3 ms·
It actually should still work, since fedora38 includes the llvm15 versioned libs. The only way to make this break is if something is loading random unversioned
by DannyBee 4y ago
It actually should still work, since fedora38 includes the llvm15 versioned libs.
The only way to make this break is if something is loading random unversioned solibs or whatever the latest one it can find is, and expecting this to work forever.
If it actually used a versioned solib, it would get llvm 15
just like it did before.
This is the whole point of versioned solibs.
- olliej 4y agoVersioning does not solve the problem. The aligned allocation operators have existed since llvm 8.x. The problem is not that the aligned allocation APIs are new. The problem is that TCMalloc is only partially replacing the global allocation APIs, it's just taken until this year for that bug to be exposed. What has happened is presumably some part of the OS has updated its target C++ version so is now using the aligned allocators, which exposes the gap in TCMalloc. I'm not sure if the spec explicitly allows an aligned allocation to be fed into an unaligned operator delete, but it seems like implementations do, so that's probably why adopting aligned operator new wouldn't be seen as an ABI break.
- DannyBee 3y agoThanks. This at least makes more sense than what I read, and explains what might actually have happened :)