[MacPorts] #59805: FileZilla @3.46.0: fatal error: 'optional' file not found

[MacPorts]

#59805: FileZilla @3.46.0: fatal error: 'optional' file not found
-------------------------+----------------------
  Reporter:  ryandesign  |      Owner:  lhaeger
      Type:  defect      |     Status:  assigned
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:  2.6.2
Resolution:              |   Keywords:
      Port:  FileZilla   |
-------------------------+----------------------

Comment (by kencu):

 We can in fact update the older `libc++` on older systems that came with
 libc++ by using the `+replacement_libcxx` variant of `libcxx`. It is not
 well tested -- I have never done it -- but Jeremy put it there for this
 reason.

 I have a personal `libcxx` port that uses the libc++ from clang/llvm 7.0,
 which is quite new, and a newer one than that is probably possible as
 well. Libc++ builds when we build clang, and new versions of clang build
 on 10.5 up, so it's just a matter of making it all happen.

 I'm not sure if that would install any newer headers though. The usual way
 of getting new headers is to use a newer clang version from macports-
 clang-*.

 This can be a bit complicated, as sometimes the version of `libc++` is
 tested for in the headers, and various pathways are followed depending on
 the version found, so it's not just obvious that newer headers gives you
 all the newer functionality.

 I would like to explore how to use a different `libc++.dylib` for
 MacPorts-installed software, kind of like we do now for libstdc++.dylib
 using `gcc`. This new updated version of libc++.dylib could be installed
 in `${prefix}/lib` for example, and software linked against it. There are
 some features in the newer-libc++-supported c++17 <filesystem> that we
 would need to support on older systems using this method. None of this is
 presently tested at all.

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