Missing llvm-config alternatives.

[Mike Mestnik]

Version-ed packages should use update-alternatives to manage the version-less instance.

update-alternatives --install /usr/bin/llvm-config llvm-config /usr/bin/llvm-config-3.1 31

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Randall Leeds (randall-leeds)]

I don't see this problem with llvm-3.1 on quantal, but I do see it on llvm-3.2 in raring.

Which release are you using?

[Mike Mestnik (cheako)]

Not sure, must have been precise-updates or quantal.

[Randall Leeds (randall-leeds)]

I see it now. On my quantal, symlinks are installed so llvm-link points to ../lib/llvm-3.1/bin/llvm-link, which is why I didn't notice a problem. There is still no alternative to configure, though.

On raring, llvm-3.2 doesn't even seem to install any symlinks, but that is a different bug I will have to verify and report. No alternatives there either, of course.

[Sylvestre Ledru (sylvestre)]

For now, llvm-config is provided by the llvm package.
It is a symlink pointing on the recommended version of llvm.

If you want to get llvm-config for llvm 3.2, try /usr/bin/llvm-config-3.2

[Mike Mestnik (cheako)]

The alternative system fully supports recommendations, please use it to allow the use of non-recommended versions as was intended.

[Matthias Klose (doko)]

it would be plain invalid to handle something via alternatives, which changes both ABI's and API's so rapidly. The alternatives system is not meant to be used for that.

[Mike Mestnik (cheako)]

I think you misunderstand the alternatives system. It's used for things that are much more different then simply ABI or API changes. It selected completed different applications, Unity VS Gnome VS KDE. The show stopper for alternatives is at X vs console applications, now if llvm-3.2 was a console app and llvm-3.1 was an X app then yes alternatives would seem inappropriate. However I'd say try and see if there is a problem, you can always have an alternative for the x and console only variants.

Here are some examples of alternatives that change ABI and API as well as the user interface drastically:
x-window-manager
mozilla-flashplugin
x-terminal-emulator
www-browser
x-www-browser

[Matthias Klose (doko)]

no, alternatives are not used to hide ABI or API changes. You should explicitly specify the tool you want to use. And there is nothing in your examples which affects building a package, so these alternatives cannot have any influence to the way a package or software is built.

[Mike Mestnik (cheako)]

Build scripts can and do call into all sorts of other applications, any of which can be an alternative. What protects the usual build from harm is the use of a minimal system. To support custom builds of other packages, please make use of the alternatives system and quit with your meaningless complaints.

[Sylvestre Ledru (sylvestre)]

To continue with meaningless complaints, I think Matthias is right.
We want packagers to explicitly use version X or Y of LLVM.
If they want to use the recommended version of LLVM, they just have to depend on the "llvm" package.

If you think we are wrong, please provide an example where the alternatives would improve the overall solution.

[Mike Mestnik (cheako)]

What is the overall solution, wouldn't that include users as well as packagers? You seem to be only thinking of packagers, you'll have to understand that you shouldn't do that when making packages.

You want packagers to do X, does that mean you are going to ignore the site administrators?

Alternatives is the solution for site administrators to be able to make the correct decision for there needs and the needs of there users on that system. By not providing alternatives you are forcing every site to be identical and that's very broad effecting every system with these packages installed. Thinking that you would be able to make the correct choice for everyone is what package maintainers should do, however in this case you'll need to implement alternatives because a few sites will need to be able to alter your decisions.

[Mike Mestnik (cheako)]

It's sad that this alternative should be set by the user running ./configure. However in most cases that is the site admin so there is a much smaller set of users who would be effected, they would have to ask an admin to adjust the alternatives for there build.

This discussion has only partly to do with cases that have the option to depend on packages. I opened this ticket because I downloaded a tar ball, unpacked in and needed to move links around by hand to select the correct version of llvm.

[Sylvestre Ledru (sylvestre)]

Users and upstream want a specific version of LLVM.
For example, if you have a look to the current trunk of LLVM (future 3.3), you will see that many headers paths have been changed.
Usually, upstream provides a way to change the path/version to llvm-config (or should).

Maybe I don't understand your arguments but, for me, like Matthias did, this bug is for me invalid.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Mike Mestnik (cheako)]

