Reexport RPC Interface and Reinstall RPC/NIS headers.

[Armin]

Since RPC/NIS has been obsoleted since glibc 2.14, but even it's replacement, libtirpc, can't build without it - reexport the interfaces and reinstall those headers for now untill everything is sorted out.

​https://projects.archlinux.org/svntogit/packages.git/plain/trunk/glibc-2.14-reexport-rpc-interface.patch?h=packages/glibc

​https://projects.archlinux.org/svntogit/packages.git/plain/trunk/glibc-2.14-reinstall-nis-rpc-headers.patch?h=packages/glibc

Seems that distros are doing it this way for a good reason (unknown to me). It can't hurt to have 2 more patches just to avoid trouble in BLFS and/or Beyond BLFS.

[bdubbs@…]

We already do this in Section 6.9 a different way:

cp -v ../glibc-2.15/sunrpc/rpc/*.h /usr/include/rpc
cp -v ../glibc-2.15/sunrpc/rpcsvc/*.h /usr/include/rpcsvc
cp -v ../glibc-2.15/nis/rpcsvc/*.h /usr/include/rpcsvc

Is there a functional difference?

[Armin]

That probably handles second patch, but not first one. RPC-dependent programs have to link against libtirpc for the functionality, but still most programs don't cover it natively and we have to explicitly define it with either LDFLAGS, sed's, patches, etc. First patch reexports rpc symbols so programs can use it like in earlier versions of glibc (I think).

[DJ Lucas]

Heh, I just recently stopped doing the above. Check the archives, this was first brought up in December of 2011. Despite the examples of the other distros, I think it's probably not a good idea now (even though I myself had suggested doing exactly this in the past) unless you want to go back and remove libtirpc from BLFS. At this point, we already have (just about?) everything in the book patched up to use libtirpc. If the glibc symbols are reexported, and a user installs libtirpc as a matter of course without being aware of the issue, it _might_ be problematic (I don't actually know, I haven't tried to really break anything in a while). Upstream developers were aware of these changes for some time prior, and should be well on their way to working this out.

[DJ Lucas]

For reference, the reverse of the glibc-commit has been in my homedir since then:

​http://www.linuxfromscratch.org/~dj/glibc-2.14-rpc_export-1.patch

[bdubbs@…]

AFAIK, all the programs that need it in BLFS have been integrated with libtirpc:

kde4runtime, samba3, nfs-utils, rpcbind, linux-pam, and libvirt

[Armin]

I don't think that this will make trouble if using libtirpc. But as I said, it can be used to fix/prevent issues Beyond BLFS, if you would to support that. If not, just tag this as wontfix, since everything in BLFS has been taken care of for now.

[Matthew Burgess]

If we do decide to fix up Glibc, then I think we should do as upstream have done:

​http://sourceware.org/git/?p=glibc.git;a=commitdiff_plain;h=021db4be6f1f4189f66feee066a495d49e92b93e

Regards,

Matt.

[bdubbs@…]

The comment says that it is still depricated and will be removed in the future. We've already taken care of it in BLFS and I don't think we should go back to a point that it interferes with libtirpc or requires regression in seven BLFS packages.

[Armin]

I've built libtirpc with the glibc 2.15 ... It misses several symbols that are not exported anymore since RPC implementation was removed.

/usr/lib/libtirpc.so.1: undefined symbol: key_encryptsession_pk

That one occours even when RPC headers are reinstalled using LFS ways.

It is mentioned here:

​http://sourceware.org/ml/libc-alpha/2011-06/msg00083.html

[ken@…]

Replying to Krejzi:

It built fine for me on LFS-svn from 20120428, using the remove-nis-2.patch which is in BLFS. AFAICS, use of RPC in BLFS is working fine : if libtirpc was brojken I would expect a lot of problems accessing my files using nfs3, but it all works.

[Armin]

Mhm, I feel stupid now ... I did not apply that patch to libtirpc.

[Armin]

Replying to matthew@…:

If we do decide to fix up Glibc, then I think we should do as upstream have done:

​http://sourceware.org/git/?p=glibc.git;a=commitdiff_plain;h=021db4be6f1f4189f66feee066a495d49e92b93e

Regards,

Matt.

Interesting. I did not notice this untill now. But, if upstream decided to do it, maybe we should do it too now so we can incorporate changes in BLFS if release is to happen this year.