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