Opened 8 years ago

Last modified 2 years ago

#52424 new enhancement

Ports that depend on old llvm versions should be updated — at Version 33

Reported by: mf2k (Frank Schima) Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: jeremyhu (Jeremy Huddleston Sequoia), ryandesign (Ryan Carsten Schmidt), agraef (Albert Graef), neverpanic (Clemens Lang), stromnov (Andrey Stromnov), mojca (Mojca Miklavec), jowens@…, mouse07410 (Mouse)
Port: pure py-llvmpy

Description (last modified by jeremyhu (Jeremy Huddleston Sequoia))

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

Change History (34)

comment:1 Changed 8 years ago by 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.

comment:2 Changed 8 years ago by 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.

comment:3 Changed 8 years ago by 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.

comment:4 Changed 8 years ago by mf2k (Frank Schima)

Description: modified (diff)

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

comment:5 Changed 8 years ago by mf2k (Frank Schima)

Description: modified (diff)

comment:6 Changed 8 years ago by 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.

comment:7 Changed 8 years ago by 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.

comment:8 in reply to:  6 Changed 8 years ago by 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.

comment:9 Changed 8 years ago by 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

comment:10 Changed 8 years ago by 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.

comment:11 in reply to:  10 Changed 8 years ago by 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?

comment:12 Changed 8 years ago by 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"

Last edited 8 years ago by jeremyhu (Jeremy Huddleston Sequoia) (previous) (diff)

comment:13 Changed 8 years ago by 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?

comment:14 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)

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

comment:15 Changed 8 years ago by 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.

comment:16 Changed 7 years ago by mf2k (Frank Schima)

Description: modified (diff)

comment:17 Changed 7 years ago by mojca (Mojca Miklavec)

Cc: mojca@… added

Cc Me!

comment:18 Changed 7 years ago by larryv (Lawrence Velázquez)

Cc: jowens@… added

Has duplicate #52491.

comment:19 in reply to:  14 Changed 7 years ago by 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?

comment:20 Changed 7 years ago by 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.

Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)

Attachment: llvm-sierra.diff added

comment:21 Changed 7 years ago by 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.

Last edited 7 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:22 Changed 7 years ago by jeremyhu (Jeremy Huddleston Sequoia)

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

comment:23 Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)

Ok, let's try it. r153720.

comment:24 Changed 7 years ago by 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.

comment:25 Changed 7 years ago by mf2k (Frank Schima)

Cc: mouse07410 added

Cc reporter of duplicate #53410.

comment:26 Changed 7 years ago by mouse07410 (Mouse)

Can you please accommodate llvm-3.9?

comment:27 Changed 7 years ago by 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.)

comment:28 Changed 7 years ago by 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.

comment:29 Changed 7 years ago by 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.

comment:30 Changed 7 years ago by 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

comment:31 Changed 7 years ago by 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.

comment:32 in reply to:  31 Changed 7 years ago by 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.

comment:33 Changed 7 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Description: modified (diff)
Note: See TracTickets for help on using tickets.