gstreamer1-gst-plugins-base @1.14.1 +universal: error: -fobjc-arc is not supported on platforms using the legacy runtime

[ryandesign (Ryan Carsten Schmidt)]

​https://build.macports.org/builders/ports-10.9_x86_64-builder/builds/56873/steps/install-dependencies/logs/stdio

error: -fobjc-arc is not supported on platforms using the legacy runtime

As the error message says, Objective-C Automatic Reference Counting requires 64-bit. But gstreamer1-gst-plugins-base is a dependency of wine which requires 32-bit.

[ryandesign (Ryan Carsten Schmidt)]

I don't know why yet, but this appears to only affect El Capitan and earlier. It built universal successfully on Sierra and High Sierra.

[ryandesign (Ryan Carsten Schmidt)]

With 1.14.1, it now appears to affect only Mavericks and Yosemite, not earlier or later versions.

[docprofsky (Schuyler St. Leger)]

On Yosemite, this happens when building this with the +ogg +universal +x11 variants, but removing the +universal variant avoids the error. It may be related to trying to build for PowerPC.

[ryandesign (Ryan Carsten Schmidt)]

Replying to docprofsky:

removing the +universal variant avoids the error.

Correct.

It may be related to trying to build for PowerPC.

No, it's related to building for i386 (the 32-bit Intel "legacy runtime", as this error message calls it). -fobjc-arc is only supported on x86_64 (64-bit Intel).

[Ionic (Mihai Moldovan)]

This is pretty bad.

The code ​was recently updated to use ARC (+ later fixups injecting -fobjc-arc where needed).

Given that the changes are quite invasive, there doesn't seem to be a way to revert back to the non-ARC behavior without maintaining a custom patchset. We really don't want that.

Since gstreamer is a dependency of wine and the 32bit version is highly useful, we're in a kind of stalemate situation.

Replying to ryandesign:

With 1.14.1, it now appears to affect only Mavericks and Yosemite, not earlier or later versions.

I wonder why that is. Did Apple actually implement ARC for x86 in newer versions? Why does it seem to work there? Can you find that out?

[ryandesign (Ryan Carsten Schmidt)]

Replying to Ionic:

The code ​was recently updated to use ARC (+ later fixups injecting -fobjc-arc where needed).

Replying to ryandesign:

With 1.14.1, it now appears to affect only Mavericks and Yosemite, not earlier or later versions.

I wonder why that is. Did Apple actually implement ARC for x86 in newer versions? Why does it seem to work there? Can you find that out?

All of the files changed by the above commit are in directories named "gl". Is it possible that these GL features are only used on some systems? Is it possible to disable the GL features on all systems and thus avoid the problematic code?

[Ionic (Mihai Moldovan)]

Replying to ryandesign:

Replying to Ionic:

Replying to ryandesign:

With 1.14.1, it now appears to affect only Mavericks and Yosemite, not earlier or later versions.

I wonder why that is. Did Apple actually implement ARC for x86 in newer versions? Why does it seem to work there? Can you find that out?

FWIW, I looked around on a 10.13 machine and libarclite was x86_64-only there, too. I don't understand why it would have worked +universal on that platform. Maybe you didn't look correctly or didn't actually build it +universal?

All of the files changed by the above commit are in directories named "gl". Is it possible that these GL features are only used on some systems? Is it possible to disable the GL features on all systems and thus avoid the problematic code?

Good question. We could --disable-opengl, but that would also disable OpenGL if +x11 was used. Instead, I'd --disable-cocoa.

I haven't noticed that before, but for Darwin < 13 we already pass --disable-cocoa --disable-opengl, which explains why it worked for older versions.

I think we should add a cocoa variant and make that conflicting with universal, enable it by default + disable/not offer it on systems not supporting ARC (so... anything prior 10.6?)

[Ionic (Mihai Moldovan)]

This seems to work around the issue and provide a cleanish upgrade path without manual user intervention:

gnome/gstreamer1-gst-plugins-base/Portfile

@@ -51 +51 @@
                     --disable-ivorbis \
                     --disable-x \
                     --disable-xvideo \
+                    --disable-cocoa \
                     --disable-xshm
 
 #gstbasetextoverlay.c:1511: error: 'for' loop initial declaration used outside C99 mode
@@ -63 +64 @@
     if {${os.major} < 10 } {
         depends_lib-delete port:graphene
     }
-    if {${os.major} < 13 } {
-        configure.args-append   --disable-cocoa --disable-opengl
-    }
 }
 
 variant x11 {
@@ -102 +100 @@
     configure.args-delete --disable-cdparanoia
 }
 
