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 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.)
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>