[MacPorts] #73696: poppler @26.02.0_0: Undefined symbols __ZN5GpgME4Data8toStringB5cxx11Ev __ZNK5GpgME5Error11asStdStringB5cxx11Ev

[MacPorts]

#73696: poppler @26.02.0_0: Undefined symbols __ZN5GpgME4Data8toStringB5cxx11Ev
__ZNK5GpgME5Error11asStdStringB5cxx11Ev
-------------------------+-------------------------------------------------
  Reporter:              |      Owner:  dbevans
  jrandall814            |
      Type:  defect      |     Status:  assigned
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:  2.12.4
Resolution:              |   Keywords:  lion mountainlion mavericks
      Port:  poppler     |  yosemite elcapitan sierra highsierra mojave
-------------------------+-------------------------------------------------

Comment (by PotMJ):

 Replying to [comment:33 rmottola]:
 > Then I tried adapting   @potmj script.
 > I just extracted the patching part in a file. So I could run it once
 upgrade fails & re-run it.
 > Remove the GCC patch of course.
 >

 Apologies for not replying sooner, but I have been deeply focused on
 `libcxx` bootstrap issues and do not expect to revisit `poppler` in the
 immediate future.

 Thank you for looking at my Portfile solution. However, the Portfile and
 upstream poppler version moved on right around the time I submitted my
 10.11 fix.  The Portfile currently relies on some quite heavy translations
 to roll back modern C23 coding conventions that are simply not supported
 by the older compilers suited to 10.11.

 My solution focused on providing a `+universal` solution.  Because
 `poppler` is a foundation library, I feel libraries should be built to
 match the multi-architecture layout shipped with the OS itself whenever
 possible.  There are known shortcomings with the `i386` C++ runtime
 support on 10.11, so a methodology was developed specifically to work
 around those missing system hooks.  The ideas or code snippets might be
 able to be applied by others in situations where there are only a few
 holes in the `i386` support,  blocking `+universal` builds.  This was one
 of the drivers behind the publishing of the Portfile.

 I worry that my initial approach was a bit of a "whack-a-mole" strategy.
 Although it successfully produced a functional `+universal` installation
 for me on 10.11 at the time, as the upstream poppler code continues to
 advance, more C23 dependencies will inevitably keep appearing.

 I wonder if the sustainable path forward is, in fact, to utilize `gcc15`
 configured with `-stdlib=libc++` to leverage the modern Clang runtime
 library for final application compatibility. The only other choice going
 forward is to force an incredibly heavy, modern Clang bootstrap.
 Ultimately, `gcc15` might provide superior `+universal` cross-compilation
 stability by making fewer broken architecture demands on the baseline
 `libc++` layer.

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