webkit2-gtk: +x11 error: GStreamerGL is needed for USE_GSTREAMER_GL

[JonnyTech]

sudo port install glabels
Password:
--->  Computing dependencies for glabels
--->  Cleaning glabels
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  Found 6 broken files, matching files to ports
--->  Found 1 broken port, determining rebuild order
You can always run 'port rev-upgrade' again to fix errors.
The following ports will be rebuilt: webkit2-gtk @2.28.2+minibrowser+x11
Continue? [Y/n]: y
--->  Computing dependencies for webkit2-gtk
--->  Cleaning webkit2-gtk
--->  Scanning binaries for linking errors
--->  Found 6 broken files, matching files to ports
--->  Found 1 broken port, determining rebuild order
--->  Rebuilding in order
     webkit2-gtk @2.28.2_7+minibrowser+x11
--->  Computing dependencies for webkit2-gtk
--->  Fetching distfiles for webkit2-gtk
--->  Verifying checksums for webkit2-gtk
--->  Extracting webkit2-gtk
--->  Applying patches to webkit2-gtk
--->  Configuring webkit2-gtk
Error: Failed to configure webkit2-gtk: configure failure: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_www_webkit2-gtk/webkit2-gtk/main.log for details.
Error: rev-upgrade failed: Error rebuilding webkit2-gtk
Error: Follow https://guide.macports.org/#project.tickets if you believe there
is a bug.

sudo port selfupdate
Password:
--->  Updating MacPorts base sources using rsync
MacPorts base version 2.9.1 installed,
MacPorts base version 2.9.1 downloaded.
--->  Updating the ports tree
--->  MacPorts base is already the latest version

The ports tree has been updated. To upgrade your installed ports, you should run
  port upgrade outdated

sudo port upgrade outdated

Nothing to upgrade.
--->  Scanning binaries for linking errors
--->  Found 6 broken files, matching files to ports
--->  Found 1 broken port, determining rebuild order
You can always run 'port rev-upgrade' again to fix errors.
The following ports will be rebuilt: webkit2-gtk @2.28.2+minibrowser+x11
Continue? [Y/n]: y
--->  Computing dependencies for webkit2-gtk
--->  Cleaning webkit2-gtk
--->  Scanning binaries for linking errors
--->  Found 6 broken files, matching files to ports
--->  Found 1 broken port, determining rebuild order
--->  Rebuilding in order
     webkit2-gtk @2.28.2_7+minibrowser+x11
--->  Computing dependencies for webkit2-gtk
--->  Fetching distfiles for webkit2-gtk
--->  Verifying checksums for webkit2-gtk
--->  Extracting webkit2-gtk
--->  Applying patches to webkit2-gtk
--->  Configuring webkit2-gtk
Error: Failed to configure webkit2-gtk: configure failure: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_www_webkit2-gtk/webkit2-gtk/main.log for details.
Error: rev-upgrade failed: Error rebuilding webkit2-gtk
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.

[JonnyTech]

Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_www_webkit2-gtk/webkit2-gtk/main.log for details.

[ryandesign (Ryan Carsten Schmidt)]

Replying to JonnyTech:

sudo port install glabels
Password:
--->  Computing dependencies for glabels
--->  Cleaning glabels

This indicates glabels was already successfully installed before you ran sudo port install glabels.

--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  Found 6 broken files, matching files to ports
--->  Found 1 broken port, determining rebuild order
You can always run 'port rev-upgrade' again to fix errors.
The following ports will be rebuilt: webkit2-gtk @2.28.2+minibrowser+x11

After every install or upgrade, unless you tell it not to, MacPorts runs rev-upgrade which checks for broken library linkage. It found broken library linkage in webkit2-gtk.

--->  Rebuilding in order
     webkit2-gtk @2.28.2_7+minibrowser+x11
--->  Computing dependencies for webkit2-gtk
--->  Fetching distfiles for webkit2-gtk
--->  Verifying checksums for webkit2-gtk
--->  Extracting webkit2-gtk
--->  Applying patches to webkit2-gtk
--->  Configuring webkit2-gtk
Error: Failed to configure webkit2-gtk: configure failure: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_www_webkit2-gtk/webkit2-gtk/main.log for details.
Error: rev-upgrade failed: Error rebuilding webkit2-gtk
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.

In attempting to rebuild webkit2-gtk to fix the broken library linkage, a problem occurred. Please attach the main.log and config.log files so that we can see what the problem was.

