Provide llvm-libs-svn-compat package

[kerberizer]

Apparently, some packages ship binaries linked to specific libLLVM.so version. E.g. freshclam from clamav is currently broken:

/usr/bin/freshclam: error while loading shared libraries: libLLVM-3.9.so: cannot open shared object file: No such file or directory

Although the users can rebuild those packages, it might be more convenient if we just provided some kind of llvm-libs-svn-compat package, which would bundle the versioned LLVM library files from the official packages in extra (llvm-libs cannot directly coexist with llvm-libs-svn because of the overlapping non-versioned files).

On a side note, in llvm-libs-svn we should probably provide a /usr/lib/libLLVM.so symlink, which for some reason doesn't seem to be created automatically (any more).

[LW-archlinux]

Lord Heavy's llvm-libs-svn doesn't conflict with llvm-libs , if his method works for aur llvm-svn there's no need for a compat pacakge.

PKGBUILD : http://pkgbuild.com/~lcarlier/mesa-git/sources/llvm-svn/ top link for his repo: http://pkgbuild.com/~lcarlier/mesa-git/

[kerberizer]

Lord Heavy's llvm-libs-svn doesn't conflict with llvm-libs , if his method works for aur llvm-svn there's no need for a compat pacakge.

Thanks, Lone_Wolf! Indeed, it boils down to which version of the library will the generic name, libFOO.so, point to. By omitting the generic names (libLLVM.so, libLTO.so, LLVMgold.so, etc.) from the -libs-svn packages, it's left to the official packages from extra to take that name. But I'm still hesitating: the people who use llvm-svn--especially for development--might actually want that generic name to be exactly the -svn version and to have a -compat package only for those packages that are linked to the version from extra. Not to mention that libraries like the gold plugin, LLVMgold.so, only install as a generic name. In fact, I'm not quite sure in what cases the linking is performed directly to libLLVM.so.

Edit 2017-03-18: OK, I read again the shared libs howto and cleared a little bit my own confusion.

[LW-archlinux]

looked further into it and i think the problem may be an upstream issue.

llvm doesn't seem to have a mechanism to allow different versions to coexist. Rephrased : If llvm does have such a mechanism neither archlinux devs nor mesa devs are aware of it. debian appears to have packages for a dozen llvm versions, might be useful to check how they do it.

the llvm-libs package uses a hack to allow the different versions of llvm libraries needed at runtime to be installed together. For the gold linker that hack still allows only one version.

As a temporary solution a -compat package using the llvm-libs hack does seem a viable option.

[kerberizer]

Here's one possible solution: let's imagine that we keep the current packages as they are, but also introduce a new one, say llvm-libs-lite-svn, which will include only the versioned libs from the current llvm-libs-svn and thus won't conflict with llvm-libs from extra. In that way, the people who need the very latest libLLVM (possibly also libLTO) will be able to install them, while at the same time keeping everything else LLVM-related "stock"--that is, from the official repositories.

Obviously, those who also need the unversioned libs (mainly LLVMgold.so, I guess) will have to use the "ordinary" llvm-libs-svn and therefore won't be able to install llvm-libs from extra. But for them, we could still provide llvm-libs-compat-svn, which would include only the versioned libs from the "stock" llvm-libs, so it's kind of the opposite to llvm-libs-lite-svn.

Here's a brief summary, in case the above sounded confusing:

• llvm-libs: the "stock" package from extra, containing both the versioned and unversioned libraries of the latest LLVM release (currently 3.9);
• llvm-libs-svn: our package, as we have it now, containing both the versioned and unversioned libraries of the LLVM svn trunk (currently 5.0.0svn);
• llvm-libs-lite-svn: contains only the versioned libraries from 5.0.0svn;
• llvm-libs-compat-svn: contains only the versioned libraries from 3.9.

So, the users have the following choices:

• use only llvm-libs: will have access only to the 3.9 libs;
• use only llvm-libs-svn: will have access only to the 5.0.0svn libs;
• use llvm-libs + llvm-libs-lite-svn: will have access to all 3.9 libs + the versioned 5.0.0svn ones;
• use llvm-libs-svn + llvm-libs-compat-svn: will have access to all 5.0.0svn libs + the versioned 3.9 ones.

This doesn't cover all possible use cases, but I hope that it'll be able to cover most. What do you think, guys? Feel free to comment here or in https://aur.archlinux.org/pkgbase/llvm-svn/.

[LW-archlinux]

looking at llvm-libs-svn , there are 4 files without a version :

BugpointPasses.so, LLVMgold.so , LLVMhello.so and a symlink in bfd-plugins/LLVMgold.so .

Having 3 packages feels a bit to complicated, how about using 2 packages :

llvm-libs-lite-svn : versioned libs only , compatible with llvm-libs

llvm-libs--svn : depends on llvm-libs-lite-svn adds the non-versioned libaries conflicts with llvm-libs