#59058 closed defect (fixed)
tkdnd @2.9+quartz: error: ARC forbids Objective-C objects in struct
Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | MarcusCalhoun-Lopez (Marcus Calhoun-Lopez) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.5.99 |
Keywords: | Cc: | chrstphrchvz (Christopher Chavez) | |
Port: | tkdnd |
Description
tkdnd @2.8+quartz could build just fine, and at least some parts of the demo scripts were working too. This changed in port version "2.9" (which is actually source version 2.9.1; I don't understand why these two versions don't match). Now, the +quartz variant does not build, at least not on macOS High Sierra:
/opt/local/include/tkMacOSXInt.h:62:13: error: ARC forbids Objective-C objects in struct NSView *view; ^ 1 error generated.
Here's what happened, as best I can determine.
tkdnd has a configure script and a CMakeLists.txt. For whatever reason, we are using the latter in MacPorts.
In version 2.8:
The configure script checks if building for Quartz, and if so, it adds the -fobjc-gc
flag to specify that memory should be managed using garbage collection.
The CMakeLists.txt unconditionally uses -fobjc-gc
and also -fno-objc-arc
to explicitly disable the competing memory management method known as automatic reference counting. There is also a commented-out line for adding -fobjc-arc
, which would enable automatic reference counting, presumably something the developer had not finished implementing or testing at the time. I don't know why the CMakeLists.txt doesn't restrict this to Quartz only like the configure script does. The Portfile uses a patch and a reinplace to make this whole block only take effect when building for Quartz.
The Portfile also uses a patch and a reinplace to remove the -fobjc-gc
flag for macOS 10.12 and later, presumably because that is the OS version in which the old deprecated garbage collection method was removed from the Objective-C runtime. So for tkdnd 2.8 on 10.12 and later, garbage collection is not being used, but neither is automatic reference counting. In the absence of both of these automatic methods, presumably tkdnd should be managing its memory manually, but I don't know if it does so. (Or maybe the compiler automatically uses ARC on newer systems? I don't know.)
In source version 2.9.1:
The configure script was changed to check the macOS version, and if it's 10.7 or later, it uses automatic reference counting (-fobjc-arc
), otherwise it uses garbage collection (-fobjc-gc
).
This same change was not made in CMakeLists.txt. It still unconditionally uses -fobjc-gc
. But the commented-out line adding -fobjc-arc
was uncommented, so now the CMakeLists.txt adds the flags -fobjc-gc -fobjc-no-arc -fobjc-arc
. This is nonsense: ARC and GC are competing memory management methods; you can only have one or the other.
I don't think that the above changes were noticed when the port was updated to "2.9" (2.9.1) so the necessary changes were not made to the port and its patches to accommodate them.
Based on the inconsistencies between configure and CMakeLists.txt and the senselessness of specifying contradictory options, I would guess the developer does not have a good understanding of memory management on macOS and may need some help from us.
The developer has noted in issues on his issue tracker that choosing whether to use ARC or GC based on the OS version is wrong. What actually matters is whether the Tk that will be used was compiled with ARC or GC. The CMakeLists.txt is set up to try to use either ActiveTcl or Apple's Tcl, whichever it finds. We patch it to use MacPorts Tcl instead. So perhaps we can find out whether our Tk is built with ARC or GC (and whether that varies based on OS version) and make tkdnd use the same choice. Ideally the tkdnd build system would check whether Tk is using ARC or GC, but I don't know how it could do that.
Change History (3)
comment:1 Changed 5 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
In 3dd0bfb44f73de4f8bd29856dad484b9a1824ba3/macports-ports (master):