FS#57387 - [julia] Requires a patched version of LLVM

Attached to Project: Community Packages
Opened by Samuele Disegna (smldis) - Monday, 05 February 2018, 21:33 GMT
Last edited by Alexander F. Rødseth (xyproto) - Thursday, 01 March 2018, 11:56 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Alexander F. Rødseth (xyproto)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
julia language is using several patches for ad hoc functionality in LLVM 3.9.

This can cause unexpected behavior in users programs.
Core developers suggest to use the official binary.
We should keep very careful up to date with the development or it is better to remove this package from community and allow an AUR version with the official binary.

For an example look at: https://github.com/JuliaNLSolvers/NLsolve.jl/issues/123


Additional info:
* version 0.6.2

This task depends upon

Closed by  Alexander F. Rødseth (xyproto)
Thursday, 01 March 2018, 11:56 GMT
Reason for closing:  No response
Additional comments about closing:  Using the files included with Julia instead of depending on packages available on the system, for now. This is because Julia requires dependencies to be patched.
Comment by Eli Schwartz (eschwartz) - Monday, 05 February 2018, 21:40 GMT
That sounds perfectly dreadful, is there any way julia could be fixed so that it works without a custom llvm version?
Comment by Antonio Rojas (arojas) - Monday, 05 February 2018, 21:46 GMT
If Julia doesn't work with an external LLVM, then they should simply force building with its internal LLVM. Having a build system that allows building with external LLVM and then blaming the packagers for issues caused by this is nonsense.
Comment by Samuele Disegna (smldis) - Monday, 05 February 2018, 23:07 GMT
No one is blaming no one. I don't know why it is done like this. I think there are warnings in several places.
Anyway, it is possible to apply a list of patches to llvm in order to make it work but given the very fast development of julia it can be difficult to follow.
As a user I would ask to drop official community support if this kind of packaging is discouraged. (Obviously these bugs are awful for both communities).
Also the wiki should report this somehow.

@arojas I will propose what you suggested if you really think it's a good choice.
Comment by Alexander F. Rødseth (xyproto) - Tuesday, 06 February 2018, 08:19 GMT
Thanks for reporting.

When building Julia, the choices are between:

1) USE_SYSTEM_LLVM=1 and then depend on the llvm39 package in [extra]

and

2) USE_SYSTEM_LLVM=0 and use the specially crafted LLVM sources that comes with Julia.

I think 2 is a horrible idea and that Julia should be moved to AUR before we set USE_SYSTEM_LLVM=0.

I think 1 is sub-optimal too, and that Julia should use the latest version of LLVM that is installed on the system.

Any other options? Thoughts? Ideas?
Comment by Samuele Disegna (smldis) - Tuesday, 06 February 2018, 08:30 GMT
- Is (2) horrible from which perspective?
- (1) is not fine since extra's LLVM will get the patches merged later than the julia release. Also building julia with a different LLVM version than what is officially shipped now would usually cause a big performance impact. Since the development is not focusing on the performance of upstream LLVM (for now).
Comment by Alexander F. Rødseth (xyproto) - Tuesday, 06 February 2018, 08:45 GMT
2) breaks with the current model of how Arch Linux packages are packaged.

The model Arch Linux is built around is to let package depend on each other, and always use the latest release of every package while also avoiding patches, whenever possible; to let upstream develop and packagers package. If this approach is "good" or "bad" is up for discussion, but I believe the current model of including modified LLVM sources in the Julia source code repository is not a good fit for the packaging model that Arch Linux uses.
Comment by Samuele Disegna (smldis) - Tuesday, 06 February 2018, 09:00 GMT
Ah yes I know (9 years arch linux user). The real question I wanted to ask is why moving to AUR is not the main option in the list. At least for now until an archlinux packager goes deeper in the situation that is quite delicate (something like rust).
Comment by Antonio Rojas (arojas) - Tuesday, 06 February 2018, 09:03 GMT
What would moving it to AUR solve? People installing it from AUR would face the exact same issues. Also, julia is currently a dependency of other packages, it can't be moved without breaking those packages.
Comment by Antonio Rojas (arojas) - Tuesday, 06 February 2018, 09:04 GMT
The real solution here is identifying the LLVM commits that fix the issue (assuming that this is indeed caused by LLVM) and applying them to our package.
Comment by Alexander F. Rødseth (xyproto) - Tuesday, 06 February 2018, 09:26 GMT
arojas,

* Julia is not currently a depenceny of other packages, only cantor has it listed as an optional dependency.
* Moving Julia to AUR would not solve the technical issues that the Julia project are facing, but it changes the status of the package and what users can expect in terms of support.

I agree that there is no need to rush a move to AUR, but I do think it's one valid option (among many).
Comment by Samuele Disegna (smldis) - Tuesday, 06 February 2018, 09:32 GMT
Ah yes dependencies, that's horrible as you said. But in this case there is just one very optional dependency.
I think that moving to AUR (shipping the official binary) is still a good temporary option. Julia development will focus more on LLVM after 1.0 (that is coming this early year).

