Re: 2025Q3: gstreamer1 linker error on Slackware 15

Fekete Zoltán <fekete.zoltan%minux.hu@localhost> writes:

I'm using pkgsrc with a minimal Slackware 15, amd64.

2025Q3/multimedia/gstreamer1 does not link because it finds the OS's
/lib64/libtirpc.so.3. And, that one does not contain some symbols.

I found the solution is as simple as adding a new dependency
(devel/libtirpc) to the Makefile in gstreamer1. See the patch below.

--- a/multimedia/gstreamer1/Makefile
+++ b/multimedia/gstreamer1/Makefile
@@ -43,6 +43,9 @@ MAKE_ENV+=
LD_LIBRARY_PATH=${WRKSRC}/output/gst:${WRKSRC}/output/libs/gst/check

 .include "../../lang/python/application.mk"
 .include "../../devel/meson/build.mk"
+.if ${OPSYS} == "Linux"
+.include "../../devel/libtirpc/buildlink3.mk"
+.endif
 # test framework, only needed at test time
 BUILDLINK_DEPMETHOD.check=     build
 .include "../../devel/check/buildlink3.mk"

Generally, we have the concept of builtin.mk for a package that decides
if the OS-provided version is good enough, and if so bl3s it, and if
not, depends on and then bl3s the package itself.

My somewhat fuzzy impression is that tirpc is in base on many systems
and has been ejected on many GNU/Linux systems.

Thus the questions are
  - how does pkgsrc view tirpc - part of base, or a packaget to be
    depended on
  - does gstreamer1 need tirpc (the implementation, not a particular
    library name) on all platforms, or special for Linux?
  - if gstreamer1 is using tirpc, then why isn't it buildlinked all the
    time?
  - does a bl3 line on libtirpc on e.g. NetBSD result in no additional
    dependencies, because it's built in?


So while you are on the right track and we should figure out how to
solve your problem, I'd like to see it done in sound way that maximizes
the odds of also fixing this, and not breaking anything, on all the
platforms not tested on.