[ryandesign (Ryan Carsten Schmidt)]

I see you attached the main.log file while I was writing my message, and the build uses cmake which does not produce config.log files, but the error in main.log is:

:info:configure CMake Error at Source/cmake/GStreamerChecks.cmake:34 (message):
:info:configure   GStreamerGL is needed for USE_GSTREAMER_GL.

[JonnyTech]

Thank you for your prompt reply.

This indicates glabels was already successfully installed before you ran sudo port install glabels.

It was not, it failed with the same message, hence why I reran sudo port install glabels

Please attach the main.log and config.log files so that we can see what the problem was.

Done.

[ryandesign (Ryan Carsten Schmidt)]

What's the output of port -v installed glabels?

[JonnyTech]

port -v installed glabels
The following ports are currently installed:
  glabels @3.4.1_0 (active) requested_variants='' platform='darwin 23' archs='arm64' date='2024-04-01T09:33:03+0400'

glabels-3

(glabels-3:59234): Gtk-WARNING **: 10:27:53.179: cannot open display:


which glabels-3
/opt/local/bin/glabels-3


sudo glabels-3
Password:

(glabels-3:59252): Gtk-WARNING **: 10:30:48.131: cannot open display:


export DISPLAY=:0.0
glabels-3

(glabels-3:59276): Gtk-WARNING **: 10:31:54.958: cannot open display: :0.0

[ryandesign (Ryan Carsten Schmidt)]

Great, then as I said glabels is already installed.

Which X server are you using? Or do you even have one? If you don't have one, you can install ours by following the instructions printed by port notes xinit.

Do not export DISPLAY=:0.0 as that will defeat the automatic setting of DISPLAY that would otherwise occur.

[JonnyTech]

After installing sudo port install xorg-server and rebooting, there is no Application shortcut for gLabels.

In Terminal, executing glabels-3 there is a delay of about a minute where nothing happens, then a XQuartz icon appears in the dock and shortly after that the gLabels application finally starts.

Thank you, this has got it working for me, the whole installation just needs some work at tidying the rough edges, ie automatically installing an X11 server, adding a startup shortcut and some kind of visual indication that the application is starting.

[ryandesign (Ryan Carsten Schmidt)]

If you mean that there is no icon for glabels in the /Applications/MacPorts folder or in Launchpad, that's normal for X programs. You launch them from a terminal. X programs are not macOS applications and do not respond as macOS applications do so they don't belong in the Applications folder. X programs do not provide an indication that they are running, beyond the window(s) that they open.

It is also normal for X to take a moment to start. You can launch /Applications/MacPorts/X11.app manually at any time before launching an X program if you want to endure that delay at a different time. You could even put X11.app in your login items to have it launch when you log in, if you use X programs frequently.

We intentionally do not add a dependency on xorg-server because you might want to use a different X server. For example, although we think you'll prefer xorg-server, you may already have installed the standalone XQuartz distribution and want to use that instead. Or you may want to use an X server located on a different computer.

[dyne2meter]

I was just doing a normal selfupdate and got this (or a very similar) error also, but in conjunction with updating gstreamer1-gst-plugins-bad. I solved it by changing variants on gtk3 and webkit2gtk to +quartz, and that fixed my issue with the configure failure. This happened on two systems, one running High Sierra and one running Mojave.

I use X only very occasionally as a platform, and use XQuartz to support jupyter and similar stuff. I don't know if I will face any consequences from changing the variant. If there is interest, I can try installing the +x11 variant and try to read or submit the log.

PS: I think I only have this installed as a dependency of the genius port (which uses epiphany)

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

:info:configure CMake Error at Source/cmake/GStreamerChecks.cmake:34 (message):
:info:configure   GStreamerGL is needed for USE_GSTREAMER_GL.

It looks like lack of "GStreamerGL" is also the reason why the port is being considered broken. On my system, sudo port -d rev-upgrade contained this line:

Could not open /opt/local/lib/libgstgl-1.0.0.dylib: Error opening or reading file (referenced from /opt/local/lib/libwebkit2gtk-4.0.37.44.4.dylib)

Indeed that library does not exist.

gstreamer-gl was in gstreamer1-gst-plugins-base @1.16.2_2 but it is not in gstreamer1-gst-plugins-base @1.24.1_0. Where did it go? Looking at ​a recent build log of gstreamer1-gst-plugins-base it says:

