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
Ping?
Perhaps we probably need Software Collections also for llvm.
(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.
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?
(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?
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).
You're right some legwork is needed. At the very least llvm-libs and llvm33-libs need to be installable together I guess.
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).
Bump. :-)
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.)
OK, I've opened Bug 1109390.