Opened 3 months ago

Last modified 3 months ago

#65778 assigned defect

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

Reported by: mascguy (Christopher Nielsen) Owned by: mascguy (Christopher Nielsen)
Priority: Normal Milestone:
Component: ports Version: 2.7.2
Keywords: Cc: barracuda156, lhaeger (Lothar Haeger)
Port: libfilezilla

Description

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...?

Change History (2)

comment:1 Changed 3 months ago by jmroot (Joshua Root)

Cc: lhaeger added

comment:2 Changed 3 months ago by 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 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.

Last edited 3 months ago by kencu (Ken) (previous) (diff)
Note: See TracTickets for help on using tickets.