[arch-general] rpcgen - cannot find any C preprocessor?
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? -- David C. Rankin, J.D.,P.E.
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.
Hi David, On Sat, Jul 14, 2012 at 8:01 AM, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
Devs,
I should point out that most devs are not subscribed to this ML.
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.
I don't know this package too well, but a priori it sounds like a bug. If it has not yet been filed, I suggest opening a report at bugs.archlinux.org, that way someone will look into it. Cheers, Tom
On Sat, Jul 14, 2012 at 2:17 PM, Tom Gundersen <teg@jklm.no> wrote:
Hi David,
On Sat, Jul 14, 2012 at 8:01 AM, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
Devs,
I should point out that most devs are not subscribed to this ML.
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.
I don't know this package too well, but a priori it sounds like a bug. If it has not yet been filed, I suggest opening a report at bugs.archlinux.org, that way someone will look into it.
Cheers,
Tom
Allan already knows about it and is talking to upstream. For now, use the -Y parameter to rpcgen.
On 07/14/2012 07:32 AM, Jan Steffens wrote:
Allan already knows about it and is talking to upstream.
For now, use the -Y parameter to rpcgen.
Thanks Tom, Jan, I always like asking on the list first before opening a bug report. Been yelled at many times because it was upstream and not an arch problem. So I like to confirm first. If Allan is talking with upstream about it, I'll hold off for now. Let me know if you want me to file it to make sure it doesn't slip though the cracks. Happy to do it. -- David C. Rankin, J.D.,P.E.
participants (3)
-
David C. Rankin
-
Jan Steffens
-
Tom Gundersen