Clarification on stable release shared object ABI compatibility

Hi,

One issue that has come up in the process of merging patches to the 3.5
branch is whether or not it is OK to add new symbols to 3.5.1 that
weren't included in 3.5.0.

My understanding is that if new symbols are added to 3.5.1, then
programs built against 3.5.0 will still be able to link against 3.5.1,
however programs built against 3.5.1 will fail to link against 3.5.0.

My initial feeling is that we should not allow new symbols in 3.5.1,
so that programs can downgrade from 3.5.1 to 3.5.0 without rebuilding,
but I wanted to get more opinions on this.

Thanks,
Tom

Can you clarify what you mean by new symbols? Adding a private method to a C++ class in a public header can add new symbols visible at the DSO level.

LLVM doesn’t have a curated C++ interface, so pretty much any old patch that adds functionality to a relatively internal class like AsmPrinter will introduce new symbols.

Personally, I don’t see any value in supporting downgrading from 3.5.1 so I would go ahead and allow new symbols, regardless of whether they look public or private.

I don't have a problem with adding new symbols (although in C++ it's important to make sure that we don't add new vtable entries). As long as programs built with LLVM x.y.z work with LLVM x.y.z+n then there's no issue for me. Most packaging systems can express a dependency like this.

David

Can you clarify what you mean by new symbols? Adding a private method to a
C++ class in a public header can add new symbols visible at the DSO level.

By new symbols, I just mean public symbols that an external application or
library may possibly use.

-Tom