LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   Glibc rpcsvc vanished in l/glibc-2.14.1-i486-2.txz (http://www.linuxquestions.org/questions/slackware-14/glibc-rpcsvc-vanished-in-l-glibc-2-14-1-i486-2-txz-913702/)

Jeronimo Barros 11-15-2011 02:28 PM

Glibc rpcsvc vanished in l/glibc-2.14.1-i486-2.txz
 
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 (Post 4525056)
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 (Post 4525518)
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 (Post 4525570)
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.


All times are GMT -5. The time now is 02:54 AM.