libfilezilla @0.32.0: link fails for 10.7 thru 10.12: undefined symbols for std::bad_variant_access

[mascguy (Christopher Nielsen)]

Details:

Undefined symbols for architecture x86_64:
  "typeinfo for std::bad_variant_access", referenced from:
      std::__1::__throw_bad_variant_access() in libfilezilla_la-json.o
  "vtable for std::bad_variant_access", referenced from:
      std::__1::__throw_bad_variant_access() in libfilezilla_la-json.o
  NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
ld: symbol(s) not found for architecture x86_64

​https://ports.macports.org/port/libfilezilla/details/

Based on the logs, it looks like the cxx standard is properly set to 2017 during compilation. And 2017-compliant compilers are also being requested by the port.

Would this be fixable via macports-libcxx? Or is there a preferred fix...?

[kencu (Ken)]

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.

[barracuda156]

Replying to 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 would 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.

Thank you! I will try that.

Seen this error with some other ports too, for instance spot: ​https://build.macports.org/builders/ports-10.8_x86_64-builder/builds/133092/steps/install-port/logs/stdio

[barracuda156]

Ok let me return to this in coming days.