If you don't understand why, then there is no point in you not providing an alternatives in the package(s). The only reason for not using alternatives would be to force your viewpoints onto your users, which you should be doing even in cases were you are absolutely positive doing this would break things. Sine any tarball downloaded could potentially need(even if the need is broken or incorrect) the old LLVM even if the new LLVM is installed or Vice Vese, then this become an essential feature.

Since all you say is that thee is no reason for an alternatives and no reason not to implement alternatives, I don't understand any hesitation.

[mornfall (mornfall)]

Well, a major downside of not providing alternatives is that installing only llvm-3.2 (say) doesn't make it possible to compile and run 3rd-party LLVM-based software without substantial tweaking. We have modified configure script specially for Ubuntu/Debian to look for llvm-config-3.2 and llvm-config-3.1 in addition to llvm-config. However, we also need to invoke llvm-link and possibly other llvm binaries at runtime, and this is a lot trickier. It seems silly to write special hacks just to make things work out of the box on Debian/Ubuntu.

Please, just provide alternatives. There're no real reasons to not use them, besides "I don't want to". For most users, installing llvm-3.2 and actually getting llvm-3.2 that works out of the box would be quite useful, I reckon.

To quote from http://wiki.debian.org/DebianAlternatives: The Debian alternatives system creates a way for several programs that fulfill the same or similar functions to be listed as alternative implementations that are installed simultaneously but with one particular implementation designated as the default.

[Conrad Steenberg (conrad-steenberg)]

FWIW, this just bit me when compiling the Crack language, which was looking for llvm-config, not llvm-config-3.2.

I agree with mornfall above that if only 3.2 is installed, the alternatives system should be used to update llvm-config.

[Mike Henry (mike-henry)]

Using update-alternatives goes for all the other LLVM-tools as well, even though using llvm-config makes it a little easier to use.

This is the state of my LLVM tools in /usr/bin after installing 3.5. Had I been able to select whether to use 3.5 or 3.4 and had all links updated, then things would have been a lot easier..

/usr/bin$ ls llvm-*
llvm-ar-3.4 llvm-config-3.5 llvm-extract-3.4 llvm-nm-3.5 llvm-rtdyld-3.5
llvm-ar-3.5 llvm-cov-3.4 llvm-extract-3.5 llvm-objdump-3.4 llvm-size-3.4
llvm-as-3.4 llvm-cov-3.5 llvm-link-3.4 llvm-objdump-3.5 llvm-size-3.5
llvm-as-3.5 llvm-diff-3.4 llvm-link-3.5 llvm-prof-3.4 llvm-stress-3.4
llvm-bcanalyzer-3.4 llvm-diff-3.5 llvm-mc-3.4 llvm-ranlib-3.4 llvm-stress-3.5
llvm-bcanalyzer-3.5 llvm-dis-3.4 llvm-mc-3.5 llvm-ranlib-3.5 llvm-symbolizer-3.4
llvm-clang llvm-dis-3.5 llvm-mcmarkup-3.4 llvm-readobj-3.4 llvm-symbolizer-3.5
llvm-config llvm-dwarfdump-3.4 llvm-mcmarkup-3.5 llvm-readobj-3.5 llvm-tblgen-3.4
llvm-config-3.4 llvm-dwarfdump-3.5 llvm-nm-3.4 llvm-rtdyld-3.4 llvm-tblgen-3.5

(llvm-clang points to clang, which is not versioned. I created llvm-config myself using update-alternatives.)

I believe a llvm_select package is even available in MacPorts, which is a really nice feature to have: "port select --set llvm llvm-3.4". Makes it really easy to switch between LLVM versions.

[Sylvestre Ledru (sylvestre)]

While I might implement llvm-config on alternatives (patches are welcome), I don't think that doing that for all llvm tools is reasonable.
It is going to be a pain to maintain and hard to use for users.

And, AFAIK, we don't have an equivalent to the port option.

[Chris Bainbridge (chris-bainbridge)]

> FWIW, this just bit me when compiling the Crack language, which was looking for llvm-config, not llvm-config-3.2.

Yes, Xorg is the same, the build script looks for llvm-config and fails otherwise.

> no, alternatives are not used to hide ABI or API changes. You should explicitly specify the tool you want to use.

