[MacPorts] #65778: libfilezilla @0.32.0: link fails for 10.7 thru 10.12: undefined symbols for std::bad_variant_access

[MacPorts]

#65778: libfilezilla @0.32.0: link fails for 10.7 thru 10.12: undefined symbols for
std::bad_variant_access
---------------------------+----------------------
  Reporter:  mascguy       |      Owner:  mascguy
      Type:  defect        |     Status:  assigned
  Priority:  Normal        |  Milestone:
 Component:  ports         |    Version:  2.7.2
Resolution:                |   Keywords:
      Port:  libfilezilla  |
---------------------------+----------------------

Comment (by kencu):

 if libfilezilla doesn’t use exceptions in the code, then explicitly
 turning exceptions off with -f flag that disables them should fix this. No
 exceptions, no throws, so no missing throw function. Code errors will
 abort instead of throwing an exception.

 if it does use exceptions, then macports-libcxx woulld be plan B. Slightly
 riskier, and possibly Filezilla might need to use it too if they share a
 lot of objects back and forth. Have to test that to see if it crashes.

 Longer-term, there are currently three c++17 headers that throw, and all
 are broken on 10.7 to 10.12 as libcxx there does not have the symbols
 (although 10.5 and 10.6 are OK as they use a newer libcxx), and none of
 this applies to libgcc so that route is available.

 These missing libcxx functions could most easily probably be  static
 inlined into the three headers on 10.7 through 10.12, or might be added to
 compiler_rt in clang to provide them… both of those would be fairly easy
 projects for someone interested. Easy to implement, easy to test.

 It is also conceivable that filesystem from the libcxx subproject could be
 added to compiler_rt as well on those systems, but with more work and
 testing needed there to be sure everything filesystem needs from libcxx
 can be found in the system libcxx.

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