[MacPorts] #69603: gjs @1.80.1: Undefined symbols for architecture x86_64: "std::__1::__libcpp_verbose_abort(char const*, ...)"

[MacPorts]

#69603: gjs @1.80.1: Undefined symbols for architecture x86_64:
"std::__1::__libcpp_verbose_abort(char const*, ...)"
----------------------------+------------------------
  Reporter:  christophecvr  |      Owner:  dbevans
      Type:  defect         |     Status:  reopened
  Priority:  Normal         |  Milestone:
 Component:  ports          |    Version:
Resolution:                 |   Keywords:  highsierra
      Port:  gjs            |
----------------------------+------------------------

Comment (by christophecvr):

 Replying to [comment:26 kencu]:
 > Replying to [comment:21 Dave-Allured]:
 > > >  has duplicate #69603
 > >
 > > Ken, okay.  I do not see how this helps the next guy to find out why
 `gjs` fails on their 10.13 system.  I think either add `gjs` to #68640, or
 else leave this ticket open.  Otherwise there is no ticket seen for 10.13
 on the `gjs` port status page, which is where the casual users go to find
 out.  Search trac history is too much for casual users.  Do you have a
 better idea?
 >
 > sure, add gjs to the other ticket.
 >
 > there will be many more build failures, as this issue relates to how the
 compiler is interacting with the system libc++.dylib on various systems,
 and possibly other issues like the c++ standard being used, whether
 exceptions are in use, etc.
 >
 > IMO this should all be tracked in 1 ticket, but hey, if you want 1,000
 tickets about this issue be my guest.

 Yes but this ticket apart of the error is really different. It might be
 the same source at the end. But in practice : first the other ticket is
 not valid on macos-10.13.6 but looks the be a macos 10.12 issue. It was
 also with clang 17. This problem here occurs with clang 16 and also clang
 15 . Is not there with clang 14. So leave it open then normally there will
 be no new ticket for this issue. Persons can see what to do to solve the
 problem temporarily until definitive fix have been found. But I'm afk that
 the real cause is really the fact that apple does not take care anymore of
 older os the 14+ in clang development and therefore is the use of higher
 clang versions very hazardous(unstable) on not supported os versions. A
 solution can be in the macports is making more use of gnu compiler C and
 g++ if needed for some features in gnu software packages.

-- 
Ticket URL: <https://trac.macports.org/ticket/69603#comment:27>
MacPorts <https://www.macports.org/>
Ports system for macOS