Re: 2025Q3: gstreamer1 linker error on Slackware 15

[Greg Troxel <gdt%lexort.com@localhost>]

Paolo Vincenzo Olivo <vins%NetBSD.org@localhost> writes:

> RPC is described in RFC 5531, published after Sun relicensed the API
> as 3-clause-bsd in 2009. 
> https://www.rfc-editor.org/rfc/rfc5531 
>
> From my understanding: 
>
> * On BSDs and macOS rpc(3) is embedded in the C library.
> * SunOS has the original Sun RPC which requires linking against libnls,
>   and is also transport independent.
> * AIX, SCO and QNX provide a compatible interface which I haven't
>   investigated in detail (might just be the same port of Sun RPC). 
> * Contemporary Linux generally lacks RPC support, as removed from glibc
>   2.26 in 2017. 
>   https://lists.gnu.org/archive/html/info-gnu/2017-08/msg00000.html
>   https://wiki.gentoo.org/wiki/Project:Toolchain/Glibc_2.26_porting_notes/RPC_implementation
>
> Taking all this into consideration, our only supported platform
> requiring libtirpc appears to be Linux (+Cygwin?; +Haiku?).

So basically everything except Linux has it in libc.

> Regarding issues with RPC on Slackware, see:
> https://www.linuxquestions.org/questions/slackware-14/glibc-rpcsvc-vanished-in-l-glibc-2-14-1-i486-2-txz-913702-print/ 
>
> Libtirpc requires patching to be able to compile outside of Linux, as it
> invokes the mutex(5) kernel API found in linux/mutex.h.

And, if it's providing something in base, with no benefits, modifying it
seems best avoided.

>> Thus the questions are
>>   - how does pkgsrc view tirpc - part of base, or a packaget to be
>>     depended on
>
> It's part of base on most systems, so should it perhaps be addressed inside a  
> dedicated mk/rpc.builtin.mk file? 

Whether we use mk/foo.builtin.mk or just bl3 on category/foo is
variable.  Generally we have mk/ when there are multiple implementations
or it's particularly complicated, like pgsql/mysql/curses, and just the
package bl3 when it is just a packaeg.   For example, even openssl is
just a package bl3.

>>   - does gstreamer1 need tirpc (the implementation, not a particular
>>     library name) on all platforms, or special for Linux?
>
> I'm positive RPC support is required regardless of the target platform. 

ok, good to know.

>>   - if gstreamer1 is using tirpc, then why isn't it buildlinked all the
>>     time?
>
> I just updated the builtin.mk file in devel/libtirpc to detect a native
> RPC API.

Great!

>>   - does a bl3 line on libtirpc on e.g. NetBSD result in no additional
>>     dependencies, because it's built in?
>
> It seems to work now, I attempted to buildlink libtirpc unconditionally
> inside gstreamer1 and sysutils/fam and it resulted in no additional
> dependencies. 
>
> I think wm/cde should buildlink it too. 

That sounds like the right approach to me.

>> 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.
>
> At this point my take is that we either:
>
> * fix libtirpc to build on any platform so we don't have to forcibly
>   rely on a built-in implementation (which on older Unices may result in
>   incompatibilities)

Someone who cares can do that, if it is actually a problem.

> * Further enhance the builtin.mk in libtirpc so that it covers all
>   built-in implementations and informs the user if no compatible API was
>   found outside of Linux.

That would be great.  I guess if no builtin is found, and no linux,
there's a failure.  I just committed a clearer description of that issue
into Makefile and DESCR.  Should it happen, we can revisit, but I think
what you've done and adding the bl3 to things that use rpc is a big step
forward.

> Also, take into account that RPC belongis to the past and I don't
> think anybody is developing new software using it.

Hey, so is C!  Anything not written in rust or go is becoming
irrelevant.  Of the ancient languages, only Scheme remains righteous.