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

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.

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. 😄

Build gcc without homebrew, reproduce the issue with that build, and then report the crash to the gcc maintainers.

Or build and test with clang, as an alternative.

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

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.

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.

You have duplicate libraries specified on the ld command underneath the g++ command.

What is the output of the following command:

g++ --version

Are you intending to use gcc here, or clang?

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.

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. 😄

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.

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.