Message: GStreamer OpenGL integration disabled via options.

So this sounds like a bug in the gstreamer1-gst-plugins-base port.

[christophecvr (christophecvr)]

Hello you need to rebuil gstreamer1-gst-plugins base I made a patch in my github on macport-ports fork .[​https://github.com/christophecvr/macports-ports/commit/cb7c24829824fdd418f48e5a9d92279619b6391e

It is for macos-10.13.6

[christophecvr (christophecvr)]

There are more problems with gstreamer . It is always so with gstreamer upgrade . Shure it was needed. But here the build is not implemented well. Also When upgrading gstreamer the old versions needs to be uninstalled first . Then gstreamer1 , then gstreamer1-gst-plugins-base, gstreamer1-gst-plugins-good, gstreamer1-gst-plugins-bad, gstreamer1-gst-libav and eventually gstreamer1-gst-plugins-ugly . Many packages using gstreamer require a rebuild as well. But webkit2-gtk does not require a rebuild one the patched gst base is build and installed .winsys cocoa. Support is removed and x11 + gl. Is enabled. P.s. if os.major is below 13 you shoul adapt the line to the os.major you have.

[kencu (Ken)]

has dup #69675

[christophecvr (christophecvr)]

I just think about the fact that in my patch i removed line 94 and 95 winsys=x11 but also reintroduced the macports introspection. I forgot to test a buil with the x11 and gl and winsys=x11 while also the macports introspection was reanabled. I will try this again tommorow .

[christophecvr (christophecvr)]

No luck gstreamer1-gst-plugins-base do not build with -Dwinsys=x11 cause it try to use cocoa. So with x11 gstreamer-gst-plugins-base must be build without the -Dwinsys=x11 and with gl support.

Error with winsys=x11 :

 CoreFoundation -framework Foundation /opt/local/lib/libX11.dylib /opt/local/lib/libX11-xcb.dylib /opt/local/lib/libxcb.dylib
ld: warning: text-based stub file /System/Library/Frameworks//OpenGL.framework/OpenGL.tbd and library file /System/Library/Frameworks//OpenGL.framework/OpenGL are out of sync. Falling back to library file for linking.
ld: warning: text-based stub file /System/Library/Frameworks//QuartzCore.framework/QuartzCore.tbd and library file /System/Library/Frameworks//QuartzCore.framework/QuartzCore are out of sync. Falling back to library file for linking.
ld: warning: text-based stub file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation.tbd and library file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation are out of sync. Falling back to library file for linking.
ld: warning: text-based stub file /System/Library/Frameworks//Foundation.framework/Foundation.tbd and library file /System/Library/Frameworks//Foundation.framework/Foundation are out of sync. Falling back to library file for linking.
ld: warning: text-based stub file /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.tbd and library file /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib are out of sync. Falling back to library file for linking.
ld: warning: text-based stub file /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.tbd and library file /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib are out of sync. Falling back to library file for linking.
ld: warning: text-based stub file /System/Library/Frameworks//CoreImage.framework/Versions/A/CoreImage.tbd and library file /System/Library/Frameworks//CoreImage.framework/Versions/A/CoreImage are out of sync. Falling back to library file for linking.
ld: warning: text-based stub file /System/Library/Frameworks//CoreVideo.framework/Versions/A/CoreVideo.tbd and library file /System/Library/Frameworks//CoreVideo.framework/Versions/A/CoreVideo are out of sync. Falling back to library file for linking.
Undefined symbols for architecture x86_64:
  "_gst_gl_context_cocoa_get_current_context", referenced from:
      _gst_gl_context_new_wrapped in gstglcontext.c.o
      _gst_gl_context_get_current_gl_context in gstglcontext.c.o
  "_gst_gl_context_cocoa_new", referenced from:
      _gst_gl_context_new in gstglcontext.c.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

[kencu (Ken)]

The +quartz variant of webkit2-gtk continues to build and work just fine, and I prefer that anyway.

That might be a workaround for folks until the issues with gstreamer1-gst-plugins-base disabling GL get sorted out by somebody.

[christophecvr (christophecvr)]

The build of gstreamer-gst-plugins-base is already sorted out. Does build perfect with gl support and x11.​https://github.com/christophecvr/macports-ports/blob/cvrwork/gnome/gstreamer1-gst-plugins-base/Portfile

On link above you can see the right portfilr. Before using that first uninstaal the installed gstreamer1-gst-plugins-base Use that portfile (build with -s option . And then do the same with plugins bad.

[kencu (Ken)]

Certainly not clear that it is already sorted out from the comments above, with those undefined link symbols etc that you indicated, but perhaps it really is sorted out and I can't see that clearly.

Are we clear on what building gstreamer-gst-plugins-base +x11 while at the same time disabling -Dwinsys=x11 will do to the x11 functionality of gstreamer-gst-plugins-base? Seems like it would break it, but I only go on the obviousness of the options, not with testing it.

At any rate, the +quartz variant of webkit2-gtk works now, as is, for folks, for people like me who want this to work today.

[christophecvr (christophecvr)]

You work with xquartz or x11 . For persons with x11 you do not need the winsys at all . You use the macos os open gl and the libgstgl that last one is build when you buil gstreamer1-gst-plugins-base without that lib there is no gl support at all in gstreamer and all applications who use and needs gstreamer with glsupport will fail. For xquartz you need the winsys and cocoa and also gl of course. Since you also need macos opengl. But saying to use xquartz(which also uses a owcn x11 )will then create conflicts with x11 of xorg and visa versa

[kencu (Ken)]

Xquartz and +quartz are different things.

I think you said you’ve been around MacPorts for a few weeks now?

Most ports work quite well building as their +quartz variant. Better in ways than the +x11 variant. Some ports do not.

[christophecvr (christophecvr)]

Well just to say the problem is solved for 100 % . And it was already with (by coincidence I admit) with my port file of wich I posted a link before.

When building the gstreamer1-gst-plugins-base with gl support on macos os you always need the cocoa. So when you build with x11 support on macos you need gl-winsys='x11, cocoa'. So you can set as option -Dgl-winsys='x11, cocoa', -Dgl-winsys='auto' or just omit the setting since auto is default value. When auto is set it uses x11 and cocoa for gl-winsys. If it is detected. If meson does not find x11 during configure phase check but wel cocoa it will just set cocoa. Actually meson (at start I did not liked it just cause i did not know it) The longer the more I like it. Here for instance meson did a very good job. What went wrong is the user interference by disabling the auto features who are just required.

I can post the meson log of build gtsreamer1-gst-plugins-base . What was done with this port file. portfile ​https://github.com/christophecvr/macports-ports/blob/cvrwork/gnome/gstreamer1-gst-plugins-base/Portfile

the last commit I did to it

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

p.s. by me I need to blacklist clang build take to much time with Xcode 10-clang and some packages do not build well) The autodetect of compiler in _resources has been set to max 14 by me. 15,16,17 are all buggy for macos-10.13.6

[christophecvr (christophecvr)]

Replying to kencu:

I think you said you’ve been around MacPorts for a few weeks now?

Yes but more the 15 years on gstreamer and implementing it in a (bitbake cross build platform on linux). Actually I was the main maintainer of gstreamer packages and upgrade on openatv for two years till I did not have time any more (yes it is time consuming). And yes we just worked with the master on our developer branch. When merging to next-release we blocked it of course on a fixed commit.

[cooljeanius (Eric Gallager)]

Also seen tangentially in ticket #69544

Edit: and in ticket #69644 too

[kencu (Ken)]

Replying to christophecvr:

p.s. by me I need to blacklist clang build take to much time with Xcode 10-clang and some packages do not build well) The autodetect of compiler in _resources has been set to max 14 by me. 15,16,17 are all buggy for macos-10.13.6