+variant cocoa conflicts universal description {Add support for native Cocoa output. Only supported for pure x86_64 builds.} {
+    if {${os.major} < 10} {
+        ui_error "The variant cocoa is not supported on platforms older than 10.6"
+        error "Platform too old to support Cocoa output"
+    }
+
+    configure.args-replace  --disable-cocoa \
+                            --enable-cocoa
+}
+
+if {${os.major} >= 10 && ![variant_isset universal] && ${build_arch} eq "x86_64"} {
+    default_variants +cocoa
+}
+
 #-fgcse (from -O2) causes build failures, but -O2 -fno-gcse doesn't seem to work
 if {[string match "*gcc-4.2" ${configure.compiler}]} {
     lappend merger_configure_cflags(i386) -O1 -fexpensive-optimizations

We'll lose Cocoa output on non-x86_64 platforms and for +universal builds, but retain OpenGL support via X11.

Interestingly, -fobjc-arc will still be used when building the OpenGL plugin, but that doesn't seem to have adverse effects if ARC is not actually used in the code.

I'll commit it myself, just throwing it in here for review first.

[ryandesign (Ryan Carsten Schmidt)]

Replying to Ionic:

FWIW, I looked around on a 10.13 machine and libarclite was x86_64-only there, too. I don't understand why it would have worked +universal on that platform. Maybe you didn't look correctly or didn't actually build it +universal?

The build failures occurred on the buildbot, which was building gstreamer1-gst-plugins-base universal as a dependency of wine. You can see in the ​packages directory that binaries didn't get produced with the universal variant for darwin 13 and 14.

I think we should add a cocoa variant and make that conflicting with universal, enable it by default + disable/not offer it on systems not supporting ARC (so... anything prior 10.6?)

It seems that full ARC support is available on 10.7 and later while 10.6 only has "ARCLite". Apparently the difference is that ARCLite does not have zeroing weak references. I don't know whether that difference is important to gstreamer1-gst-plugins-base but we can try it out.

ARC is also only supported on x86_64 so in addition to conflicting with the universal variant you would want to verify that configure.build_arch is x86_64.

[Ionic (Mihai Moldovan)]

Replying to ryandesign:

The build failures occurred on the buildbot, which was building gstreamer1-gst-plugins-base universal as a dependency of wine. You can see in the ​packages directory that binaries didn't get produced with the universal variant for darwin 13 and 14.

Yes, that makes perfect sense, but I wasn't talking about Darwin 13 and 14. The buildbot infrastructure did produce +universal builds for Darwin 15, 16 and 17 and I don't understand how that would have worked in the first place. I suspect that Cocoa support was determined as unavailable by configure (since we [incorrectly] don't use --enable-cocoa as the default configure option and configure defaults to an enable-if-available-otherwise-disable autodetection if a parameter is not explicitly provided), which lead to the problematic code being skipped.

We were already explicitly disabling Cocoa support for platforms < Darwin 13, so that explains why we have +universal builds for such older systems.

It seems that full ARC support is available on 10.7 and later while 10.6 only has "ARCLite". Apparently the difference is that ARCLite does not have zeroing weak references. I don't know whether that difference is important to gstreamer1-gst-plugins-base but we can try it out.

Probably not. If it is, we can still adjust the checks.

ARC is also only supported on x86_64 so in addition to conflicting with the universal variant you would want to verify that configure.build_arch is x86_64.

Yeah, I'm doing exactly this (well, using ${build_arch} instead of ${configure.build_arch}). Did you miss my patch-for-review in the latest comment?

[ryandesign (Ryan Carsten Schmidt)]

Replying to Ionic:

The buildbot infrastructure did produce +universal builds for Darwin 15, 16 and 17 and I don't understand how that would have worked in the first place.

I haven't attempted to figure it out.

ARC is also only supported on x86_64 so in addition to conflicting with the universal variant you would want to verify that configure.build_arch is x86_64.

Yeah, I'm doing exactly this (well, using ${build_arch} instead of ${configure.build_arch}). Did you miss my patch-for-review in the latest comment?

It did see the patch. I did not see the part where you were checking build_arch. Now that I see it, I note that it is only in the block of code that chooses whether to enable the variant by default. It is not in the variant itself. It would still be possible for a user on 32-bit 10.6 to select the variant manually, which will result in a build failure.

[Ionic (Mihai Moldovan)]

Great catch, thanks. It's always good to have another set of eyes going through stuff...

[Mihai Moldovan <ionic@…>]

In 198cb4c00060f094569593057e41064b1e3d7346/macports-ports (master):

gnome/gstreamer1-gst-plugins-base: add new cocoa variant, enabled by default if supported.

Fixes: #56495

Cocoa support is only building successfully on ARC-enabled platforms
and, by virtue of this, only on x86_64.

Upgrading should be seamless, the variant is added by default if
supported.