> Users and upstream want a specific version of LLVM.

I don't see how llvm is different to automake, or cc/c++, or java, which all support update-alternatives?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Chris Bainbridge (chris-bainbridge)]

Relevant comment from Xorg upstream on supporting explicit "llvm-version" naming in their build scripts:

"Mesa's build system supports and should only support officially supported builds of upstream projects - LLVM's cmake and auto* build systems do not have a switch to add a "-3.2" suffix to llvm-config.
Sorry, but we cannot support billions of (user-modified) cases by modifing build system each time - It is hard enough to support official builds.

If people or in this bad case even distributions think they must modify and mess up things it is their own problem"

Resolution NOTOURBUG - https://bugs.freedesktop.org/show_bug.cgi?id=59967

I guess that makes it pretty clear that not all users want a specific version of LLVM...

[Chris Bainbridge (chris-bainbridge)]

There is a update-alternatives workaround for llvm documented at http://kwangyulseo.com/2014/02/05/using-multiple-llvm-versions-on-ubuntu/

[Sylvestre Ledru (sylvestre)]

I will discuss about this on debian-devel to have other opinions. I am not sure what to do here...

[Mike Mestnik (cheako)]

* It is going to be a pain to maintain and hard to use for users.

The alternatives system was designed/built/implemented to address these issues. It's when this system is NOT used that multiple package versions become a pain to maintain and hard to use for users.

If you've a better idea or a problem with the alternatives system you should open a bug against that package. Otherwise it looks like this is the best approach and no attempt is made to make improvements.

[Sylvestre Ledru (sylvestre)]

Here is the thread that I started on debian-devel:
https://lists.debian.org/debian-devel/2014/06/msg00380.html

[Chris Bainbridge (chris-bainbridge)]

> Here is the thread that I started on debian-devel:
> https://lists.debian.org/debian-devel/2014/06/msg00380.html
> "llvm-defaults provides symlinks /usr/bin/llvm-nm to the actual binaries."

This is the first time I have seen anyone mention "llvm-defaults" - you say that it is supposed to automatically install symlinks like /usr/bin/llvm-nm - but this does not seem to happen, the only symlinks I have installed are with -version suffix like /usr/bin/llvm-nm-3.4.

[Mike Mestnik (cheako)]

The alternatives system is a high level tool meant to unify this process across all applications. It should be a solution flexible enough to cover and even support any application level tools. If you see cause for the alternatives system to make calls into llvm-defaults please go ahead and add that feature to the tool.

My advice would be to replace llvm-defaults with a wrapper around the update-alternatives tool, this would seem to be easier than having the update-alternatives tool call the llvm-defaults tool.

For generic problems that affect many applications it's important that applications do not construct individual solutions! This puts a heavy burden on the users to learn each applications system.

[Chris Bainbridge (chris-bainbridge)]

Could someone explain how to use llvm-defaults to create the default symlinks to the versioned binaries? It might help some of the people subscribed to this bug.

[Matthias Klose (doko)]

apt-get install llvm-runtime
apt-get install llvm-dev

[Rick Foos (rickfoosusa)]

In 15.10, llvm-runtime, and llvm-dev resolve to llvm-3.6-runtime, and llvm-3.6-dev.

Nothing is put into the alternative system.

So if llvm-3.7-runtime, and llvm-3.7 dev are installed, there is really no way to pick a default to switch between revisions.

If the installations at least added everything to alternatives, with the latest version given the highest priority, there would be a way to upgrade automatically, and manually select a desired version.

[Matthias Klose (doko)]

Yes, we support 3.6 in 15.10. 3.7 is unsupported (and fails to build on i386 and powerpc).

> Nothing is put into the alternative system.

yes, intended. Use llvm-config-3.7 explicitly, or prefix your command with

    PATH=/usr/lib/llvm-3.7/bin:$PATH

> So if llvm-3.7-runtime, and llvm-3.7 dev are installed,
> there is really no way to pick a default to switch between revisions.

see above. you are wrong.

> If the installations at least added everything to alternatives,
> with the latest version given the highest priority, there would
> be a way to upgrade automatically, and manually select a desired version.

Wrong, this would lead to automatic breakage when changing LLVM versions. There are no two LLVM versions which are ABI and/or API compatible.