[LLVMdev] LLVM shared library naming

[Owen Shepherd]

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
On 13 Apr 2013 18:51, "Óscar Fuentes" <ofv at wanadoo.es> wrote:

> Michael Young <mikado_282 at 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.)
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130413/333cc39c/attachment.html>