I had a few minutes this morning and solved the verbose_abort minor issue for clang-16. That has been pushed and -- hopefully -- that will be the end of that.

I'll push that fix to clang-17 soon enough, but clang-17 is already not used by default on the older systems so there should be no errors there.

What is wrong with clang-15? I haven't been keeping up with the clang front so much since I abandoned them to Chris a few years ago, but I thought he had been keeping things going. Is there some actual issue with a clang-15 related failure on 10.13 you can point to?

[kencu (Ken)]

Replying to cooljeanius:

Also seen tangentially in ticket #69544

Edit: and in ticket #69644 too

Is anyone working on fixing the GL support for these gstreamer ports to the point where they can actually PR something?

Lots of stuff is hosed since that gstreamer update. I am using +quartz, so I don't see it, and I am hoping someone will sort out how to fix it properly and PR something.

[kencu (Ken)]

Replying to christophecvr:

What went wrong is the user interference by disabling the auto features who are just required.

Macports does not generally allow software to autoconfigure based on what happens to be found, because in so doing, often times bad things happen and software configures itself in ways that were not intended.

So if we want gstreamer* ports with x11 and GL support, we usually will require the right dependencies be installed and then force the build to use exactly what we want used.

I have too many other things going on right now for me to fix the gstreamer* ports, but hopefully that will get done before everyone gets totally frustrated.

