[arch-general] [SOLVED/WORKAROUND] BUG? Re: rpcgen - cannot find any C preprocessor?

[David C. Rankin]

On 07/08/2012 09:36 PM, David C. Rankin wrote:
> All,
> 
>   I have a new build error with tdebase (kdebase) in trinity that I think is the
> result of a hardwired path somewhere and some recent gcc change. The error I get is:
> 
> [ 49%] Built target libkmanpart-module
> [ 49%] Generating nfs_prot_xdr.c
> cannot find any C preprocessor (cpp)
> rpcgen: C preprocessor failed with exit code 1
> 
> ??  It has always built without issue.
> 
>   Looking, I find https://bbs.archlinux.org/viewtopic.php?pid=1126084#p1126084
> which references a hardcoded path problem in hamlib that was fixed by providing
> specific path information to rpcgen.
> 
>   My question is, has there been some change to gcc that would be expected to
> cause this type error? I ask to confirm this before I start hacking the TDE
> build files on my end. Has anyone else seen this issue pop up lately?
> 

Devs,

  There is either a bug in Arch's packaging of glibc/rpcgen or it is upstream.
rpcgen was removed from glibc a while back and then was put back in when
libtirpc wasn't ready for use. Given this failure, after much investigation, it
was discovered that the rpcgen in glibc on arch searches for cpp in:

(1) /lib/cpp
(2) /usr/ccs/lib/cp  (really...?)

  Neither of which are present on Arch any longer leading to the tdebase build
failure. To fix the problem all I did was create a symlink in the archroot for
/lib/cpp->/usr/bin/cpp. Now tdebase builds just fine.

  I know the /lib/cpp link disappeared somewhere between June 4, 2012 and July
8, 2012 because tdebase was building fine on 6/4 and then failed beginning
around 7/8.

  With all the changes to glibc 2.16 I don't know if this missing link is an
arch packaging issue or upstream. Regardless, it is a problem that affects
packages relying on rpcgen.

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