trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: July 2012

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

From: Darrell Anderson <humanreadable@...>
Date: Tue, 10 Jul 2012 09:57:40 -0700 (PDT)
> As /usr/bin is a standard FHS location, I'd like to know
> where rpcgen is hard-coded to look for the cpp executable. I
> hope this is not Yet Another WTF example of egghead
> development.

For the moment I believe this is an Arch packaging problem, although eventually we'll see what other distros might be affected too. :-)

When building glibc, the expected locations for the cpp executable are defined in glibc sunrpc/rpc_main:

#define SVR4_CPP "/usr/ccs/lib/cpp"
#define SUNOS_CPP "/lib/cpp"

I looked at the glibc 2.16, 2.15 and 2.11.1 sources and those expected locations have not changed.

The cpp executable is installed with the gcc package.

With Slackware, cpp is built to install to /usr/bin. In the Slackware package post-install script, a sym link is created from /lib/cpp -> /usr/bin/cpp.

Does Arch create such a sym link in /lib/cpp? My guess is something changed in the Arch build script with gcc that no longer creates that sym link or no longer installs cpp to /lib/cpp.

I suppose this could be better. That is, the glibc people could add a third define statement. The gcc people could update their make files to install cpp to /lib/cpp rather than /usr/bin/cpp. I don't know why packagers have to adjust for either but that seems to be the case at the moment.

In the end, I think the bug might not be our problem. Check with the Arch people who build gcc and find out why cpp is not built to install to /lib/cpp or why a sym link from /lib/cpp -> /usr/bin/cpp is not created in the package.

Darrell