gstreamer1-gst-plugins-base 1.14.4: fails to build with +universal

[thetrial (alabay)]

gstreamer1-gst-plugins-base fails to build under El Capitan. Due to an OS-Update I completely rebuilt my installation to avoid any incompatibilities, but at this point macports hangs. I guess this is in connection with wine-devel I use.

I’ll attach the logfile.

[thetrial (alabay)]

Logfile

[Schamschula (Marius Schamschula)]

You don't need to CC yourself. You get emailed as the ticket reporter.

The problem seems to be that your machine is looking for the sse2 extension, but it is not available on your machine.

[mf2k (Frank Schima)]

Error appears to be:

:info:build libtool: link: ccache /usr/bin/clang -dynamiclib  -o .libs/libgstaudio-1.0.0.dylib  .libs/libgstaudio_1.0_la-audio.o .libs/libgstaudio_1.0_la-audio-format.o .libs/libgstaudio_1.0_la-audio-channels.o .libs/libgstaudio_1.0_la-audio-channel-mixer.o .libs/libgstaudio_1.0_la-audio-converter.o .libs/libgstaudio_1.0_la-audio-info.o .libs/libgstaudio_1.0_la-audio-quantize.o .libs/libgstaudio_1.0_la-audio-resampler.o .libs/libgstaudio_1.0_la-gstaudioaggregator.o .libs/libgstaudio_1.0_la-gstaudioringbuffer.o .libs/libgstaudio_1.0_la-gstaudioclock.o .libs/libgstaudio_1.0_la-gstaudiocdsrc.o .libs/libgstaudio_1.0_la-gstaudiodecoder.o .libs/libgstaudio_1.0_la-gstaudioencoder.o .libs/libgstaudio_1.0_la-gstaudiobasesink.o .libs/libgstaudio_1.0_la-gstaudiobasesrc.o .libs/libgstaudio_1.0_la-gstaudiofilter.o .libs/libgstaudio_1.0_la-gstaudiometa.o .libs/libgstaudio_1.0_la-gstaudiosink.o .libs/libgstaudio_1.0_la-gstaudiosrc.o .libs/libgstaudio_1.0_la-gstaudioutilsprivate.o .libs/libgstaudio_1.0_la-streamvolume.o .libs/libgstaudio_1.0_la-gstaudioiec61937.o .libs/libgstaudio_1.0_la-gstaudiostreamalign.o .libs/libgstaudio_1.0_la-tmp-orc.o .libs/libgstaudio_1.0_la-audio-enumtypes.o   -L/opt/local/lib ../../../gst-libs/gst/tag/.libs/libgsttag-1.0.dylib -lz -lgstbase-1.0 -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0 -lintl -lorc-0.4  -arch x86_64 -g -Os -arch x86_64 -arch i386 -Wl,-headerpad_max_install_names -arch x86_64 -arch i386 -Wl,-framework -Wl,CoreFoundation -Wl,-framework -Wl,CoreFoundation   -install_name  /opt/local/lib/libgstaudio-1.0.0.dylib -compatibility_version 1405 -current_version 1405.0 -Wl,-single_module
:info:build Undefined symbols for architecture x86_64:
:info:build   "_interpolate_gdouble_cubic_sse2", referenced from:
:info:build       _gst_audio_resampler_new in libgstaudio_1.0_la-audio-resampler.o
:info:build   "_interpolate_gdouble_linear_sse2", referenced from:
:info:build       _gst_audio_resampler_new in libgstaudio_1.0_la-audio-resampler.o
:info:build   "_interpolate_gfloat_cubic_sse", referenced from:
:info:build       _gst_audio_resampler_new in libgstaudio_1.0_la-audio-resampler.o
:info:build   "_interpolate_gfloat_linear_sse", referenced from:
:info:build       _gst_audio_resampler_new in libgstaudio_1.0_la-audio-resampler.o
:info:build   "_interpolate_gint16_cubic_sse2", referenced from:
:info:build       _gst_audio_resampler_new in libgstaudio_1.0_la-audio-resampler.o
:info:build   "_interpolate_gint16_linear_sse2", referenced from:
:info:build       _gst_audio_resampler_new in libgstaudio_1.0_la-audio-resampler.o
:info:build   "_resample_gdouble_cubic_1_sse2", referenced from:
:info:build       _gst_audio_resampler_new in libgstaudio_1.0_la-audio-resampler.o
:info:build   "_resample_gdouble_full_1_sse2", referenced from:
:info:build       _gst_audio_resampler_new in libgstaudio_1.0_la-audio-resampler.o
:info:build   "_resample_gdouble_linear_1_sse2", referenced from:
:info:build       _gst_audio_resampler_new in libgstaudio_1.0_la-audio-resampler.o
:info:build   "_resample_gfloat_cubic_1_sse", referenced from:
:info:build       _gst_audio_resampler_new in libgstaudio_1.0_la-audio-resampler.o
:info:build   "_resample_gfloat_full_1_sse", referenced from:
:info:build       _gst_audio_resampler_new in libgstaudio_1.0_la-audio-resampler.o
:info:build   "_resample_gfloat_linear_1_sse", referenced from:
:info:build       _gst_audio_resampler_new in libgstaudio_1.0_la-audio-resampler.o
:info:build   "_resample_gint16_cubic_1_sse2", referenced from:
:info:build       _gst_audio_resampler_new in libgstaudio_1.0_la-audio-resampler.o
:info:build   "_resample_gint16_full_1_sse2", referenced from:
:info:build       _gst_audio_resampler_new in libgstaudio_1.0_la-audio-resampler.o
:info:build   "_resample_gint16_linear_1_sse2", referenced from:
:info:build       _gst_audio_resampler_new in libgstaudio_1.0_la-audio-resampler.o
:info:build   "_resample_gint32_cubic_1_sse41", referenced from:
:info:build       _gst_audio_resampler_new in libgstaudio_1.0_la-audio-resampler.o
:info:build   "_resample_gint32_full_1_sse41", referenced from:
:info:build       _gst_audio_resampler_new in libgstaudio_1.0_la-audio-resampler.o
:info:build   "_resample_gint32_linear_1_sse41", referenced from:
:info:build       _gst_audio_resampler_new in libgstaudio_1.0_la-audio-resampler.o
:info:build ld: symbol(s) not found for architecture x86_64
:info:build clang: error: linker command failed with exit code 1 (use -v to see invocation)
:info:build make[5]: *** [libgstaudio-1.0.la] Error 1

