Can't run C++ code after updating the Command line tools(maybe?)

You made a critical mistake. You posted the same content in the Apple Developer forums. In this forum, you omitted the key piece of information. Not that it was difficult to guess. It's always homebrew. 😄

divyans wrote:

What do you mean by 'always homebrew'. Do i have to do something with it to resolve the issue. If yes, then what do i have to do?

etresoft is not fond of homebrew.

Yes, homebrew installs can sometimes go sideways.

If you really need gcc here (and not the clang-provided gcc shim, or clang++ itself), remove and then reload gcc using homebrew, and follow the setup procedure for establishing gcc in your path. But if you don’t specifically need gcc, use clang.

divyans wrote:

Do i have to do something with it to resolve the issue. If yes, then what do i have to do?

Yes. Uninstall homebrew.

There is no problems with Xcode 15. It's just that Homebrew has done something horribly wrong, as it always does, that causes it to break with Xcode 15.

Unfortunately, this is often a catch-22. People install Homebrew because they don't know how to configure, build, or install dependences on a Mac. This is because the developers of various dependences also don't know how to do that. But what this means is that no one knows how to uninstall Homebrew either. Usually it requires erasing the hard drive and reinstalling the operating system.

Look at it this way. You have two apps installed. Homebrew and Xcode 15. They don't work together. You may not be able to even uninstall Homebrew. Yet you can removed Xcode 15 and reinstall the previous version with no problem. Which app is the higher-quality app? Replace Homebrew and Xcode with any 2 apps and the answer is always the same. Get rid of the junk app.

I don't have Xcode installed even then it is showing the same error in vs code:

Errors while compiling:

-macosx_version_min has been renamed to -macos_version_min

ld: warning: ignoring duplicate libraries: '-lgcc'

0 0x10254b648 __assert_rtn + 72

1 0x10247ffac ld::AtomPlacement::findAtom(unsigned char, unsigned long long, ld::AtomPlacement::AtomLoc const*&, long long&) const + 1204

2 0x102495924 ld::InputFiles::SliceParser::parseObjectFile(mach_o::Header const*) const + 15164

3 0x1024a2e30 ld::InputFiles::parseAllFiles(void (ld::AtomFile const*) block_pointer)::$_7::operator()(unsigned long, ld::FileInfo const&) const + 420

4 0x1a1958440 _dispatch_client_callout2 + 20

5 0x1a196bf1c _dispatch_apply_invoke + 224

6 0x1a1958400 _dispatch_client_callout + 20

7 0x1a1969fb8 _dispatch_root_queue_drain + 684

8 0x1a196a6c0 _dispatch_worker_thread2 + 164

9 0x1a1b04038 _pthread_wqthread + 228

ld: Assertion failed: (resultIndex < sectData.atoms.size()), function findAtom, file Relocations.cpp, line 1336.

collect2: error: ld returned 1 exit status

Pls help.

etresoft wrote:

gibfahn wrote:

Sounds like https://github.com/Homebrew/homebrew-core/issues/145991, which has more information.

For those keeping score at home, Github bug numbers are sequential. 😄

Purportedly, an Xcode 15 bug: FB13038083

MrHoffman wrote:

Purportedly, an Xcode 15 bug: FB13038083

Not really. It's an assertion. Apple coded it that way on purpose.

In any event, Apple feedback numbers are only useful to Apple. They aren't like Github issues. Only Apple and the original author have any access to them.

The very last thing that anyone impacted by a problem like this should ever do is assume that just because someone posted an Apple feedback number somewhere, Apple is going to fix this bug promptly, or at all. Apple uses feedback reports as "votes" to gauge the scale of impact of a particular issue. So when someone sees a feedback number, assumes Apple is going to fix it, and then doesn't file their own report, that is a vote for Apple to not fix the problem. Anyone who wants a bug fixed needs to file their own feedback report. Don't bother referencing any existing feedback number of any information from anyone else. Post your own report with your own information. If a particular problem has enough duplicate bug reports, and if Apple decides that it actually is something they want to fix, then it might get fixed in a few months.

