Ports that depend on old llvm versions should be updated

[mf2k (Frank Schima)]

The listed ports depend on older versions of llvm. Can they be updated to use either llvm-3.8 or llvm-3.9?

Originally suggested by jeremyhu in ticket:52317#comment:7.

Port	Maintainers	Status
faust2-devel	ryandesign aggraef	Fixed
ghc	cal	#48899
julia	sean
pure	ryandesign aggraef
py-llvmlite	stromnov	Not needed
py-llvmpy	stromnov

[ryandesign (Ryan Carsten Schmidt)]

I haven't looked at pure in awhile, but last I checked, there were reasons why I did not want to upgrade pure to a newer version of llvm than 3.4.

For faust2-devel, I don't recall.

I'm not wild about more portgroups and more variants.

[jeremyhu (Jeremy Huddleston Sequoia)]

Yeah, I'd prefer to not have more portgroups, especially for such a small set of projects, some of which are possibly dead and just in need of removal.

[neverpanic (Clemens Lang)]

For GHC, this will be #48899. I am not going to add variants, and I do not prefer using variants due to the additional testing effort I have to do.

[mf2k (Frank Schima)]

I updated the description to remove the mention of variants and a new portgroup due to unpopular demand.

[agraef (Albert Graef)]

I'm the principal developer of Pure, and I also maintain the related ports here (together with Ryan Schmidt).

Pure certainly isn't dead, I just haven't gotten around porting it to LLVM 3.6+ yet. It should work fine with LLVM 3.5, though.

This will also affect all LLVM applications which still rely on the old JIT rather than the new MCJIT of LLVM (of which there are still a few at least in Linux, not so sure about macOS). That's also why LLVM 3.5 ist still supported, e.g., on Arch Linux, along with the latest LLVM version. I'd suggest that MacPorts do the same, if possible. Otherwise supporting Pure on macOS will become *very* hard until it's ported to LLVM 3.6+ (which isn't trivial because of architectural changes in the LLVM JIT, otherwise I would have done it long ago).

Anyway, the executive summary is: I will try to port Pure to LLVM 3.6+ asap, but I'd appreciate it if MacPorts could have LLVM 3.5 stick around a little while until it's done.

[agraef (Albert Graef)]

Concerning faust2-devel, the latest git sources should support both LLVM 3.8 and 3.9, but I haven't verified this myself. I will update that port asap, but this may still take some time as I'm currently busy with other things.

[ryandesign (Ryan Carsten Schmidt)]

Replying to aggraef@…:

Pure certainly isn't dead, I just haven't gotten around porting it to LLVM 3.6+ yet. It should work fine with LLVM 3.5, though.

This will also affect all LLVM applications which still rely on the old JIT rather than the new MCJIT of LLVM (of which there are still a few at least in Linux, not so sure about macOS). That's also why LLVM 3.5 ist still supported, e.g., on Arch Linux, along with the latest LLVM version. I'd suggest that MacPorts do the same, if possible. Otherwise supporting Pure on macOS will become *very* hard until it's ported to LLVM 3.6+ (which isn't trivial because of architectural changes in the LLVM JIT, otherwise I would have done it long ago).

Anyway, the executive summary is: I will try to port Pure to LLVM 3.6+ asap, but I'd appreciate it if MacPorts could have LLVM 3.5 stick around a little while until it's done.

The reason for this ticket is probably the fact that llvm < 3.7 does not build on macOS Sierra. I don't imagine there are any plans to remove llvm < 3.7 for previous verisons of OS X, but also probably no plans to make llvm < 3.7 work on Sierra.

I think the reason why I did not update the port to llvm 3.5 is that that llvm 3.5 and later requires libc++, which is a bit problematic on OS X < 10.9 where libc++ is not the default and much more problematic on Mac OS X < 10.7 where libc++ is not present. Perhaps by now support for older OS versions is less important.

[stromnov (Andrey Stromnov)]

• py-llvmpy has been officially deprecated and is no longer being actively developed (in favor of llvmlite project)
• py-llvmlite strongly depends on LLVM-3.8

[jeremyhu (Jeremy Huddleston Sequoia)]

Pure certainly isn't dead

Sorry if I wasn't clear. I wasn't saying that all the ports are dead and should be removed, just that some are likely in that camp (eg: py-llvmpy as mentioned above).

Don't worry, I do not intend to remove llvm-3.5 unless there are no dependents.

My thoughts on the older versions we still have around:

• 3.3 - Needed for bootstrapping on Leopard. We should limit our dependency elsewhere.
• 3.4 - A very solid release and the last one that works with libstdc++ (needed to bootstrap later versions). It will be around for quite some time.
• 3.5 - codegen issues on i386 make me not trust this version very much. I'd like to remove it eventually (but it is not pressing)
• 3.6 - A decent release, but there's not much of a need for it given the quality of later versions.
• 3.7 - The last release using autoconf. It'll be good to keep this one around as a point of reference for build system related regressions. It's also a high quality release.

