On Saturday, June 11, 2011 16:11:35 Mike Frysinger wrote: > historically, glibc provided all the ugly rpc support (while not nearly as > relevant today, it still is used by way of nfs support). the glibc > maintainers have opted to stop supporting this. at first they declined to > accept new features, but now they've started removing support for new code > to build against it. > > libtirpc started off to support the new features (namely ipv6 support), but > has now taken on a new roll of supporting all the rpc code. > > so if you have a build bug due to glibc-2.14 due to missing rpc/ or rpcsvc/ > header, you're going to have to convert over to libtirpc. > > something like: > inherit toolchain-funcs > ... > append-cppflags $($(tc-getPKG_CONFIG) libtirpc --cflags) > export LIBS+=" $($(tc-getPKG_CONFIG) libtirpc --libs)" > > obviously the LIBS part will need tweaking based on your package.
after seeing the feedback of broken packages, and libtirpc itself not being ready as a full replacement for the rpc symbols, i plan on implementing the same kind of hack that fedora is using atm: re-exporting the symbols and headers. this will give us time to migrate packages over to libtirpc without being stuck on glibc-2.13 indefinitely. the ABI will not be adversely affected long or short or any other term. -mike
signature.asc
Description: This is a digitally signed message part.
