Message: previous - next
Month: July 2012

SOLVED [ was Re: [trinity-devel] (glibc 2.16.0?) [was Re: [trinity-devel] tdebase - ftbfs - rpcgen - cannot find any C preprocessor]]

From: "David C. Rankin" <drankinatty@...>
Date: Sat, 14 Jul 2012 01:01:19 -0500
On 07/13/2012 12:11 PM, David C. Rankin wrote:
> On 07/11/2012 04:59 PM, Nix wrote:
>> On 9 Jul 2012, David C. Rankin outgrape:
>>> [ 49%] Generating nfs_prot_xdr.c
>>> cannot find any C preprocessor (cpp)
>>> rpcgen: C preprocessor failed with exit code 1
>> OK. This is glibc's rpcgen that's failing. It specifically searches for
>> /lib/cpp, then for /usr/ccs/lib/cpp (I kid you not) then fails if it
>> can't find either of them. It would be interesting to see an strace
>> of your rpcgen, to see what it's searching for...
>> I note that in glibc 2.14 and 2.15, the RPC calls were made unusable by
>> newly-linked programs, and rpcgen was removed. Because no replacement
>> was ready, this broke compilation of every RPC user out there, so most
>> distros patched it back in. I suspect arch's patching back in failed.
>> In glibc 2.16, RPC is back upstream again (until such time as libtirpc
>> is *really* ready to replace it), if glibc is configured with
>> --enable-obsolete-rpc, which absolutely every non-embedded distro will
>> be doing. Which explains why it works with glibc 2.16.
> Darrell, Nix,
>   Thanks. I think I can make a run a tweaking my install to get rpcgen to work
> with the tdebase build. I'll give it a go this pm.

It was either Arch or glibc 2.16 upstream, and it was the missing link in the
search locations Nix provided. To solve the issue, I simply created a symlink
/lib/cpp->/usr/bin/cpp and tdebase built fine.

  Just for the next two months, I wish upstream would

I posted this info to the Arch list as well.

David C. Rankin, J.D.,P.E.