gstreamer1-gst-plugins-base @1.16.2_0+ogg+universal+x11: Failed to build. Missing /opt/local/lib/libgstsdp-1.0.0.dylib

[digital-pers0n]

I'm following this ​https://wiki.winehq.org/MacOS/Building#MacPorts guide to build wine under macOS 10.11, but it failed during compilation of gstreamer1-gst-plugins-base, because for some reason libgstsdp-1.0.0.dylib is missing.

Application Specific Information:
dyld: launch, loading dependent libraries
DYLD_LIBRARY_PATH=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gstreamer1-gst-plugins-base/gstreamer1-gst-plugins-base/work/gst-plugins-base-1.16.2-x86_64/gst-libs/gst/rtsp/.libs

Dyld Error Message:
  Library not loaded: /opt/local/lib/libgstsdp-1.0.0.dylib
  Referenced from: /opt/local/var/macports/*/GstRtsp-1.0
  Reason: image not found

[digital-pers0n]

Build log

[kencu (Ken)]

Well hey! my workaround for building wine on Mojave using the 10.13 SDK has now become their official recommended way to do it (at present). Something tells me Gcenx was involved in that...

For this ticket -- there was briefly an error in gobject-introspection that caused errors like this. It has since been fixed.

If you update Macports, you should get the new version, and things should then proceed for you.

[ryandesign (Ryan Carsten Schmidt)]

Replying to digital-pers0n:

I'm following this ​https://wiki.winehq.org/MacOS/Building#MacPorts guide to build wine under macOS 10.11

No need to follow any special instructions; sudo port install wine or sudo port install wine-devel or sudo port install wine-crossover should suffice.

[michaelld (Michael Dickens)]

Well carp ... I see this same error when building the port in issue. Probably a corner case where my tweaks to GI-O fail. Let me see what's going on & how to fix.

[michaelld (Michael Dickens)]

new case to sleuth through ... internal-to-build linking against libtool .la library ... hmmm ...

[michaelld (Michael Dickens)]

Almost there ... tricky stuff!

[michaelld (Michael Dickens)]

Finally got a solid combination that seems to do the trick. Here's the PR: ​https://github.com/macports/macports-ports/pull/9071

[idryzhov (Igor Ryzhov)]

Another way to fix the issue: ​https://github.com/macports/macports-ports/pull/9117

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #61690.

[michaelld (Michael Dickens)]

In d814edefb7b045e6cb14cfac7d88c1f91bbabe52/macports-ports (master):

gobject-introspection: add libtool library path tweaks to scanner

Hopefully the final tweaks, since they now handle both libtool and non-libtool library references, both in-build and outside-build.

Now works work: gobject-introspection, poppler, gstreamer1-gst-plugins-base, py38-gobject3, gexiv2, and libsoup

Ref: #61427

[michaelld (Michael Dickens)]

The PR fix for this isn't ideal, but it works for most cases & is better than the lack of fix we have at the moment.

I'm closing this ticket as "fixed". If somebody comes up with exactly the same issue then please reopen and post a log. If the issue is similar but maybe not the same, then please open a new ticket.

[dbevans (David B. Evans)]

I sorry to be so late in catching on to what the various gobject-introspection tweaks are doing but in an effort to fix poppler almost all the rest of the ports that use gobject-introspection seem to be broken.

Before the tweeks started, gobject-introspection generated typelibs that referenced the absolute path to any required dylibs. Now these references are only a relative path to the required libraries causing breakage as in this case. The proper solution to the topic of this question is, why does /opt/local/lib/libgstsdp-1.0.0.dylib not exist.

To be clear, typelibs should reference the absolute path to any required dylibs not just the library name. This is important since not all such libraries may be installed in the standard MacPorts prefix. An example is libraries that are installed in named subdirectories of that path. This is happening more and more as we shift to meson builds that do not use libtool at all.

Once that is done, I would like to push to get out the latest meson versions of glib2 and gobject-introspection which will probably invalidate these tweaks anyway.

Before things get farther out of hand lets stop and reconsider these tweaks. I propose reverting the gobject-introspection commits that were meant to fix legitimate problems in poppler and address those problems in poppler rather than mess with gobject-introspection. I'm already starting to do this in my development branches since this effort is blocking upgrades of many GNOME ports to 3.38 versions.

Again please pardon me for not bringing this up sooner but personal issues have kept me from being able spend the time necessary to keep on top of these changes.

[kencu (Ken)]

while gobject-introspection was in "flux" a whole mess of ports that rely on it were updated, and almost all of them are broken, unfortunately.

It was eventually fixed, and (I believe it) generates proper library references again, but now every single port that was updated while it was broken needs to be rev-bumped.

Sorry you missed all that -- there were dozens and dozens of messages about it.

Michael worked about a week solid on fixing gobject-introspection -- he'll be devestated if you invalidated all his tweaks, broke poppler again, and took us right back to where we started :>

[michaelld (Michael Dickens)]

"devastated" is maybe a little strong ... but I certainly wonder why undo all of these tweaks when they seem to work?

I do agree that updating glib2 & GO-I are useful endeavors. I'm fairly confident that: 1) these updates will invalidate my hard-determined tweaks. (2) current GO-I scanner still has the underlying issue. The issue is not in poppler or gstreamer1-gst-plugins-base, but in GO-I scanner. You can read up on my explanations in the PRs for the tweaks.

All of the above said: I'd much rather get these ports updated than let them lag further behind!

Hence I'd propose to leave the current GO-I scanner tweaks in place, -not- rev-bump any more GO-I dependent ports than necessary to get those changes in place (many GO-I scanned ports worked without the tweaks), and let you go about your updates. Then once you're about ready, it's not difficult for me to replicate the tweaks on the then-current GO-I port ... and, most importantly, we can then try to push fixes upstream -- which I really can't do at the moment since our GO-I port is so old compared with the current release.

[michaelld (Michael Dickens)]

What I think none of us want is to go back to where we were before the tweaks! That would require a huge effort, which IMHO is better spent solely moving forward rather than a huge step back before a huge step forward.

All of this said: The majority of the ports here are yours ... so do with them as you see fit & we'll watch from the sidelines until you say "boo" ;)

[kencu (Ken)]

we do have to update glib2. I have several ports that can't be upgraded until we do that.

There has been a PR in the queue for a year or more that is likely going to just get flushed. The hiccup, I believe, was building universal with meson was broken, but I fixed that a few months ago and I think that issue is OK now.