[barracuda156]

Replying to christophecvr:

Well just to say the problem is solved for 100 % . And it was already with (by coincidence I admit) with my port file of wich I posted a link before.

When building the gstreamer1-gst-plugins-base with gl support on macos os you always need the cocoa. So when you build with x11 support on macos you need gl-winsys='x11, cocoa'. So you can set as option -Dgl-winsys='x11, cocoa', -Dgl-winsys='auto' or just omit the setting since auto is default value. When auto is set it uses x11 and cocoa for gl-winsys. If it is detected. If meson does not find x11 during configure phase check but wel cocoa it will just set cocoa. Actually meson (at start I did not liked it just cause i did not know it) The longer the more I like it. Here for instance meson did a very good job. What went wrong is the user interference by disabling the auto features who are just required.

Automatic linking to whatever a build system happens to find is not a great behavior, IMO. (This is not exclusive to meson though, of course.)

[christophecvr (christophecvr)]

Replying to barracuda156:

Replying to christophecvr:

Automatic linking to whatever a build system happens to find is not a great behavior, IMO. (This is not exclusive to meson though, of course.)

Yea well that really depends on what. They did provide the opportunity to disable this behaviour which in some cases must be done in other case not. Here with opengl it is a not. When using nvidia graphics card gstreamer1 must be build with opengl support as soon any applications needs to play video streams. gstreamer without opengl support is useless. Macos has his own opengl support. Also macos has is own checks on presence off all required functions. Yes when using x11 the functions in the libgstgl.dylib that we will build (most probably ?) for the applications using x11 will not be required.However they maybe present in the library and will not conflict at all. Even better actually the builded lib will be ok for x11 and non x11 applications. Since the non x11 will use the cocoa related functions the x11 the x11 related functions. The macos test when building checks for all required functions and does not botter if it is x11 or cocoa. So for gstreamer1 plugins base the portfile just need a little change. below how the portfile should be.

# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4

PortSystem          1.0
PortGroup           compiler_blacklist_versions 1.0
PortGroup           gobject_introspection 1.0
PortGroup           meson 1.0

# https://bugzilla.gnome.org/show_bug.cgi?id=636134
PortGroup           muniversal 1.0

name                gstreamer1-gst-plugins-base
set my_name         gst-plugins-base
# please only commit stable updates (even numbered releases)
version             1.24.1
revision            0
description         This is gst-plugins, a set of plug-ins for GStreamer.
long_description    ${description}
maintainers         nomaintainer
categories          gnome
license             LGPL-2+
homepage            https://gstreamer.freedesktop.org/modules/${my_name}.html
master_sites        https://gstreamer.freedesktop.org/src/${my_name}/
distname            ${my_name}-${version}
use_xz              yes

checksums           rmd160  2b6ab7dd6e5a5301b0f020d05628f7348337a41e \
                    sha256  884045d1d7c5d6bb8605e45c7ee0e9f1341888e81c2b7c42dff52bb98ede8ec3 \
                    size    2418392

set py_ver          3.12
set py_ver_nodot    [string map {. {}} ${py_ver}]
set python.bin      ${prefix}/bin/python${py_ver}

depends_build-append \
                    port:gtk-doc \
                    port:pkgconfig \
                    port:python${py_ver_nodot}

depends_lib-append  path:lib/pkgconfig/gobject-introspection-1.0.pc:gobject-introspection \
                    port:graphene \
                    port:gstreamer1 \
                    path:include/turbojpeg.h:libjpeg-turbo \
                    port:libopus \
                    port:libpng \
                    port:orc \
                    path:lib/pkgconfig/pango.pc:pango \
                    port:zlib

