LLVM shared library naming

When I configure and build LLVM (on Linux - Ubuntu 12.04) with the
"--enable-shared" option, I get a shared library named "libLLVM-3.2svn.so",
regardless of whether I build from sources pulled from the repository
(even when pulling from "tags/RELEASE_32/final") or from the release tarballs.
Is this correct behavior?

Even if this odd naming is what is expected, why is this artifact in the name
of a shared library? Is this "wart" in the internal name, too? Are there any
recommendations that suggest renaming this library or linking against this
library in a way that doesn't maintain or require this wierdness?

I apologize if I seem overly critical - I just don't understand the rationale
for it, and it seems that the naming is misleading, if not technically
problematic. I really am grateful to the developers of LLVM, and I'm enjoying
learning it. As always, feel free to point me to documentation or a relevant
mailing list discussion - I looked, but didn't see anything.

Thanks,
Michael

Michael Young <mikado_282@hotmail.com> writes:

When I configure and build LLVM (on Linux - Ubuntu 12.04) with the
"--enable-shared" option, I get a shared library named "libLLVM-3.2svn.so",
regardless of whether I build from sources pulled from the repository
(even when pulling from "tags/RELEASE_32/final") or from the release tarballs.
Is this correct behavior?

The `svn' part shouldn't be on the library compiled with the released tarball.

Even if this odd naming is what is expected, why is this artifact in the name
of a shared library? Is this "wart" in the internal name, too? Are there any
recommendations that suggest renaming this library or linking against this
library in a way that doesn't maintain or require this wierdness?

What's the artifact? What's the internal name?

BTW, how are you building LLVM (cmake or configure&&make) ?

I apologize if I seem overly critical - I just don't understand the rationale
for it, and it seems that the naming is misleading, if not technically
problematic.

Having version numbers in the shared library name is standard practice
in Linux (and, possibly, other Unixes.) It seems that LLVM does it in
reverse, though. It should be libLLVM(-svn).so.3.2 (I'm not sure about
where the -svn part should be.)

libLLVM.so.3.2 wouldn’t work because LLVM 3.2 is binary incompatible with 3.1/3.0

Putting the version in the name is standard practice for libraries with no stable ABI or API. See for example Boost