For future reference for building julia and patching LLVM, here you can find the patches: https://github.com/JuliaLang/julia/tree/master/deps/patches and probably you can follow the offical buildscripts until someone get to follow the community and get all the information it is needed to take care of users.
Comment by Antonio Rojas (arojas) - Tuesday, 06 February 2018, 09:36 GMT
@xyproto it is a *build-time* dependency. Moving it will prevent building Julia support in Cantor

@smldis nothing prevents anybody from pushing a julia-bin package to AUR which bundles the upstream binary, there are many examples of that. And certainly there's nothing wrong with upstream Julia recommending Arch users to install the julia-bin package. But ideally we should collaborate to have a package in our repos that solves these issues in a way that is satisfactory for both parties.
Comment by Alexander F. Rødseth (xyproto) - Tuesday, 06 February 2018, 11:55 GMT
@arojas It's still only one optional dependency. Rebuilding Cantor without Julia support would be fine, IMO.

@smldis It's not just LLVM. Julia also includes sources that are currently used for: OPENLIBM, OPENSPECFUN, BLAS, LAPACK, LIBUV, UTF8PROC and DSFMT.
Comment by Milan Bouchet-Valat (nalimilan) - Tuesday, 06 February 2018, 12:46 GMT
> @smldis It's not just LLVM. Julia also includes sources that are currently used for: OPENLIBM, OPENSPECFUN, BLAS, LAPACK, LIBUV, UTF8PROC and DSFMT.

@xyproto AFAIK Julia does not need any patches for these libraries, except libuv which is a fork (but it's also a small dependency). At least in Fedora I just use the standard packages.

FWIW, if you want to see the LLVM patches we use in Fedora (some are needed by other projects than Julia):
https://src.fedoraproject.org/cgit/rpms/llvm3.9.git/tree/
Comment by Alexander F. Rødseth (xyproto) - Tuesday, 06 February 2018, 13:33 GMT
@nalimilan, thanks for the insight from Fedora. I will try enabling the system versions of those packages and see if some of them work when compiling Julia now, since last time I tried.

When it comes to llvm39 in Arch Linux, Julia is the **only** dependency, amongst the official packages: https://www.archlinux.org/packages/extra/x86_64/llvm39/

To be fair, Blender depends on llvm35 (as the only official package), so Julia is not the only exception.

If llvm39 could be removed entirely (from the official package collection, and moved to the unofficial one at AUR), I think that would be advantageous.
Comment by Alexander F. Rødseth (xyproto) - Tuesday, 06 February 2018, 16:55 GMT
@smldis

Both patching the llvm39 package specifically for for Julia, or using a custom version of LLVM that comes with Julia, is, IMO, not compatible with The Arch Way.

Please report this problem upstream and ask Julia developers to support an unpatched version of LLVM; be it LLVM 3.5, 3.9, 5.0 or the latest version at any time.
Comment by Samuele Disegna (smldis) - Tuesday, 06 February 2018, 18:20 GMT
What you ask is not needed since there are already people working on it and they are doing a grear job.

There are many other constraints and priorities to take care of before reaching that goal. The ETA is not clear and that's why a temporary solution can be helpful for users.

Thank you everybody for being so committed on the topic :)
Comment by Milan Bouchet-Valat (nalimilan) - Tuesday, 06 February 2018, 21:50 GMT
As I noted on one of the GitHub issues, it should be possible for Julia to work with LLVM without patches at some point, but that's not going to happen for 1.0, which will keep using LLVM 3.9. So at the very best that would be for 1.1. It would be nice to find a solution in the meantime.
Comment by Alexander F. Rødseth (xyproto) - Wednesday, 07 February 2018, 10:17 GMT
Updated the julia package to include the patched LLVM version that comes with Julia, while waiting for a release that can depend on a package that is an unpatched version of LLVM.

The updated julia package will appear in [community] shortly.
Comment by Samuele Disegna (smldis) - Wednesday, 07 February 2018, 10:19 GMT
Wow, I didn't thought this was an option. <3

Did you run the testsuite?
Comment by Milan Bouchet-Valat (nalimilan) - Wednesday, 07 February 2018, 10:50 GMT
Sounds great!
Comment by Eli Schwartz (eschwartz) - Wednesday, 07 February 2018, 11:09 GMT
@xyproto, I assume this is a stopgap measure while you figure out how to ensure the llvm39 package has backported the right fixes?
Comment by Alexander F. Rødseth (xyproto) - Wednesday, 07 February 2018, 13:36 GMT
@eschwartz The llvm39 package is not maintained by me, and Julia needing LLVM patches is not a problem with the llvm39 package. But it's a stopgap measure, yes.

Loading...