gstreamer1 @1.24.1_0+universal: linking of temporary binary failed

[thetrial (alabay)]

Something is not working, and I don’t know what. I’ll attach the logfile.

[ryandesign (Ryan Carsten Schmidt)]

I see this in the log which may not be related to the problem you're seeing but definitely looks wrong:

:info:build ../gstreamer-1.24.1-x86_64/plugins/tracers/gstrusage.c:50:5: warning: 'MAC_OS_X_VERSION_MIN_REQUIRED' is not defined, evaluates to 0 [-Wundef]
:info:build #if MAC_OS_X_VERSION_MIN_REQUIRED < 1050
:info:build     ^
:info:build ../gstreamer-1.24.1-x86_64/plugins/tracers/gstrusage.c:333:5: warning: 'MAC_OS_X_VERSION_MIN_REQUIRED' is not defined, evaluates to 0 [-Wundef]
:info:build #if MAC_OS_X_VERSION_MIN_REQUIRED < 1050
:info:build     ^
:info:build 2 warnings generated.

This block of code, whatever it is, is intended for macOS versions earlier than 10.5, but because MAC_OS_X_VERSION_MIN_REQUIRED is not defined and evaluates to 0, it is taking effect for all versions of macOS. This file needs to #include <AvailabilityMacros.h> to get the definition of MAC_OS_X_VERSION_MIN_REQUIRED.

As for the real problem in the log, I see you're building universal and that this port uses the muniversal portgroup so it builds the different architectures separately. I'm seeing a successful build of the x86_64 part but the i386 part fails because the right arch flags have not been used for everything, specifically not when building the temporary binary used for gobject introspection:

:info:build linking of temporary binary failed: Command '['/usr/bin/clang', '-o', '/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gstreamer1/gstreamer1/work/build-i386/tmp-introspectpzl0fa8a/Gst-1.0', '/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gstreamer1/gstreamer1/work/build-i386/tmp-introspectpzl0fa8a/Gst-1.0.o', '-L.', '-Wl,-rpath,.', '-L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gstreamer1/gstreamer1/work/build-i386/gst', '-Wl,-rpath,/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gstreamer1/gstreamer1/work/build-i386/gst', '-lgstreamer-1.0', '-lgobject-2.0', '-lglib-2.0', '-lintl', '-lgmodule-2.0', '-lm', '-ldl', '-lgirepository-1.0', '-lgio-2.0', '-lgobject-2.0', '-lgmodule-2.0', '-lglib-2.0', '-lintl']' returned non-zero exit status 1.

Since there were no -arch flags here, it built for the default arch x86_64 and was unable to link with the i386 flavor of the library that was just built:

:info:build ld: warning: ignoring file /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gstreamer1/gstreamer1/work/build-i386/gst/libgstreamer-1.0.dylib, file was built for i386 which is not the architecture being linked (x86_64): /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gstreamer1/gstreamer1/work/build-i386/gst/libgstreamer-1.0.dylib

As a result, all of the symbols that that library should provide are undefined:

:info:build Undefined symbols for architecture x86_64:
:info:build   "_gst_allocation_params_get_type", referenced from:
:info:build       _GI_GET_TYPE_FUNCS_ in Gst-1.0.o
:info:build   "_gst_allocator_flags_get_type", referenced from:
:info:build       _GI_GET_TYPE_FUNCS_ in Gst-1.0.o
…

This is exactly the problem that the gobject_introspection 1.0 portgroup was designed to solve. The port used to include that portgroup until yesterday when the port was updated to a new version and its build system was switched to meson. The gobject_introspection 1.0 portgroup was designed for the autotools build system and I don't know if it works with the meson build system. If not, hopefully it can be enhanced to do so. I've seen many ports remove the inclusion of the gobject_introspection 1.0 portgroup and instead copy/paste code into the Portfile to handle the situation, a practice I would really love to see the end of. That's why we have portgroups: to consolidate common logic in one place.

[Gcenx]

