Aha got it, thanks! Like you said it’s not pretty but it works, and somewhat better than the abomination they came up with instead, which involved building only the minimal part that depended on the new Lua 5.2 as shared library, then making fake shared libraries for all remaining unsatisfied symbols referenced from it to trick the linker, and compiling them in statically instead like they used to do before. Hard to explain, don’t ask me why they did it... :-/

Edit: there is one pretty glaring downside to this approach though, which is that both the component we need to patch up with renamed symbols and the liblua.a are also used in other places, so they would either have to be built differently depending on the application, or we would have to maintain multiple versions of the same 5.0 liblua.a and change the build config/detect logic, for even more confusion and ugliness >_<

Introduce the project- nay, the organization-wide mangling scheme! Every symbol is now required to have the library's version name in its name, may as well throw in some namespaces there too. Then maintain some sort of metainfo of what part is requiring what versions, and what project is providing what versions, and... and well, at this stage you're kinda reinventing the package management, but at least you don't need a custom linker, which is a good thing, right?

The not-so-funny part is that it would probably be about the same effort to do that compared to convincing everybody to use shared linking for these kinds of things >_<