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.
<rant> Just for the next two months, I wish upstream would QUIT DORKING WITH THE DAMN PACKAGES!!! </rant>
I posted this info to the Arch list as well.
http://bugs.pearsoncomputing.net/bugzilla/show_bug.cgi?id=1082 [RESOLVED] [NOTOURPROBLEM]