gst-plugins-good @0.10.15 doesn't build on Snow Leopard

[arolsen@…]

--->  Building gst-plugins-good
Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_gnome_gst-plugins-good/work/gst-plugins-good-0.10.15" && /usr/bin/make -j2 all " returned error 2
Command output: Making all in goom
  CC    gstgoom.o
  CC    drawmethods.o
  CC    sound_tester.o
  CC    mathtools.o
  CC    lines.o
  CC    ifs.o
  CC    surf3d.o
  CC    tentacle3d.o
  CC    v3d.o
  CC    convolve_fx.o
  CC    flying_stars_fx.o
  CC    plugin_info.o
  CC    goom_tools.o
  CC    config_param.o
  CC    filters.o
  CC    goom_core.o
  CC    graphic.o
  CC    mmx.o
/var/tmp//ccrRArkJ.s:47:suffix or operands invalid for `push'
/var/tmp//ccrRArkJ.s:49:suffix or operands invalid for `pop'
/var/tmp//ccrRArkJ.s:52:suffix or operands invalid for `push'
/var/tmp//ccrRArkJ.s:55:suffix or operands invalid for `pop'
/var/tmp//ccrRArkJ.s:166:suffix or operands invalid for `pop'
/var/tmp//ccrRArkJ.s:233:`(%r12,%r10d,4)' is not a valid base/index expression
/var/tmp//ccrRArkJ.s:253:`(%r12,%r10d,4)' is not a valid base/index expression
make[3]: *** [libgstgoom_la-mmx.lo] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Error: Status 1 encountered during processing.

[arolsen@…]

Cc Me!

[ian@…]

Cc Me!

[rmsfisher@…]

A much better problem has surfaced after disabling the "goom" plugin with its grumpy mmx assembly code. The "goom2k1" plugin remains, despite goom's current "goom2k4" incarnation being stagnant since 2005. Please test against r58768 for future work pertaining to this bug; it hardly makes sense to solve a problem with 0.10.15 when 0.10.16 is the current release version.

[jeptorra@…]

Cc Me!

[jeptorra@…]

The root cause of this issue is comming from --build= --host= --target= values received in configure. Current values make gst-arch.m4 enable 32bits assembly code while the compiler is producing 64bits. This issue is spread in all gstreamer packages because the macro in common/m4/gst-arch.m4 is shared. I've been able to build gstreamer core from git by hand with the following configure line:

./configure --prefix=/opt/local --build=x86_64-apple-darwin10.0.0

It produced the following lines in config.h:

/* Define if the host CPU is an Alpha */
/* #undef HAVE_CPU_ALPHA */

/* Define if the host CPU is an ARM */
/* #undef HAVE_CPU_ARM */

/* Define if the host CPU is a CRIS */
/* #undef HAVE_CPU_CRIS */

/* Define if the host CPU is a CRISv32 */
/* #undef HAVE_CPU_CRISV32 */

/* Define if the host CPU is a HPPA */
/* #undef HAVE_CPU_HPPA */

/* Define if the host CPU is an x86 */
/* #undef HAVE_CPU_I386 */

/* Define if the host CPU is a IA64 */
/* #undef HAVE_CPU_IA64 */

/* Define if the host CPU is a M68K */
/* #undef HAVE_CPU_M68K */

/* Define if the host CPU is a MIPS */
/* #undef HAVE_CPU_MIPS */

/* Define if the host CPU is a PowerPC */
/* #undef HAVE_CPU_PPC */

/* Define if the host CPU is a 64 bit PowerPC */
/* #undef HAVE_CPU_PPC64 */

/* Define if the host CPU is a S390 */
/* #undef HAVE_CPU_S390 */

/* Define if the host CPU is a SPARC */
/* #undef HAVE_CPU_SPARC */

/* Define if the host CPU is a x86_64 */
#define HAVE_CPU_X86_64 1

I'm new in mac world/macports. I think that the fix is provide proper build/host/target values to ./configure, are current values comming from the portfile ?

Or are those values global for all macports?

[jeptorra@…]

I've added the following lines to the end of the Portfile and fixes the 64 bits arch detection in snow leopard. Not sure if this can cause any side effect, I'm unable to test on other scenarios.

Build of 32 bits tree in snow leopard failed due some perl related bugs.

platform darwin i386 {
        configure.args-append --build=${build_arch}-apple-darwin${os.major}
}

I've been trying build with the portfiles that are in trunk using a local portfile repository, unfortunelly I've got the following errors:

Making all in osxaudio
  CC    gstosxringbuffer.o
  CC    gstosxaudioelement.o
