Mark Mentovai

That’s no problem. I was primarily hoping to get this into [iains/gcc-12-branch](https://github.com/iains/gcc-12-branch) as that’s where [MacPorts gcc-devel on mac-arm64](https://github.com/macports/macports-ports/blob/0abf9a96ab316a6149cffcdf478621bbdcb29ea4/lang/gcc-devel/Portfile#L33) is currently pulling from (although it’d be great if that could...

> I think this is now handled OK in 12.x and master, right? Think so. I think that this was only a problem in your branches. Upstream doesn’t have `enable_darwin_at_rpath`...

[cpplint here](https://github.com/google/styleguide/tree/gh-pages/cpplint) was maintained by @eglaysher while he was at Google, and hasn’t seen much action since. I didn’t know anything about [cpplint/cpplint](https://github.com/cpplint/cpplint) until moments ago.

It’s just a question of ownership. If there are internal owners for cpplint, it’d be best for them to be involved in the process. But even if we can’t get...

@kencu: > here’s the ticket where I put down my experiments > > https://trac.macports.org/ticket/65293 I don’t follow. There, you show that `xcrun --sdk macosx --find ld` and even `xcrun --sdk...

@kencu: > 2. "use_xcode yes" is still needed, sometimes, and it ideally should not be Can we figure out when, though? The part that I’m having trouble with is that...

@kencu: > Well, not quite. > > The experiment suggests that xcrun calls through to xcodebuild if Xcode is installed, but not if Xcode is not installed. My current thinking...

https://github.com/macports/macports-ports/commit/9887e90d69f4265f9056cddc45e41551d7400235#commitcomment-49824261 showed that `xcrun --show-sdk-path` doesn’t work on some older OS versions (presumably OS X 10.7, but it wasn’t nailed down explicitly), hence the `xcrun --find ld` technique. As I...

@mascguy @kencu: I ended [my last comment](https://github.com/macports/macports-ports/pull/15136#issuecomment-1159832469) with a proposal: > One option would be to sniff out the string `cannot be located` from `xcrun`’s `stderr`, and treat it as...

> Our previous method only became a problem once we got into the macosx12.1, 12.2, 12.3, etc business it seems? Well, here, yes, mostly. Apple screwed this up by switching...