[ryandesign (Ryan Carsten Schmidt)]

Replying to jeremyhu@…:

• 3.4 - A very solid release and the last one that works with libstdc++ (needed to bootstrap later versions). It will be around for quite some time.

Did you encounter a particular problem with 3.4 on Sierra, or did you just block it out of habit?

[jeremyhu (Jeremy Huddleston Sequoia)]

Did you encounter a particular problem with 3.4 on Sierra, or did you just block it out of habit?

Yes, the older versions of clang don't support 10.1x deployment targets (so that's actually an issue with Yosemite+), nullable, and various other keywords that are prevalent throughout the newer SDKs.

So it's not so much a "this doesn't work on Sierra" as a "this doesn't work well with the Sierra SDK"

[ryandesign (Ryan Carsten Schmidt)]

Sounds like you're talking about clang. What about just the features of llvm that Dr Graef mentioned he uses in pure?

[jeremyhu (Jeremy Huddleston Sequoia)]

Correct, llvm core is not impacted by the SDK changes, only clang.

[agraef (Albert Graef)]

jeremyhu, thanks for clarifying! I'm certainly glad that LLVM 3.4 will still be supported for the time being, on the older platforms at least.

Concerning clang in Sierra, AFAICT neither Pure nor any of its addon modules have clang as a dependency (other than that they need a C/C++ compiler to build, of course).

Some of the examples that ship with the Pure sources need a C/C++ compiler capable of producing LLVM bitcode, but that's in no way essential, so most Pure users should be fine as long as LLVM 3.4 (or 3.5) is provided, even if there's no matching clang version on Sierra.

[mojca (Mojca Miklavec)]

Cc Me!

[larryv (Lawrence Velázquez)]

Has duplicate #52491.

[ryandesign (Ryan Carsten Schmidt)]

Replying to jeremyhu@…:

Correct, llvm core is not impacted by the SDK changes, only clang.

Then can you please change the llvm ports to allow old llvm versions to build on Sierra, even if old versions of clang cannot?

[jeremyhu (Jeremy Huddleston Sequoia)]

That was my intent when I wrote that comment, but I'm incredibly overloaded. If you or someone else can provide a patch, I'll ack it.

[ryandesign (Ryan Carsten Schmidt)]

attachment:llvm-sierra.diff​ removes the prohibition on building llvm-3.3 through -3.6 on macOS Sierra and later. I haven't tried building these on Sierra yet.

[jeremyhu (Jeremy Huddleston Sequoia)]

Ack, thanks. Go ahead and push, but we should leave this open to get the others addressed. Thanks.

[ryandesign (Ryan Carsten Schmidt)]

Ok, let's try it. r153720.

[jeremyhu (Jeremy Huddleston Sequoia)]

​https://build.macports.org/builders/ports-10.12_x86_64-watcher/builds/963

Looks like it built fine (only the clang sub-ports are reported broken).

If anyone has issue with them on Sierra, please file a separate bug. If it's trivial to fix, I'll likely fix it. If not, it'll likely be marked as incompatible once the dependents are all updated.

[mf2k (Frank Schima)]

Cc reporter of duplicate #53410.

[mouse07410 (Mouse)]

Can you please accommodate llvm-3.9?

[geekosaur]

Urgh. So someone patched ghc to use a later LLVM. This broke it.

ghc has a hard dependency on specific LLVM versions, because the LLVM IR it generates needs specific annotations for LLVM to understand it and these annotations change with every release. If you want ghc to support a later LLVM, you must upgrade ghc to a version that supports generating compatible LLVM IR for that release.

Please either revert the ghc update or upgrade ghc. (ghc 8.0.2 supports LLVM 3.7. I do not know what version 8.2.1 will support when it is released, but possibly it will include its own LLVM; if it does, *please* do not be Debian and force it to use a MacPorts-installed LLVM unless you are willing to rewrite ghc's LLVM support including its generation of LLVM IR.)

[agraef (Albert Graef)]

Urgh. So someone patched ghc to use a later LLVM. This broke it.

Right, this should be reverted as quickly as possible. This port is really trivial to fix and then it compiles just fine in Sierra now. I've left a comment at ​https://github.com/macports/macports-ports/pull/70, and will follow up with a corresponding pull request later today.

[agraef (Albert Graef)]

Pull request is now up at ​https://github.com/macports/macports-ports/pull/320, can someone please have a look and merge? Thanks.

[agraef (Albert Graef)]

In d7385a7/macports-ports:

Fix broken ghc port, and add a patch to make it work on Sierra.

See: #52424
Closes: #52582

[agraef (Albert Graef)]

Re the faust2-devel port, I've fixed that in ​https://github.com/macports/macports-ports/pull/367. Can someone please commit? Thanks.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to agraef:

Re the faust2-devel port, I've fixed that in ​https://github.com/macports/macports-ports/pull/367. Can someone please commit? Thanks.

Done, thanks.