[PATCH] sunrpc: Turn bindresvport into a compatibility symbol

[H.J. Lu]

On Tue, Jul 7, 2020 at 10:04 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * H. J. Lu:
>
> > On Tue, Jul 7, 2020 at 9:13 AM Florian Weimer via Libc-alpha
> > <libc-alpha@sourceware.org> wrote:
> >>
> >> (This is a bit of a controversial change, but I'm not sure what our
> >> alternatives are, given the conflict with libtirpc.)
> >>
> >> bindresvport is mostly used along with Sun RPC functions.  libtirpc
> >> has its own implementation of it, and this implementation is
> >> is used when linking against libtirpc (under a separate symbol
> >> version).  The libtirpc implementation is superior because it
> >> provides a filter for well-known ports, addressing historic bug 456.
> >>
> >> Exceptions that use bindresvport without linking against libtirpc
> >> are torque (the resource manager) and the sign command in OBS
> >> (the build service).
> >
> > Have they been fixed?  Otherwise, they won't compile/link with glibc
> > 2.32.
>
> I suppose I can try to submit patches for them if this indeed the
> direction we want to move in.

I think it is a good thing when using with glibc, regardless of what
glibc does with
bindresvport.  We need to provide a solution before it is removed from
glibc API.

> The symbol clash with libtirpc is rather unfortunate.

True.

> >> This change turns bindresvport into a compatibility symbol because
> >> it is currently declared in a non-RPC header (<netinet/in.h>),
> >> and remvoes it from the public header.  In theory, it would be
> >> possible to make the declaration conditional on
> >> --enable-obsolete-rpc, but that would need quite a bit of shuffling
> >> for a declaration that would be removed soon anyway.
> >>
> >> Despite the declaration of bindresvport6 in a public header file,
> >> no implemention was provided by glibc, so this commit removes this
> >> declaration without further changes.
> >
> > I think that bindresvport6 can be removed with a separate patch.
>
> Sure, if we don't want to follow this approach.
>

I think 2 things are orthogonal.

-- 
H.J.