#58741 closed request (fixed)
get clang 3.4 and 3.9 4.0 5.0"back"
Reported by: | rmottola (Riccardo) | Owned by: | jmroot (Joshua Root) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | jeremyhu (Jeremy Huddleston Sequoia), larryv (Lawrence Velázquez), cjones051073 (Chris Jones) | |
Port: | clang-3.9 clang-4.0 |
Description
recently clang 8.0 has been marked a replacement for older compilers. This is not true generally: when Mac SDK code is used, too new compilers cause issues, so on 10.6 Snow Leopard, for example 3.9 is a very good compromise, as is clang 5.0 too. Clang 8.0 is just "too new". For non-Mac code this is different and newer compilers are fine (Same applies for GCC, btw, using gcc6 or gcc8 causes issues!)
Ken maybe has more experience, but I think 3.9 is useful to retain. Also, it is difficult to bootstrap these compilers, so to get 8.0 I needed 3.9, but I needed to get 3.4 which is the "source". Similar experiences on 10.7 or 10.5, just with different limits. On 10.5 I use 3.4 and 3.7, wanting to get 3.9 and 5.0 actually
Change History (17)
comment:1 Changed 5 years ago by kencu (Ken)
comment:2 Changed 5 years ago by mf2k (Frank Schima)
Keywords: | clang removed |
---|---|
Port: | clang-3.9 clang-4.0 added; clang removed |
Type: | defect → request |
comment:3 Changed 5 years ago by jmroot (Joshua Root)
Cc: | jeremyhu larryv added |
---|
comment:5 Changed 5 years ago by rmottola (Riccardo)
4.0 was a bad release for me, no need to get it back. 3.9 did all what 3.7 did, I only don't know if 3.7 is a needed stepstone to actually get a working 3.9? I think to remember yes.
comment:6 Changed 5 years ago by kencu (Ken)
Yes, you needed 3.7 to get to 3.9. 3.4 wouldn't build it properly.
If you need 3.9 for some reason, it's easy enough to get it back. You most likely still have it installed. Try sudo port -v activate llvm-3.9
and it should pop up a list of the ones you have. Select the previous-to-last one. Then do the same with clang-3.9
and you'll be good to go.
The only issue will be if the underpinnnings every change requiring a rebuild -- I think this is unlikely to happen, but if it did, then you'd need a portfile to match that version. That is a bit more tricky.
To do that, you create a local repository <https://guide.macports.org/chunked/development.local-repositories.html> and then find and copy over the last version of the llvm-3.9 directory that you want.
You can find this pretty easily by looking at the log history in the git repo.
comment:7 Changed 5 years ago by jeremyhu (Jeremy Huddleston Sequoia)
What specific issues are you seeing clang-8.0 have with the SnowLeopard SDK? I am not aware of any issues. This ticket is not really actionable without specifics. We won't be resurrecting 3.9 nor 4.0.
comment:8 Changed 5 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Also, I'm not aware of 5.0 being needed for bootstrapping later builds anywhere. Where is that information coming from? I'd like to also deprecate 5.0 and 6.0 next year.
comment:9 Changed 5 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:10 Changed 5 years ago by kencu (Ken)
I haven’t verified building clang 7+ with clang 3.7 as yet.
It might work ; just don’t know for sure at present.
comment:11 Changed 5 years ago by cjones051073 (Chris Jones)
Obsoleting macports clang compilers is fine, I am in favour of removing old ones as possible, but before obsoleting the port you first need to remove reference to them in base. A number of them are used as fallbacks and this needs to be removed, *and* made available to users as a public release, *before* the port is declared obsolete. e.g. Macports clang 5.0 is a very commonly used fallback, so please do not obsolete this one at least before removing all references to it in base. I recently had to do this for 3.9 and 4.0 in base, which should have been done before the ports themselves where declared as obsolete.
comment:12 follow-up: 15 Changed 5 years ago by jmroot (Joshua Root)
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
Yeah, these need to come back until after the next base release.
comment:13 Changed 5 years ago by jmroot (Joshua Root)
Owner: | set to jmroot |
---|---|
Resolution: | → fixed |
Status: | reopened → closed |
comment:14 Changed 5 years ago by cjones051073 (Chris Jones)
Cc: | cjones051073 added |
---|
comment:15 Changed 5 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Replying to jmroot:
Yeah, these need to come back until after the next base release.
Why? They aren't referenced in base any more? That logic has been kept in the ports tree for almost a year now, and it was updated prior to the obsoletion.
comment:16 Changed 5 years ago by jmroot (Joshua Root)
Yes, it's been too long between releases. 2.5.x doesn't use the compiler selection files in the ports tree.
https://github.com/macports/macports-base/blob/v2.5.4/src/port1.0/portconfigure.tcl#L604
comment:17 Changed 5 years ago by cjones051073 (Chris Jones)
I can only agree, we really should think about making incremental base releases a bit more regularly... Its been way too long since the last.
We kept 3.4, 3.7, and 5.0 as stepping stones. I hope I thought that through fully...I think that’s the minimal amount needed.
I have kept them all in backup in case we need them, esp 3.9 , but the portfiles will start breaking due to dep changes and base changes sooner or later.