# Embedded systems are not our primary target, so disable OpenGL|ES support.
configure.args-append \
                    -Dalsa=disabled \
                    -Dcdparanoia=disabled \
                    -Dexamples=disabled \
                    -Dgl-graphene=enabled \
                    -Dlibvisual=disabled \
                    -Dnls=disabled \
                    -Dogg=disabled \
                    -Dqt5=disabled \
                    -Dtheora=disabled \
                    -Dvorbis=disabled \
                    -Dx11=disabled \
                    -Dxshm=disabled \
                    -Dxvideo=disabled

# gstbasetextoverlay.c:1511: error: 'for' loop initial declaration used outside C99 mode
configure.cflags-append -std=c99

# gst-libs/gst/gl/gstgldebug.h:28: error: redefinition of typedef ‘GstGLAsyncDebug’
compiler.blacklist-append *gcc-3.* *gcc-4.* clang

post-patch {
    reinplace "s|/usr/bin/env python3|${python.bin}|" \
        ${worksrcpath}/scripts/extract-release-date-from-doap-file.py \
        ${worksrcpath}/scripts/dist-translations.py \
        ${worksrcpath}/scripts/meson-pkg-config-file-fixup.py \
        ${worksrcpath}/scripts/update-orc-dist-files.py \
        ${worksrcpath}/gst-libs/gst/gl/gl_mkenum.py
}

variant x11 {
    depends_lib-append \
                    port:mesa \
                    port:xorg-libX11 \
                    port:xorg-libXext \
                    port:xorg-libXv
    configure.args-replace \
                    -Dx11=disabled \
                    -Dx11=enabled \
                    -Dxshm=disabled \
                    -Dxshm=enabled \
                    -Dxvideo=disabled \
                    -Dxvideo=enabled
}

variant ogg description {Build with support for libogg, libvorbis, libtheora} {
    depends_lib-append \
                    port:libogg \
                    port:libtheora \
                    port:libvorbis
    configure.args-replace \
                    -Dogg=disabled \
                    -Dogg=enabled \
                    -Dtheora=disabled \
                    -Dtheora=enabled \
                    -Dvorbis=disabled \
                    -Dvorbis=enabled
}

variant cdparanoia description {Enable (currently broken) cdparanoia plugin} {
    depends_lib-append \
                    port:cdparanoia
    configure.args-replace \
                    -Dcdparanoia=disabled \
                    -Dcdparanoia=enabled
}

# Prefer X11 implementation.
default_variants    +ogg +x11

gobject_introspection yes

# Cocoa-GL
# Only enable on OS X 10.9 or later, if the x11 variant is not enabled.
# Requires ARC (automatic reference counting, a clang feature enabled
# by -fobjc-arc), which was not supported when targeting the legacy fragile
# Objective-C runtime used on 32-bit x86 until Xcode 7.3 / clang 3.9
# (https://llvm.org/viewvc/llvm-project?view=revision&revision=250955).
# If building universal or for i386 then ensure that a sufficiently recent
# version of clang is used, since the Xcode clang may be too old.
platform macosx {
    if {![variant_isset x11] && ${os.major} >= 13} {
        if {(${universal_possible} && [variant_isset universal]) || ${build_arch} eq "i386"} {
            compiler.blacklist-append *gcc* {macports-clang-3.[0-8]} {clang < 703}
        }
        configure.args-append \
                    -Dgl_winsys=cocoa
    }
}

test.run            yes
test.target         check

livecheck.type      regex
livecheck.name      ${my_name}
livecheck.url       ${master_sites}
livecheck.regex     "${my_name}-(\\d+\\\.\\d*\[02468\](?:\\.\\d+)*)${extract.suffix}"

I removed the opengl enabled disabled as this is a required library on nvidia graphic cards in all circumstances. For video playing. p.s. for mac hardware who are using the metal graphic cards they are using something else then opengl or ... well if i'm not wrong meson will sort this out. (unless it is mac only hardware).

Then I left in the last part (without) x11 build and use, I did not test it but I do not think that this rule in this case is needed. Almost shure when building without i386 support that the rule I left

platform macosx {
    if {![variant_isset x11] && ${os.major} >= 13} {
        if {(${universal_possible} && [variant_isset universal]) || ${build_arch} eq "i386"} {
            compiler.blacklist-append *gcc* {macports-clang-3.[0-8]} {clang < 703}
        }
        configure.args-append \
                    -Dgl_winsys=cocoa
    }
}

-Dgl_winsys=cocoa maybe removed.