I'm certainly not a fan of Homebrew. But if this bug is going to get fixed, it will have to be Homebrew that fixes it. Don't wait for Apple.

FWIW, if you want to play the numbers game, in case you weren't aware GitHub enumerates both issues and PR's together. In other words, the homebrew-core repo actually has less than 6000 issues. In a 7-year-old repo project with over 6000 formulae, I don't think this number is as alarming as you make it sound like, especially that many of these are just to track a bug in that upstream project. Sometimes detect the bug to begin with very early on after a new release of that other project or even upstream a patch.

etresoft wrote:

gibfahn wrote:

Sounds like https://github.com/Homebrew/homebrew-core/issues/145991, which has more information.

For those keeping score at home, Github bug numbers are sequential. 😄

FWIW, if you want to play the numbers game, in case you weren't aware GitHub enumerates both issues and PR's together. In other words, the homebrew-core repo actually has less than 6000 issues. In a 7-year-old repo project with over 6000 formulae, I don't think this number is as alarming as you make it sound like, especially that many of these are just to track a bug in that upstream project. Sometimes detect the bug to begin with very early on after a new release of that other project or even upstream a patch.

osalbahr wrote:

FWIW, if you want to play the numbers game, in case you weren't aware GitHub enumerates both issues and PR's together. In other words, the homebrew-core repo actually has less than 6000 issues.

I don't know if 1.9 bugs per day is quite the win you think it is.

In any event, the number of Homebrew bugs doesn't bother me. It is all the posts here in the developer forum from people who are totally lost that bother me. Day in, day out. zsh doesn't work. ls doesn't work. Apache doesn't work. Paths are broken. We can't help because we have no idea how Homebrew has utterly scrambled the system. And even if we did know, we can't explain how to fix it for people who don't know how any of it works. That's why they are using Homebrew in the first place.

etresoft wrote:

osalbahr wrote:

FWIW, if you want to play the numbers game, in case you weren't aware GitHub enumerates both issues and PR's together. In other words, the homebrew-core repo actually has less than 6000 issues.

I don't know if 1.9 bugs per day is quite the win you think it is.

In any event, the number of Homebrew bugs doesn't bother me. It is all the posts here in the developer forum from people who are totally lost that bother me. Day in, day out. zsh doesn't work. ls doesn't work. Apache doesn't work. Paths are broken. We can't help because we have no idea how Homebrew has utterly scrambled the system. And even if we did know, we can't explain how to fix it for people who don't know how any of it works. That's why they are using Homebrew in the first place.

Ok, fair enough, such posts are indeed annoying. It is a fair expectation to comment-out Homebrew’s eval command before making a post. However I think the situation of a breaking upgrade to the linker is different and not exactly specific to Homebrew in that regard, so an Apple discussion post discussing the issue saves time for lots of macOS users, not just Homebrew users.

And I’m curious, seeing how critical you are of Homebrew, how do you propose macOS users should install various command line tools if not using Homebrew?

osalbahr wrote:

It is a fair expectation to comment-out Homebrew’s eval command before making a post. However I think the situation of a breaking upgrade to the linker is different and not exactly specific to Homebrew in that regard, so an Apple discussion post discussing the issue saves time for lots of macOS users, not just Homebrew users.

The linker isn't broken. It's Homebrew that's broken. Xcode 15 and all of the other updates have been available to developers for a few months now. All of us other developers have been testing with it. Why hasn't Homebrew been doing that? The only people's time that this is being saved here is that of Homebrew developers.

I'm not sure what you mean about Homebrew's eval command. That's the point here. All I know about Homebrew is that it is invariably installed when people report basic command line operations mysteriously stop working. And I don't just mean sometimes - I mean every, single, time. It's always Homebrew.

how do you propose macOS users should install various command line tools if not using Homebrew?

Same way it has always been done? Maybe the developer provides an installer. If not, maybe it can be installed from source. Failing that, maybe Homebrew could develop a packaging system to easily install 3rd party command line tools? How come they don't do that? Can you tell me why Homebrew installs tools that are already part of the operating system and corrupts command line environments? Why not just install software? Why not test said software? Why not support their software?

