Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#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)

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.

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

Keywords: clang removed
Port: clang-3.9 clang-4.0 added; clang removed
Type: defectrequest

comment:3 Changed 5 years ago by jmroot (Joshua Root)

Cc: jeremyhu larryv added

comment:4 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)

See also #58747.

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: newclosed

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.

https://github.com/macports/macports-base/pull/137

Last edited 5 years ago by cjones051073 (Chris Jones) (previous) (diff)

comment:12 Changed 5 years ago by jmroot (Joshua Root)

Resolution: wontfix
Status: closedreopened

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: reopenedclosed

In 499729eaf92d6c7cf9a697575c9f5f2233315982/macports-ports (master):

Revert "llvm-3.9: Obsolete port" and "llvm-4.0: Obsolete port"

This reverts commits 8470ccfcdae5c31638c4c5bc2b24ee05e4a2a95b and
7615202b212d36d0598b5775cb33020a916462ac.

These clang versions are in the default fallback list used by base,
and so need to remain available until after a new base version that
doesn't use them is released.

Fixes: #58741

comment:14 Changed 5 years ago by cjones051073 (Chris Jones)

Cc: cjones051073 added

comment:15 in reply to:  12 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.

Note: See TracTickets for help on using tickets.