There are a couple of other issues that affect building on OS X 10.6:

* There are two #if GST_GL_HAVE_OPENGL blocks that contain code using OpenGL 3.2 constants; these guards should also ensure that those constants are available (again, I believe they were added in 10.7). The blocks in question are in gst-libs/gst/gl/gstglcolorconvert.c, line 990; and gst-libs/gst/gl/gstglcontext.c, line 584.

* tests/examples/gl/cocoa/Makefile.am uses -Wno-error=unused-command-line-argument, which is not a valid option in the version of gcc shipped with 10.6 (I know I said I was using gcc 5.2.0, but I had to abandon that due to not supporting Objective-C's block syntax).

Inelegantly bashing my way through those issues, and the original reported error, resulted in a successful build.

Do you want to provide a patch for this? Not sure if we want to continue supporting 10.6 at this point, many interesting features are just not available there.

Created attachment 313790 [details] [review]
Hack around various compilation errors on OS X 10.6

... is any of this reasonable?

Review of attachment 313790 [details] [review]:

Looks mostly ok.

Just some suggestions for consistency with the rest of the codebase.

::: configure.ac
@@ +408,3 @@
+AS_OBJC_COMPILER_FLAG([-Wunused-command-line-argument],
+    [UNUSED_COMMAND_LINE_ARGUMENT_FLAG_SUPPORTED=yes])
+AC_SUBST(UNUSED_COMMAND_LINE_ARGUMENT_FLAG_SUPPORTED)

Make this an automake substitution instead of an autoconf one.

i.e AM_CONDITIONAL(UNUSED_COMMAND_LINE_ARGUMENT_FLAG_SUPPORTED, test "x$UNUSED_COMMAND_LINE_ARGUMENT_FLAG_SUPPORTED" = "xyes")

::: gst-libs/gst/gl/gstglcolorconvert.c
@@ +988,3 @@
   gboolean in_tex_rectangular = FALSE;
 
+#if GST_GL_HAVE_OPENGL && defined(GL_TEXTURE_RECTANGLE)

I would prefer

#ifndef GL_TEXTURE_RECTANGLE
#define GL_TEXTURE_RECTANGLE 0x84F5
#endif

at the top of the file.

Assuming that 10.6 has texture rectangle support as GL_TEXTURE_RECTANGLE_ARB so we can still get zerocopy with vtdec.

::: gst-libs/gst/gl/gstglcontext.c
@@ +582,3 @@
         goto next;
 
+#if GST_GL_HAVE_OPENGL && defined(GL_CONTEXT_PROFILE_MASK)

Again

#ifndef GL_CONTEXT_PROFILE_MASK
...

probably also needed for GL_CONTEXT_CORE_PROFILE_BIT and GL_CONTEXT_COMPATIBILITY_PROFILE_BIT as well.

::: tests/examples/gl/cocoa/Makefile.am
@@ +5,3 @@
 cocoa_videooverlay_SOURCES = cocoa-videooverlay.m
 
+cocoa_videooverlay_OBJCFLAGS=$(if @UNUSED_COMMAND_LINE_ARGUMENT_FLAG_SUPPORTED@,-Wno-error=unused-command-line-argument) \

It would probably make more sense to do (with the AM_CONDITIONAL in configure.ac):

cocoa_videooverlay_OBJCFLAGS = ...
if UNUSED_COMMAND_LINE_ARGUMENT_FLAG_SUPPORTED
cocoa_videooverlay_OBJCFLAGS += -Wno-error=unused-command-line-argument
endif

Thanks for the feedback! What's the best way for me to test that the plugins actually still work as intended with the new #defines?

Some example gst-launch lines that should cover these cases.

gst-launch-1.0 videotestsrc ! glimagesink
gst-launch-1.0 videotestsrc ! x264enc ! h264parse ! vtdec ! glimagesink
gst-launch-1.0 uridecodebin uri=file:///path/to/some/file ! glimagesink

Created attachment 314034 [details] [review]
Fix (partial?) for compilation/runtime errors on OS X 10.6

Okay, this is what I have so far. The glimagesink doesn't seem to be working properly for me, unfortunately, but at least it compiles and runs without crashing now.

The remaining problem is that the glimagesink window doesn't update itself as the video plays. As soon as it opens, it's filled with random noise or with image fragments that look like other parts of my screen, which remains static. Resizing the window causes it to redraw correctly, but only once per resize event; as soon as I stop dragging the image remains frozen on the previous frame. Any ideas about what this might be? I'm afraid I don't have any OpenGL programming experience.

I don't really think it makes sense to support a 7-year old OS with modern applications at this point.