I think I'm expressing some pretty basic expectations. Most other developers test their software. They test installers and uninstallers. They test with new versions of dependencies that users are likely to install, such as the operating system. They try not to corrupt the system. Their support their apps. When developers don't do these things, yeah, I start to get critical.

> The linker isn't broken.

Breaking upgrade != broken. It simply means not backwards compatible.

> Same way it has always been done?

The way “it’s always been done” is through a package manager, such as apt, dnf, pacman, etc. Manually installing from source is very annoying and tedious, but it is fine if you do it only once. The problem is, more often than not, I’d also need to install some of the dependencies from source too, so I resort to build tools like spack.

Depending on your use case, sure, *.dmg files might be sufficient, but that is far from the case for many macOS users. Just look at the numbers. And it is even more if you count installed dependencies, which is the main job of a package manager.

> Failing that, maybe Homebrew could develop a packaging system to easily install 3rd party command line tools? How come they don't do that? Can you tell me why Homebrew installs tools that are already part of the operating system and corrupts command line environments? Why not just install software? Why not test said software? Why not support their software?

Homebrew, in fact, does all of this! To answer your first and main question, one example from the top of my head speedtest.net’s CLI giving instructions to install it, a 3rd party, via Homebrew. There’s also HashiCorp (terraform) maintaining their own Homebrew packages. It is very easy to use 3rd party “taps” and can be done in one command.

I can answer the remaining questions, if you’re interested. Most are easy to find in Homebrew’s website and glancing through the documentation. There seems to be a few misunderstandings, and it seems that Homebrew does not fit your use case so it’s understandable that you don’t know much about its internals.

osalbahr wrote:

> The linker isn't broken.

Breaking upgrade != broken. It simply means not backwards compatible.

Saying "backwards compatible" implies that this is an Xcode problem. It is not. This is 100% a Homebrew problem. Everyone knew that Apple was going to release a new version of Xcode. Homebrew didn't bother to test their software. Homebrew didn't bother to inform their users. Homebrew didn't bother to support their software. They just sat on their bums and assumed that someone else would fix their problems for them - just like they always do.

The way “it’s always been done” is through a package manager, such as apt, dnf, pacman, etc.

Nonsense. Those package managers are strictly a Linux thing. Even on Linux, they are a royal pain. You can never configure two systems the same way and they regularly fail. 

Manually installing from source is very annoying and tedious

Is that another way of saying "correct"?

it is fine if you do it only once.

Or if you need to do it repeatedly, perhaps in a script, and ensure that each installation is identical. 

The problem is, more often than not, I’d also need to install some of the dependencies from source too, so I resort to build tools like spack.

I'm not here to argue about package managers. Homebrew isn't a package manager, it's junk. 

Depending on your use case, sure, *.dmg files might be sufficient

DMG files? What is this, 1998?

Just look at the numbers. And it is even more if you count installed dependencies, which is the main job of a package manager.

This is not a quantitative issue. It is a qualitative issue. The quality of Homebrew is junk. That's the issue.

Homebrew, in fact, does all of this!

Then why are we arguing in a non-Homebrew forum about how Homebrew has neglected to do any of that? This is the Apple Support community, not the Homebrew support community.

I can answer the remaining questions, if you’re interested. Most are easy to find in Homebrew’s website and glancing through the documentation. There seems to be a few misunderstandings, and it seems that Homebrew does not fit your use case so it’s understandable that you don’t know much about its internals.

I am not interested. My questions were obviously rhetorical and satirical. Homebrew is junk. I'm not about to read up on Homebrew so that I can do their tech support for them. That's their job, not mine. My job is to help my fellow Apple users. One way I can do that is to tell them when they've installed some junk software and help them uninstall it. Homebrew is one of the few apps that is of such poor quality that the only way its target customer base can uninstall it is to erase their hard drive and reinstall the operating system. There's no way that I can explain to someone who needed Homebrew in the first place how to fix it. All I can do is tell them how to reset their system and to avoid this kind of junkware in the future.