gstosxringbuffer.c: In function 'gst_osx_ring_buffer_create_audio_unit':
gstosxringbuffer.c:151: error: 'ComponentDescription' undeclared (first use in this function)
gstosxringbuffer.c:151: error: (Each undeclared identifier is reported only once
gstosxringbuffer.c:151: error: for each function it appears in.)
gstosxringbuffer.c:151: error: expected ';' before 'desc'
gstosxringbuffer.c:152: error: 'Component' undeclared (first use in this function)
gstosxringbuffer.c:152: error: expected ';' before 'comp'
gstosxringbuffer.c:153: warning: ISO C90 forbids mixed declarations and code
gstosxringbuffer.c:166: error: 'desc' undeclared (first use in this function)
gstosxringbuffer.c:172: error: 'comp' undeclared (first use in this function)
gstosxringbuffer.c:172: warning: implicit declaration of function 'FindNextComponent'
gstosxringbuffer.c:178: warning: implicit declaration of function 'OpenAComponent'
gstosxringbuffer.c:192: warning: implicit declaration of function 'CloseComponent'
gstosxringbuffer.c:193: warning: format '%lx' expects type 'long unsigned int', but argument 8 has type 'OSStatus'
gstosxringbuffer.c:204: warning: format '%lx' expects type 'long unsigned int', but argument 8 has type 'OSStatus'
gstosxringbuffer.c:216: warning: format '%lx' expects type 'long unsigned int', but argument 8 has type 'OSStatus'
gstosxringbuffer.c: In function 'gst_osx_ring_buffer_open_device':
gstosxringbuffer.c:253: warning: format '%lx' expects type 'long unsigned int', but argument 8 has type 'OSStatus'
gstosxringbuffer.c: In function 'gst_osx_ring_buffer_acquire':
gstosxringbuffer.c:402: warning: format '%lx' expects type 'long unsigned int', but argument 8 has type 'OSStatus'
gstosxringbuffer.c:410: warning: format '%lx' expects type 'long unsigned int', but argument 8 has type 'OSStatus'
gstosxringbuffer.c:427: warning: format '%lx' expects type 'long unsigned int', but argument 8 has type 'OSStatus'
gstosxringbuffer.c: In function 'gst_osx_ring_buffer_start':
gstosxringbuffer.c:548: warning: format '%lu' expects type 'long unsigned int', but argument 9 has type 'AudioDeviceID'
gstosxringbuffer.c: In function 'gst_osx_ring_buffer_pause':
gstosxringbuffer.c:593: warning: format '%lu' expects type 'long unsigned int', but argument 9 has type 'AudioDeviceID'
gstosxringbuffer.c: In function 'gst_osx_ring_buffer_stop':
gstosxringbuffer.c:614: warning: format '%lu' expects type 'long unsigned int', but argument 9 has type 'AudioDeviceID'
make[3]: *** [libgstosxaudio_la-gstosxringbuffer.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
  CC    gstosxaudiosink.o
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

[rmsfisher@…]

A little (possible) progress but still no complete build. This stuff is really over my head, so if the thing I did to get a few lines farther is stupid let me know.

[rmsfisher@…]

Updated Build Log

[neric27@…]

Hi, there seems to be a lot of osx-related activity in git : ​http://cgit.freedesktop.org/gstreamer/gst-plugins-good/log/

this one : "osxaudio: Fixes build on macosx snow leopard." is actually the patch-sys-osxaudio-gstosxringbuffer.c.diff.

[jeptorra@…]

Finally I've got it fixed.

I'm attaching my portfile and patches. I've did some changes in the portfile that should be tested in other platforms.

[jeptorra@…]

Portfile for -good

[jeptorra@…]

patch to add missing include file

[jeptorra@…]

patch to add missing lib in Makefile.am

[jeptorra@…]

I've added git variant too. I don't know if you want add it too and which is the common name you use (trunk, unstable?)

As we patch makefile.am it's needed run autogen.sh

The patch for configure is not necessary as ximagesink can be specified with a configure flag.

I'm also attaching core/base Portfiles, but not related to this bug specifically.

[jeptorra@…]

Portfile for core

[jeptorra@…]

Portfile for -base

[mf2k (Frank Schima)]

gst-plugins-good committed in r59177. I left out the git variant, instead it should be handled in a new -devel port.

[mf2k (Frank Schima)]

Replying to jeptorra@…:

I'm also attaching core/base Portfiles, but not related to this bug specifically.

Can you explain the purpose of these changes please? I'm hesitant to commit them.

[jeptorra@…]

Replying to macsforever2000@…:

Replying to jeptorra@…:

I'm also attaching core/base Portfiles, but not related to this bug specifically.

Can you explain the purpose of these changes please? I'm hesitant to commit them.

I was providing those for the git variant.

I've been trying the suggested idea of new -devel port and I found this less flexible than having a variant.

I mean that for example if I want mix core/base unstable with good/bad/ugly stable. I can do that with variants but not with different portfiles. Unfortunatelly good/bad/ugly from git is not finishing the build due something strange in the translations. I will try to fix it in next session.

Current status is:

core/base/good/ugly all warnings fixed in SL bad 3 warning sets remaining, I couldn't fix those before the freeze All Quicktime based elements won't work due 64bis is not supported and need to be rewritten in something called QT Kit, this task is out of my scope so probably I won't be able fix it.

[rmsfisher@…]

Gst-plugins-good 0.10.16 is now current and works for me. If one or more of y'all could confirm that it is working I will close this ticket. If the Quicktime-related issues still exist those could be moved to a more specific (and upstream version independent) ticket.

[rmsfisher@…]

After 7 days without feedback gst-plugins-good is still working. I'm closing the ticket.