Hacker News Reader

Comment by RX14 | Hacker News Reader

Unfortunately the assertion that you control which LLVM version you use isn't always the case. Debian 8 stable is still using LLVM 3.5, while homebrew on OSX and archlinux typically track the latest stable version (currently 3.9). Crystal, the programming language I work on, has to work on both versions and a few in between. (We're dropping support for < 3.8 soon though). Sure, we could bundle a LLVM version with the language, but that has several disadvantages, including size and extra work to build and distribute the package securely.

That being said, the changes are typically minor, and while the bindings are a little bit too dense on {% if LibLLVM::IS_38 %} for me [0], it's certainly not hellish yet. However the LLVM debug info generator is a different story... [1]

[0] https://github.com/crystal-lang/crystal/blob/c60df09b5082918... [1] https://github.com/crystal-lang/crystal/blob/master/src/llvm...

View on HN

It is my understanding that this is semi-explicit in the culture of the LLVM project as a BSD analog to the architectural damage sometimes described with GCC and GPL: instead of "we don't like supported intermediate data formats, as it allows people to hoard code: if you want to use our code you have to link to it, which will force you to open source your code so it can be upstreamed" they play "we don't like supported APIs, as it allows people to hoard code: if you want to use our code you will spend a lot of your time on the merge treadmill, which will eventually demoralize you into begging for us to upstream your code".

Honestly I just think distros and package managers are the busted ones here. LLVM is strongly coupled to your language's semantics, and I'm unaware of any good reason to force every compiler to use the same version.

This is why I wish more package managers had a (more) formalized versions of what Gentoo calls "slots". One of the major uses of slots in Gentoo is to represent major versions of libraries, s.t. LLVM 3.5 would be in the "3.5" slot, and LLVM 4 would be in the "4" slot. Dependencies are declared against slots, and the standard *nix naming convention for shared objects trivially lets multiple slots be installed at the same time.

(Other package managers tend to emulate slots by simply having multiple packages with the slot number embedded in the package name itself. Debian/Ubuntu, for example, does this, and it isn't clear to me why their scheme would preclude having multiple LLVMs installed. That said, Gentoo always seems to have difficultly with clang/llvm, so my gut wonders if there is something more at play here.)

Debian does exactly that - the unstable repo currently has:

llvm-3.4 llvm-3.5 llvm-3.6 llvm-3.7 llvm-3.8 llvm-3.9 llvm-4.0

Note that these are all package names. Each is then versioned separately - e.g. 4.0 is currently at v4.0-1, and 3.8 is at 3.8.1-18.

It's not a technical problem. All distro package managers allow for parallel-installed libraries one way or another.

What's necessary for your distro to actually ship multiple versions is someone stepping up to actually maintain the thing, dealing with bug reports and monitoring security issues.

For libraries with many users that happens all the time. See the parallel packages for OpenSSL 1.0 and 1.1 in most distro repositories. For less popular libraries it's often easier to just patch all users and only ship the most recent version.

Nowadays LLVM seems firmly placed in the first camp, as patching programs to work with different LLVM versions can be a lot of work and there are quite a lot of them.

Looking into the Debian repos, you find packages for LLVM 3.7, 3.8, 3.9 and 4.0, in addition there's even a 5.0 pre-release snapshot. It's similar with Fedora and probably other distributions.

Just curious - why not define a macro for some of those? For example DI_FLAGS_TYPE that resolves to DINode::DIFlags / uint as needed? It seems there are some similarities that could be abstracted.

Also a cleanup could be simpler later - find/replace the macro.

Yes, same for pony. Only DIFile and the AlignBits changed.

Reply on news.ycombinator.com