Weirdly I don’t remember having issues with gobject-introspection when I’d originally started to carry an updated copy of GStreamer1 ports but I did move to using muniversal-1.1. I’ve since removed gobject-introspection from the custom gstreamer based package I’m maintaining.

[barracuda156]

Replying to Gcenx:

Weirdly I don’t remember having issues with gobject-introspection when I’d originally started to carry an updated copy of GStreamer1 ports but I did move to using muniversal-1.1. I’ve since removed gobject-introspection from the custom gstreamer based package I’m maintaining.

I have nothing to test universal built at the moment. Does switching to muniversal 1.0 fix the problem for the current version?

[christophecvr (christophecvr)]

Hello I we are running in a lot of more problems just because gstreamer1.24.1 is not build like it should for example on macbookpro mid 2010 using intel 64 arch macos-10.13.6 (High Sierra) xcode 10.1 . nvidia graphics (means opengl support is a must). The base x11 is indeed only for x86_64 arch.The winsys is multiver or even i386 so x11 and winsys with opengl is not possible it will break on issues like x86_64 bla bla bla not found. x11 is a must , gl support is a must. The base gl support has been moved from gst-plugins-bad to gst-plugins-base . Here just a temporary show how we can work further on . Off course this is for intel 64 nvidia graphics and a base core which is x86_64 (yes on high sierra there is still multiver support but mostly it bugs with x11 since that is build for x86_64 only and that is ok and right.) See the patch I did to the macports-ports with that path i'm able to build gstreamer1 with opengl and x11 support that is required.

​https://github.com/christophecvr/macports-ports/commit/cb7c24829824fdd418f48e5a9d92279619b6391e

I will also add a debug of build of terminal.

[christophecvr (christophecvr)]

Succesfull Build of gstreamer1-gst-plugins-base with x11 and gl support no winsys.

[barracuda156]

Replying to christophecvr:

Hello I we are running in a lot of more problems just because gstreamer1.24.1 is not build like it should for example on macbookpro mid 2010 using intel 64 arch macos-10.13.6 (High Sierra) xcode 10.1 . nvidia graphics (means opengl support is a must). The base x11 is indeed only for x86_64 arch.The winsys is multiver or even i386 so x11 and winsys with opengl is not possible it will break on issues like x86_64 bla bla bla not found. x11 is a must , gl support is a must. The base gl support has been moved from gst-plugins-bad to gst-plugins-base . Here just a temporary show how we can work further on . Off course this is for intel 64 nvidia graphics and a base core which is x86_64 (yes on high sierra there is still multiver support but mostly it bugs with x11 since that is build for x86_64 only and that is ok and right.) See the patch I did to the macports-ports with that path i'm able to build gstreamer1 with opengl and x11 support that is required.

​https://github.com/christophecvr/macports-ports/commit/cb7c24829824fdd418f48e5a9d92279619b6391e

I will also add a debug of build of terminal.

1. If you want to tweak compiler choice for a given port, do it in a portfile. It is not acceptable or even useful to do it generally (unless a compiler is just broken, which is not the case for clang-15/16). By the way, if Apple clang cannot build this, it should be raised to upstream, I guess, that looks like a bug.

2. I find your exposition confusing, sorry. The port should support all archs (which include arm64 and ppc/ppc64), so if something is for intel 64 Nvidia, it cannot be a general setting. If older systems and powerpc need special settings, those can be made conditional. Same goes for the latest macOS versions, if those require special settings.

3. If some configure args _really_ have to be just removed, a comment it a portfile will be helpful, otherwise someone may add them back, or think it was an accidental removal, etc.

[thetrial (alabay)]

By the way … the and not command switch seems not to work [always|anymore].

sudo port upgrade outdated and not \( gstreamer1 \) does not prevent from trying to build gstreamer1 … and that breaks MacPorts’ upgrade more or less completely. Yesterday I had a new problem I cannot reproduce today because of upgrading (again) not reaching this point anymore (glib2 related).

[thetrial (alabay)]

Is there any prospect of getting the problem under control?