Maybe it is required for i386 build arch but then it just needed to be moved one stage up. (p.s. I added the mac ports introspection to it like mentioned by was it dbevans or ? in a other ticket) But to be honest yes anyway a introspection is enabled but by using the PortGroup gobject_introspection 1.0 there are a little extra adds who should be added. If they are really added I don't. (I well also used gobject_introspection yes that is required in that PortGroup) It will also enable the introspection in meson (change from auto into enabled) .

As extra I forgot to mention. If You now build the gstreamer like mentioned above the gstreamer plugins base is build for x11 and non x11 applications on x86_64 platforms. So You may like to use some applications without x11 support and others with. They all will be able to use the nvidia gl graphics acceleration when using a gstreamer plugin.

[christophecvr (christophecvr)]

I well have A question about the introspection. First it is important to use the mac-ports introspection adds off portgroup. But By messon I also see this extra code in a lot of port files.

# uses g-ir-scanner, which uses $CC from env
if {${universal_possible} && [variant_isset universal]} {
    foreach arch ${configure.universal_archs} {
        lappend merger_build_env(${arch})  "CC=${configure.cc} -arch ${arch}"
        lappend merger_destroot_env(${arch})  "CC=${configure.cc} -arch ${arch}"
    }
} else {
    build.env-append       "CC=${configure.cc} ${configure.cc_archflags}"
    destroot.env-append    "CC=${configure.cc} ${configure.cc_archflags}"
}

1 ) Looks to me that this must be added for each meson build used if we use the introspection. ?

2) When using this g-ir scanner are the settings of macports introspection applied provided we add ?

PortGroup           gobject_introspection 1.0
gobject_introspection yes

[kencu (Ken)]

it has been stated in other tickets that the gobject_introspection PortGroup requires updating to work properly when interacting with ports that build with meson.

In general, g-ir-scanner and gobject_introspection have been a fairly huge PITA to deal with, as they are extremely touchy entities that need lots of tweaking to work right.

[barracuda156]

Replying to kencu:

it has been stated in other tickets that the gobject_introspection PortGroup requires updating to work properly when interacting with ports that build with meson.

I think I saw failures with it in some ports, so yeah, most likely.

[barracuda156]

Replying to kencu:

Xquartz and +quartz are different things.

I think you said you’ve been around MacPorts for a few weeks now?

Most ports work quite well building as their +quartz variant. Better in ways than the +x11 variant. Some ports do not.

By the way, are there some reasons not to make +quartz the default for systems supporting it? (Sure enough, we do not need to break powerpc builds by this, by perhaps all recent macOS can prefer it over x11?)

[barracuda156]

Replying to christophecvr:

The build of gstreamer-gst-plugins-base is already sorted out. Does build perfect with gl support and x11.​https://github.com/christophecvr/macports-ports/blob/cvrwork/gnome/gstreamer1-gst-plugins-base/Portfile

This seems to build fine for me on Sonoma.

[cooljeanius (Eric Gallager)]

Replying to barracuda156:

Replying to kencu:

Most ports work quite well building as their +quartz variant. Better in ways than the +x11 variant. Some ports do not.

By the way, are there some reasons not to make +quartz the default for systems supporting it? (Sure enough, we do not need to break powerpc builds by this, by perhaps all recent macOS can prefer it over x11?)

See issue #60511

Edit: see also issue #39782

[christophecvr (christophecvr)]

Replying to barracuda156:

Replying to christophecvr:

The build of gstreamer-gst-plugins-base is already sorted out. Does build perfect with gl support and x11.​https://github.com/christophecvr/macports-ports/blob/cvrwork/gnome/gstreamer1-gst-plugins-base/Portfile

This seems to build fine for me on Sonoma.

That is nice also. I only can test on 10.13.6 (High Sierra). I did a further study of gstreamer. And for gstreamer package it is best to build with x11 and xquartz support. The majority of plugins are not depending on x11 or xquartz. Well when using open gl. But building gstreamer with support for the two does not cause any conflict. Gstreamer builds a main gl lib and also separated libs and packages for x11 or xquartz. So it is just the package who uses the gstreamer plugins who must be configured to use x11 or xquartz. I'm well busy now with the cdparanoia plugin now. Found the reason why it does not build that is because a required cd find check has been removed out of the cdparanoia-III-10.2 self cause on macos it is different and yes this is required to use the plugin for reading standard audio cd's (who are in cdda format). Will see if I can make a patch to the gstreamer cdparanoia plugin to use the macos io drivers to read a cd on mac.

