> On 22 Jan 2019, at 4:16 pm, Ken Cunningham <[email protected]> > wrote: > > > On 2019-01-22, at 2:37 AM, Joshua Root wrote: > > >> >> I think this issue overall is covered by >> <https://trac.macports.org/ticket/37846>, and I agree with jeremyhu's >> assessment there.
Personally I do not really completely agree with Jeremy here. MacPorts gcc ports are configured to use MacPorts toolkit, as per the cctools port. This is exactly what it is doing. I see nothing to blaim gcc for in this regard. Its not ggc’s fault that the tool kit we are configuring it to use is flawed. The issue, from my perspective, lies with a combination of how the as shipped with cctools, Apples own open sourced version, decides whether or not to use clang, via some rather convoluted gymnastics, partly due to the ancient fallback GNU as they ship when it decides not to use clang (for licensing reasons we all know about) and in part due to the way MacPorts packages things which causes the cctools as to effectively never pick clang and always to fallback to the ancient GNU as version. >> >> - Josh > > Yes, we discussed it there similarly to this email chain. > > But Jeremy's solution five years ago was to leave it to gcc to fix. > > That -- I think -- is just never going to happen. I agree. The only way we will improve things, I believe, is if we decide to make some changes to cctools. Ideally I think the default cctools should be variant free, and if be tweak what it does on different platforms more behind the scenes (so, for instance, things could change in the future without all the issues w.r.t. variants changing). It would also I think be a good idea to look to patching as’s driver.c code, to make it a bit more MacPorts aware and thus able to be more flexible in picking an appropriate clang to use. Chris
smime.p7s
Description: S/MIME cryptographic signature
