Bug 1098534

Summary: Package relying on a specific LLVM version
Product: [Fedora] Fedora Reporter: Milan Bouchet-Valat <nalimilan>
Component: llvmAssignee: Adam Jackson <ajax>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: ajax, bos, dmalcolm, jv+fedora, petersen, scottt.tw
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-13 19:04:30 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1040517    
Attachments:
Description Flags
llvm3.3 .spec file none

Description Milan Bouchet-Valat 2014-05-16 13:37:44 UTC 
I'm currently working to package the new Julia language [1] in Fedora (bug 1040517). In doing that, I'm facing a problem regarding LLVM versions: indeed, Julia relies on LLVM APIs which change accross releases. Currently, it only works with LLVM 3.3, and fails with the new 3.4 version which has recently been uploaded to F20.

So I'm wondering how you think I should proceed. Even if at some point Julia is fixed to support LLVM 3.4, a future update will likely break it at some point in the future. To me, the only reasonable solution would be that Julia rely on a specific LLVM version, and only change it manually when it is known to be supported.

At the moment, it is still possible to build a package using LLVM 3.3, simply by installing LLVM packages from the "fedora" rather than "fedora-updates" repository. Do you consider this a reasonable option? One drawback is that on a desktop machine, mesa-libxatracker will likely be installed, and it depends on the lastest version of llvm-libs. This means one cannot build a package using LLVM if one wants to keep the latest Mesa on their machine; of course it's not a problem on Koji VMs. A solution would be to move the contents of llvm-libs into llvm-libs-$VERSION, and to make all libraries inside the package use versioned names too; then llvm-libs would only provide symbolic links to .so files, and would only be required for development. I guess this makes sense, since usually executables do not required unversioned .so files (from -devel packages) to be installed, only versioned ones.

Thanks for your help!


1: http://julialang.org
Comment 1 Milan Bouchet-Valat 2014-05-28 07:24:15 UTC 
Ping?
Comment 2 Jens Petersen 2014-05-29 01:57:35 UTC 
Perhaps we probably need Software Collections also for llvm.
Comment 3 Jens Petersen 2014-05-29 02:03:38 UTC 
(In reply to Jens Petersen from comment #2)
> Perhaps we probably need Software Collections also for llvm.

Until that might happen, you may be better off using Copr perhaps?

We do certainly have contention though with llvm versions.
Mesa always seems to want latest llvm to support latest GPUs I think
whereas compiler tools often tend to lag somewhat preferring
slightly older recent releases.
Comment 4 Milan Bouchet-Valat 2014-05-30 19:51:52 UTC 
Actually, I'm not even able to use Copr since as long as my package depends on llvm-libs 3.3, it cannot be installed in parallel with Mesa.

How would software collections help with that problem? What do you think of my proposal about versioning llvm-libs?
Comment 5 Jens Petersen 2014-06-02 07:39:48 UTC 
(In reply to Milan Bouchet-Valat from comment #4)
> Actually, I'm not even able to use Copr since as long as my package depends
> on llvm-libs 3.3, it cannot be installed in parallel with Mesa.

Julia doesn't need Mesa right?

So my suggestion was basically to add a llvm33 package
(perhaps initially in Copr) and use that to build Julia.

> How would software collections help with that problem?

Ok, a Software Collection might actually be overkill in this case.

> What do you think of my proposal about versioning llvm-libs?

I guess llvm33 could provide llvm33-libs and llvm33-devel.
Is that would you have in mind?
Comment 6 Milan Bouchet-Valat 2014-06-02 08:55:25 UTC 
Sure, Julia doesn't need Mesa; it just needs to be installable at the same time as Mesa for users who want both.

Having llvm33, llvm33-libs, llvm33-static and llvm33-devel parallel installable with LLVM 3.4 would be perfect. (Calling them llvm-3.3-XXX would probably look nicer.)

Though using the old LLVM 3.3 packages from the 'fedora' repo and renaming them will not be enough, the .so files need to be renamed too to avoid conflicts with 3.4 (cf. bug description).
Comment 7 Jens Petersen 2014-06-03 02:13:44 UTC 
You're right some legwork is needed.

At the very least llvm-libs and llvm33-libs need to be installable together I guess.
Comment 8 Milan Bouchet-Valat 2014-06-08 17:19:06 UTC 
Created attachment 903308 [details]
llvm3.3 .spec file

I've put together a llvm3.3 package based on the last llvm-3.3 F20 .spec file. It's parallel-installable with the standard llvm package, except for -devel subpackages. See attached .spec file, and Koji build here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7020563

With this, I'm able to build Julia based on LLVM 3.3 on F20.

Actually, one could even imagine moving headers to a versioned path instead of putting them in /usr/include/llvm, which would allow installing -devel packages for 3.3 and 3.4 in parallel. alternatives would then be used to choose which llvm-config to enable. Though I'm not sure it's worth it, and when I tried it didn't work as ./configure does not seem to take into account --includedir (or I did something wrong).
Comment 9 Milan Bouchet-Valat 2014-06-12 13:01:48 UTC 
Bump. :-)
Comment 10 Jens Petersen 2014-06-13 01:40:58 UTC 
It sounds good to me and good progress.
I haven't looked carefully at the spec file
but how about submitting the package for review?

One comment: it might be better to call it llvm33 rather than llvm3.3.
I know 3.3 is more precise but I think usually Fedora tends to avoid "."s
in package names - otherwise llvm-3.3 might be better perhaps.
Personally I would go with llvm33 anyway.

(There is also work underway to allow SCL in Fedora but it
will needs more work.)
Comment 11 Milan Bouchet-Valat 2014-06-13 19:04:30 UTC 
OK, I've opened Bug 1109390.