[MacPorts] #69869: kicad @7.0.11: crashes when run

[MacPorts]

#69869: kicad @7.0.11: crashes when run
--------------------------+----------------------
  Reporter:  Gamespeople  |      Owner:  ra1nb0w
      Type:  defect       |     Status:  assigned
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:  2.9.3
Resolution:               |   Keywords:  catalina
      Port:  kicad        |
--------------------------+----------------------

Comment (by cdavis5e):

 I've looked at this, and I think I know what the problem is.

 The crash log obscures the actual problem. The actual problem occurs when
 KiCad is loading the plugin or "KiFace" for the tool that was selected. As
 part of this process, the KiFace attempts to grab the settings object for
 KiCad itself of type `KICAD_SETTINGS`. But the `SETTINGS_MANAGER` object
 stores the settings it knows about as pointers to the base class,
 `JSON_SETTINGS`. In order to return a settings object by type, it must
 `dynamic_cast` each of the pointers until it finds the one the caller is
 looking for. This is where the problem happens.

 In order to perform a `dynamic_cast`, type information is required. The
 Itanium C++ ABI that Darwin uses requires type info data to be unique--
 except, apparently, on Apple Silicon, where Windows-style duplicates are
 tolerated. Because of KiCad's linking model, two copies of the type info
 are present, one in the `kicad` binary itself and the other in the KiFace
 binary. The `KICAD_SETTINGS` object was created by `kicad`, but is being
 accessed by the KiFace. But because the type info pointers don't match,
 the `dynamic_cast` on the correct object fails, so the `SETTINGS_MANAGER`
 is unable to find the object the KiFace is looking for, and thus the
 KiFace throws an exception, which causes KiCad to fail loading the KiFace
 binary and, because it tries to use a null pointer, it crashes.

 It isn't limited to this particular instance. `dynamic_cast`s abound in
 KiCad's source code. All of these are potential land mines waiting to go
 off. The ''right'' solution IMO is to make the KiFaces import symbols from
 the main binary instead of linking in a separate copy of the type info.
 This should be possible since the KiFaces are binaries of type
 `MH_BUNDLE`, which is specifically allowed to import from a main binary,
 though I'm not sure how that would work when embedding with Python. A more
 pragmatic solution for our purposes might be to make the type info symbols
 weak; then, at run time, `dyld(1)` will coalesce them so that there is
 only one instance that is ever referenced. I'll attach a patch that
 implements this latter solution.

 Based on what I said above, I'm guessing that this problem wouldn't show
 up on an Apple Silicon device--that's probably why the KiCad devs never
 caught it.

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