[christophecvr (christophecvr)]

What needs to be changed in the gstreamer paranoia plugin is this function which is located in file ext/cdparanoia/gstcdparanoiasrc.c line 122 - 298 .

static gboolean
gst_cd_paranoia_src_open (GstAudioCdSrc * audiocdsrc, const gchar * device)
{
  GstCdParanoiaSrc *src = GST_CD_PARANOIA_SRC (audiocdsrc);
  gint i, cache_size;

  GST_DEBUG_OBJECT (src, "trying to open device %s (generic-device=%s) ...",
      device, GST_STR_NULL (src->generic_device));

  /* find the device */
  if (src->generic_device != NULL) {
    src->d = cdda_identify_scsi (src->generic_device, device, FALSE, NULL);
  } else {
    if (device != NULL) {
      src->d = cdda_identify (device, FALSE, NULL);
    } else {
      src->d = cdda_identify ("/dev/cdrom", FALSE, NULL);
    }
  }

  /* fail if the device couldn't be found */
  if (src->d == NULL)
    goto no_device;

  /* set verbosity mode */
  cdda_verbose_set (src->d, CDDA_MESSAGE_FORGETIT, CDDA_MESSAGE_FORGETIT);

  /* open the disc */
  if (cdda_open (src->d))
    goto open_failed;

  GST_INFO_OBJECT (src, "set read speed to %d", src->read_speed);
  cdda_speed_set (src->d, src->read_speed);

  for (i = 1; i < src->d->tracks + 1; i++) {
    GstAudioCdSrcTrack track = { 0, };

    track.num = i;
    track.is_audio = IS_AUDIO (src->d, i - 1);
    track.start = cdda_track_firstsector (src->d, i);
    track.end = cdda_track_lastsector (src->d, i);
    track.tags = NULL;

    gst_audio_cd_src_add_track (GST_AUDIO_CD_SRC (src), &track);
  }

  /* create the paranoia struct and set it up */
  src->p = paranoia_init (src->d);
  if (src->p == NULL)
    goto init_failed;

  paranoia_modeset (src->p, src->paranoia_mode);
  GST_INFO_OBJECT (src, "set paranoia mode to 0x%02x", src->paranoia_mode);

  if (src->search_overlap != -1) {
    paranoia_overlapset (src->p, src->search_overlap);
    GST_INFO_OBJECT (src, "search overlap set to %u", src->search_overlap);
  }

  cache_size = src->cache_size;
  if (cache_size == -1) {
    /* if paranoia mode is low (the default), assume we're doing playback */
    if (src->paranoia_mode <= PARANOIA_MODE_FRAGMENT)
      cache_size = 150;
    else
      cache_size = paranoia_cachemodel_size (src->p, -1);
  }
  paranoia_cachemodel_size (src->p, cache_size);
  GST_INFO_OBJECT (src, "set cachemodel size to %u", cache_size);

  src->next_sector = -1;

  return TRUE;

  /* ERRORS */
no_device:
  {
    GST_ELEMENT_ERROR (src, RESOURCE, OPEN_READ,
        (_("Could not open CD device for reading.")), ("cdda_identify failed"));
    return FALSE;
  }
open_failed:
  {
    GST_ELEMENT_ERROR (src, RESOURCE, OPEN_READ,
        (_("Could not open CD device for reading.")), ("cdda_open failed"));
    cdda_close (src->d);
    src->d = NULL;
    return FALSE;
  }
init_failed:
  {
    GST_ELEMENT_ERROR (src, LIBRARY, INIT,
        ("failed to initialize paranoia"), ("failed to initialize paranoia"));
    return FALSE;
  }
}

to use

in cdparanoia-III-10.2/interface/scan_devices.c (patched version) the procedure added for mac to open cd:

#ifdef __APPLE__
cdrom_drive *cdda_find_a_cdrom(int messagedest,char **messages){
    cdrom_drive *d = calloc(1, sizeof(cdrom_drive));
    if(!d)
        return NULL;
    d->interface = IOKIT_INTERFACE;
    return d;
}

#else 

But unfortunately I do not know how.

[ryandesign (Ryan Carsten Schmidt)]

[1427b4c6ee238989cb51586e349a5ff9dc6ad926/macports-ports]