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]


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