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?

[Znapi (Zachary Napier)]

Ran into this on high sierra. I don't have a patch, but here's the kludging I did to get it to compile:

First, port build gstreamer1 +universal. This will fail, but it will leave the build directories.

In /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gstreamer1/gstreamer1/work/build-i386/meson-uninstalled/gstreamer-1.0-uninstalled.pc, add -arch i386 to the Cflags line at the bottom.

In /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gstreamer1/gstreamer1/work/build-i386/build.ninja, replace all instances of --pkg-export with --pkg.

In /opt/local/lib/gobject-introspection/giscanner/dumper.py, add the following at line 282. It is line 282 in my version at least. It is just before some code that prints out the entire linker command line, so the whole thing looks like this, with my additions marked by pluses:

+        args.insert(1, '-arch')
+        args.insert(2, 'i386')
        if not self._options.quiet:
            print("g-ir-scanner: link: %s" % (
                subprocess.list2cmdline(args), ))
            sys.stdout.flush()

Then port destroot gstreamer1 +universal will finish the build and destroot it.

Lastly, undo the changes to dumper.py.

Now you can run whatever command was failing before and it should get past gstreamer. For me, gstreamer1-gst-plugins-base seems to be failing with the same issue.

[thetrial (alabay)]

It doesn’t work here.

:info:build   File "/opt/local/lib/gobject-introspection/giscanner/dumper.py", line 282
:info:build     args.insert(1, '-arch')
:info:build TabError: inconsistent use of tabs and spaces in indentation
:info:build [21/339] ccache /usr/bin/clang 

Seems like I made something unclean. I tried tabs, I tried spaces, it doesn’t go through.

[thetrial (alabay)]

If this should get abandoned, it would be nice to make a workaround that Macports can go through updates again. I’m stuck since three months.

[thetrial (alabay)]

Replying to thetrial:

It doesn’t work here.

Ha! Today I managed it ran through. I had to clean all ccached stuff beforde and copied the +-markes lines line per line … now it worked. This is a workaround. Now the question is: What exactly is the problem?! Because, as you said … the same comes with gstreamer1-gst-plugins-base. I’ve opened a new ticket (why hasn’t there been one before?): #70332.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #70610.

[kencu (Ken)]

Replying to thetrial:

Is there any prospect of getting the problem under control?

So far, the people with the skills to fix this universal build issue just haven’t felt motivated to do so.

Perhaps that may change… summer is coming to an end soon.

Now, you might ask how a major change in build system might have been pushed without the author of it testing to see if it would break universal builds…. and there, I have no answer for you.

[thetrial (alabay)]

An interesting side observation: When I try to build gstreamer1, macports seems to break. I get:

Error: process_cmd failed: sqlite error: another row available (100) while executing query: SELECT cxx_stdlib FROM registry.ports WHERE id=1790

That only happens, when I try a runthrough without and not \( wine-devel gstreamer1 gstreamer1-gst-plugins-base \) – after a (breaking) try with gstreamer1. Very interesting. Reproducable. So I play back my backup.