[mf2k (Frank Schima)]

I see this problem in High Sierra just recently. Cc'ing last person to modify this port for possible comment.

[thetrial (alabay)]

Replying to Schamschula:

You don't need to CC yourself. You get emailed as the ticket reporter.

Oh, okay, thanks :-)

The problem seems to be that your machine is looking for the sse2 extension, but it is not available on your machine.

What does that mean? This is a MBP 5.5, and until this update everything worked well.

[ryandesign (Ryan Carsten Schmidt)]

Replying to Schamschula:

You don't need to CC yourself. You get emailed as the ticket reporter.

It is now possible for users to configure Trac so that they do not automatically receive emails for all tickets they file. Users who do this will Cc themselves on the tickets for which they do want emails. So we should no longer admonish users for Cc'ing themselves on their own tickets.

The problem seems to be that your machine is looking for the sse2 extension, but it is not available on your machine.

All Intel Macs have SSE2.

[mopihopi]

I am also encountering this error on macOS 10.12.6 16G1510, Xcode 9.2 9C40b, upgrading gstreamer1-gst-plugins-base from @1.14.4_0+ogg+universal to @1.14.4_1+ogg+universal+x11 (I don't want x11 but the new Portfile automatically adds +x11 if +universal is set).

[Schamschula (Marius Schamschula)]

Replying to ryandesign:

Replying to Schamschula:

You don't need to CC yourself. You get emailed as the ticket reporter.

It is now possible for users to configure Trac so that they do not automatically receive emails for all tickets they file. Users who do this will Cc themselves on the tickets for which they do want emails. So we should no longer admonish users for Cc'ing themselves on their own tickets.

I was not aware of this change. Good to know this for future reference!. Thanks.

The problem seems to be that your machine is looking for the sse2 extension, but it is not available on your machine.

All Intel Macs have SSE2.

I just installed gstreamer1-gst-plugins-base +ogg+x11 i.e. w/o +universal on my El Cap machine. So the issue is with the universal variant.

[JohnFHall (John Hall)]

Not just 10.11.6, but same fail result on 10.12.6 for me.

[mopihopi]

The build fails with the combination of +universal and +x11. Unfortunately +universal now forces +x11. However if the line "variant universal requires x11 {}" is commented out in the Portfile then a +universal build (without +x11) builds successfully (although then bug #57020 will be back).

It appears that the problem is caused by configure setting HAVE_SSE and HAVE_SSE2 but not HAVE_X86. Because HAVE_SSE and HAVE_SSE2 are set it will attempt to call the sse and sse2 versions of the functions, however because HAVE_X86 is not set the source files containing those functions are not built.

HAVE_X86 is set by configure if __i386__ is declared or __x86_64__ is declared, but configure determines that these are not declared:

:info:configure checking whether __i386__ is declared... no
:info:configure checking whether __x86_64__ is declared... no
:info:configure checking to see if compiler understands -msse... yes
:info:configure checking to see if compiler understands -msse2... yes
:info:configure checking to see if compiler understands -msse4.1... yes

This is because the configure tests are compiled in universal mode, so each test fails (because it fails for one of the architectures):

configure:23945: checking whether __i386__ is declared
configure:23945: /usr/bin/clang -c -pipe -Os -std=c99 -arch x86_64 -arch i386 -I/opt/local/include conftest.c >&5
conftest.c:89:10: error: use of undeclared identifier '__i386__'
  (void) __i386__;
         ^
1 error generated.

Without +x11, there are two builds (one for i386 and one for x86_64) each with their own configure run, and the objects are combined at the end. This approach builds correctly.

[kencu (Ken)]

I'm confused. I had it build on 10.6.8 +ogg +universal +x11 without any trouble:

  gstreamer1-gst-plugins-base @1.14.4_0+ogg+universal+x11 (active) platform='darwin 10' archs='i386 x86_64' date='2018-10-06T09:09:28-0700'

but now, after the revbump, I can't rebuild it either, with the same errors as noted above ... I'll attach my log.

[kencu (Ken)]

build fail log 10.6.8 clang-3.9 configured libcxx

[kencu (Ken)]

when I deleted the new line you added

variant universal requires x11 {}

and then manually built it with +ogg +universal +x11, I see this:

checking whether __i386__ is declared... no
checking whether __x86_64__ is declared... yes
checking to see if compiler understands -msse... yes
checking to see if compiler understands -msse2... yes
checking to see if compiler understands -msse4.1... yes

and then

checking whether __i386__ is declared... yes
checking whether __x86_64__ is declared... no
checking to see if compiler understands -msse... yes
checking to see if compiler understands -msse2... yes
checking to see if compiler understands -msse4.1... yes

and it builds through to completion +ogg +universal +x11 without any troubles

$ port -v installed gstreamer1-gst-plugins-base
The following ports are currently installed:
  gstreamer1-gst-plugins-base @1.14.4_0+ogg+universal+x11 platform='darwin 10' archs='i386 x86_64' date='2018-10-06T09:09:28-0700'
  gstreamer1-gst-plugins-base @1.14.4_1+ogg+universal+x11 (active) platform='darwin 10' archs='i386 x86_64' date='2018-10-28T20:13:26-0700'

So -- something about your added line seems to be messing up the muniversal portgroup's function...

[Ionic (Mihai Moldovan)]

Yeah, must be muniversal being thrown off by that, for whatever reason. Probably because it defines its own universal variant that we're now overriding wrongly.

The approach is flawed anyway, since OpenGL functionality is not always enabled even if universal requires x11. Older platforms won't have support for OpenGL if built -universal-x11, which means that gstreamer1-gst-plugins-bad will still fail.

I guess I'll have to create an opengl variant that requires either x11 or nothing (meaning cocoa, if supported, i.e., if the OS is new enough). Ugly, but I don't see a better way.

[dershow]

As one more data point, I had 1.14.4 installed. But it just tried to upgrade to 1.14.4_1 and now I get the error above. I'm on 10.13.6.

[kencu (Ken)]

you might use variant_isset to either add the default +x11 or error out if it is not set.

[kencu (Ken)]

This block seems to do the right thing, and I believe accomplishes what you were after without breaking the muniversal PortGroup:

if {[variant_isset universal]} {
    if {![variant_isset x11]} {
        ui_error "${name} ${version} requires +x11 if +universal is set."
        return -code error "incompatible variant selection."
    }
}

[mopihopi]

I don't see why +x11 would be required. It is working fine without x11 or OpenGL as long as apple_media is not enabled in gstreamer1-gst-plugins-bad. Adding +x11 for apple_media doesn't make sense since apple_media doesn't work with +x11.

[kencu (Ken)]

I actually have no idea about that. Ionic sorted that out.

But if Ionic wanted a way for +universal to require +x11 without tanking the muniversal PG, there is a way.

[kencu (Ken)]

Has duplicate 57485.

any objections to me just fixing this with the block I posted above while we ponder what to do with this in the long term? Hate to see ticket after ticket of it being broken.

[kencu (Ken)]

In cd5211c2d534687cd0ef1d6d807b92a4fcc9c3dc/macports-ports (master):

gstreamer1-gst-plugins-base: change x11 test

previous test made the universal PG non-functional
closes: #57462