> On 22 Sep 2023, at 1:27 pm, Christopher Jones <jon...@hep.phy.cam.ac.uk> > wrote: > > > >> On 22 Sep 2023, at 1:09 pm, Carlo Tambuatco <oraclmas...@gmail.com> wrote: >> >> macOS 13.5.2 >> package-id: com.apple.pkg.CLTools_Executables >> version: 15.0.0.0.1.1694021235 >> >> My g++-mp-12 (from gcc version 12) install on macports started giving me >> these errors compiling >> C++ programs after upgrading my XCode command line tools a few days ago. >> >> Is this something macports will address in a future update? > > This indeed looks like an issue introduced with the recent Xcode/CLT update. > > At this time I don’t think anyone can say how it will get addressed, or show > long that might take, as it needs to be determined if this is an bug on > Apple’s side, in Xcode/CLT, a bug in gcc, or just some incompatibility > upstream gcc now needs to address. > > It could also be an issue introduced with how MacPorts builds GCC. I have my > doubts that this could be the case, given how it just appeared with an Xcode > update, but it cannot be ruled out right now.
A quick web search yields a number of reports of this, e.g. https://discussions.apple.com/thread/255137447 so this is I think nothing to do with the MacPorts packing of GCC. Whether its GCC or Xcode at fault remains to be seen. > >> Do I need to reinstall/recompile >> all of macports? > > I doubt that would help. > > Workaround, for now, is to not use gcc to build C++ sources. Clang is anyway > the default compiler on Mac’s, and is what MacPorts uses for the vast > majority of ports, so if you can use clang++ (either Xcode or MacPorts own > builds). Both these are still fine. > > Chris > >> >> -macosx_version_min has been renamed to -macos_version_min >> 0 0x106e2df43 __assert_rtn + 64 >> 1 0x106d2ff43 ld::AtomPlacement::findAtom(unsigned char, unsigned long >> long, ld::AtomPlacement::AtomLoc const*&, long long&) const + 1411 >> 2 0x106d4c431 ld::InputFiles::SliceParser::parseObjectFile(mach_o::Header >> const*) const + 19745 >> 3 0x106d5cb71 ld::InputFiles::parseAllFiles(void (ld::AtomFile const*) >> block_pointer)::$_7::operator()(unsigned long, ld::FileInfo const&) const + >> 657 >> 4 0x7ff80f31d066 _dispatch_client_callout2 + 8 >> 5 0x7ff80f33018f _dispatch_apply_invoke_and_wait + 213 >> 6 0x7ff80f32f692 _dispatch_apply_with_attr_f + 1207 >> 7 0x7ff80f32f847 dispatch_apply + 45 >> 8 0x106df5972 ld::AtomFileConsolidator::parseFiles(bool) + 370 >> 9 0x106d7cd67 main + 12263 >> ld: Assertion failed: (resultIndex < sectData.atoms.size()), function >> findAtom, file Relocations.cpp, line 1336. >> collect2: error: ld returned 1 exit status >