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).

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 setting, those can be made conditional. Same goes for the latest macOS versions, if those require special settings.

[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?