[SOLVED] Glibc rpcsvc vanished in l/glibc-2.14.1-i486-2.txz

Jeronimo Barros · 11-15-2011, 02:28 PM

Today I tried to compile postfix in a slackware-current fresh instllation (changelog Sun Nov 13 16:03:06 UTC 2011) and got this error:

dict_nis.c:42:27: fatal error: rpcsvc/ypclnt.h: No such file or directory

In an older install:

root@ushuaia:~# grep ypclnt.h /var/adm/packages/*
/var/adm/packages/glibc-2.13-x86_64-5:usr/include/rpcsvc/ypclnt.h

But in the new one this directory doesn't appear.

Does anyone know what happened ?

Thanks in advance.

disturbed1 · 11-15-2011, 05:40 PM

That's not the only error with 2.14.1.
rpc has been removed, and replaced with a different library libtirpc.

About the rpc fiasco
http://sourceware.org/git/?p=glibc.g...iff;h=acee4873
http://sourceware.org/git/?p=glibc.g...iff;h=bdd816a3
^ Those patches will reinstate the missing headers, and fix a couple more bugs in glibc.

ReaperX7 · 11-15-2011, 08:34 PM

I hope those can be added to the existing package like a patch by Patrick soon if it is needed.

disturbed1 · 11-15-2011, 09:09 PM

Quote:

Originally Posted by ReaperX7

I hope those can be added to the existing package like a patch by Patrick soon if it is needed.

It's needed, actually it's pretty much required

There's quite a few packages that will FTBFS -
nfs-utils

Code:

../../support/include/rpcsvc/nfs_prot.h:9:21: fatal error: rpc/rpc.h: No such file or directory

Funny thing is, Drepper says to use TI-RPC, but you can't build TI-RPC against this Glibc.
http://sourceforge.net/tracker/index...75&atid=903784

ReaperX7 · 11-15-2011, 09:27 PM

I'll keep my eye out for glibc-2.14.1-patch*date or patch version number*-i486/x86_64-1.txz fairly soon on the -current tree.

Darth Vader · 11-16-2011, 07:42 AM

Quote from the NEWS file of GLIBC Version 2.14

Code:

* The RPC implementation in libc is obsoleted.  Old programs keep working
  but new programs cannot be linked with the routines in libc anymore.
  Programs in need of RPC functionality must be linked against TI-RPC.
  The TI-RPC implemtation is IPv6 enabled and there are other benefits.

  Visible changes of this change include (obviously) the inability to link
  programs using RPC functions without referencing the TI-RPC library, the
  removal of the RPC headers from the glibc headers, and the lack of
  symbols defined in <rpc/netdb.h> when <netdb.h> is installed.
  Implemented by Ulrich Drepper.

That's it, folks! Even you love or hate it, you should live with it!

ponce · 11-16-2011, 09:09 AM

instead, I personally agreed with the comment on top of the gentoo patch (inside their patches tarball)

Quote:

export the rpc symbols and headers again until we can get libtirpc sorted
out as a proper and full replacement

patch from fedora (if redhat can't get it to work as the maintainers of all
these packages, then what chance do we have!)

GazL · 11-16-2011, 09:09 AM

Quote:

Originally Posted by Darth Vader

Quote from the NEWS file of GLIBC Version 2.14

Code:

* The RPC implementation in libc is obsoleted.  Old programs keep working
  but new programs cannot be linked with the routines in libc anymore.
  Programs in need of RPC functionality must be linked against TI-RPC.
  The TI-RPC implemtation is IPv6 enabled and there are other benefits.

  Visible changes of this change include (obviously) the inability to link
  programs using RPC functions without referencing the TI-RPC library, the
  removal of the RPC headers from the glibc headers, and the lack of
  symbols defined in <rpc/netdb.h> when <netdb.h> is installed.
  Implemented by Ulrich Drepper.

That's it, folks! Even you love or hate it, you should live with it!

I think you missed the point that tirpc isn't quite ready to take over yet, and still relies on some of the parts of glibc that they've removed and as disturbed1 pointed out above it won't build against glibc 2.14.

Deprecating/Obsoleting old stuff is all well and good, but one should really make sure that the new replacement is in place and ready to go before you take the old one away. Just another example of disjointed development in the linux ecosystem. No wonder the BSD guys laugh at us.

disturbed1 · 11-16-2011, 09:33 AM

Quote:

Originally Posted by GazL

I think you missed the point that tirpc isn't quite ready to take over yet, and still relies on some of the parts of glibc that they've removed and as disturbed1 pointed out above it won't build against glibc 2.14.

Deprecating/Obsoleting old stuff is all well and good, but one should really make sure that the new replacement is in place and ready to go before you take the old one away. Just another example of disjointed development in the linux ecosystem. No wonder the BSD guys laugh at us.

You can build libtirpc, but it needs patches. LFS is using patches from Debain.
http://linuxfromscratch.org/pipermai...er/003835.html

I've been running FreeBSD 8.2 and 9.0rc on a few VMs and spare Laptops. Once 9.0 is released, I'm going to see how it fairs on a modern PC with the Nvidia binary driver.

Darth Vader · 11-16-2011, 09:46 AM

Then, the one billion russian dollars question:

Why we need this frakking pre-alpha quality GLIBC, on release 2.14? Because?

Jeronimo Barros · 11-16-2011, 10:27 AM

So, falling back to the glibc-solibs-2.13-i486-4.txz...

Thank you very much for the explanations.

ponce · 11-16-2011, 12:47 PM

I think the error, Darth, has been to deprecate the rpc stuff after the 2.14.x branch was already declared stable.
I also cannot agree with Ulrich, but maybe "pre-alpha quality" is unfair.

ponce · 11-26-2011, 04:31 AM

I was trying to build the newest libvirt on -current and got stuck too without a working XDR implementation

so I tried to use libtirpc, discovering that DES and NIS were broken (

), but seems to builds fine if patched.
the only thing is that (following LFS's advices) you have to install some headers just to let libtirpc build (you can remove them after building, but they will be needed to build postfix - or either I think you have to patch out its nis support).

if you want to have a look or test with apps that need rpc (they must use the libtirpc headers in /usr/include/tirpc) or with libvirt, sources are here:

http://ponce.cc/slackware/testing/rpcnis-headers/

(EDIT: postfix seems to build with these installed, and it runs also after)

http://ponce.cc/slackware/testing/libtirpc/

http://ponce.cc/slackware/testing/libvirt/

but I really don't know which way Pat is gonna take with this issue, so take this just as testing stuff...
comments/suggestions/fixes are obviously welcomed

ponce · 12-15-2011, 01:56 AM

if someone is interested, I've started moving these things in git branches on github

https://github.com/Ponce/current-sou...rpc/l/libtirpc

already updated (the no-des.patch got prettier

)

Jeronimo Barros · 12-15-2011, 04:59 AM

Ponce, thank you for the informations and scripts.

I'll try your scripts as soon as possible.