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 |