By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.

Bug 1082

Summary:	Build issue: glibc 2.16 - tdelibs FTBFS kioslave rpcgen - cannot find any C preprocessor (cpp)
Product:	TDE	Reporter:	David C. Rankin <trin>
Component:	tdebase	Assignee:	Timothy Pearson <kb9vqf>
Status:	RESOLVED NOTOURPROBLEM
Severity:	blocker	CC:	bugwatch, darrella
Priority:	P5
Version:	R14.0.0 [Trinity]
Hardware:	All
OS:	Linux
Compiler Version:		TDE Version String:
Application Version:		Application Name:

Description David C. Rankin 2012-07-09 22:49:58 CDT

Following update of glibc (2.15-12 -> 2.16-) tdebase fails to build from source displaying the following build failure:

[ 49%] Building CXX object kioslave/man/CMakeFiles/kio_man-module.dir/kio_man.cpp.o
Linking CXX shared module kio_man.so
[ 49%] Built target kio_man-module
[ 49%] Generating kmanpart.moc
Scanning dependencies of target libkmanpart-module
[ 49%] Building CXX object
kioslave/man/CMakeFiles/libkmanpart-module.dir/kmanpart.cpp.o
Linking CXX shared module libkmanpart.so
[ 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
make[2]: *** [kioslave/nfs/nfs_prot_xdr.c] Error 1
make[1]: *** [kioslave/nfs/CMakeFiles/kio_nfs-module.dir/all] Error 2
make: *** [all] Error 2

  All packages in the build order up to tdebase (including tdelibs) build fine with glibc 2.16. Researching similar failures suggest that there is a problem with a hardcoded path concerning rpcgen in the TDE code. That being said, the location of cpp remains in /usr/bin as it has always been suggesting that the rpcgen issue is slightly more than a hardcoded path in TDE. D. Anderson has suggested a real-time patch using sed to the following files:

tdebase/kioslave/nfs/CMakeLists.txt:34
tdebase/kioslave/nfs/CMakeLists.txt:38
tdebase/kioslave/nfs/Makefile.am:21
tdebase/kioslave/nfs/Makefile.am:25

  Darrell has also confirmed that tdebase is the only primary app in the GIT tree that calls rpcgen.

  In order to insure that TDE builds on the current glibc and to give TDE a bit of longevity after release, I am elevating this to a blocker, considering it a final part of the gcc 4.7 mess so that build failures are not experienced by each distro as they move to 2.16 (it being the current glibc).

  I'll report back results of testing as suggested by Darrell. Hopefully this is the last gcc/glibc transition related fish we shall have to fry for R14 :)

Comment 1 Darrell 2012-07-10 11:58:47 CDT

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.

Comment 2 Darrell 2012-07-10 12:01:38 CDT

I added "Build issue" to the summary description.

Comment 3 David C. Rankin 2012-07-14 00:59:42 CDT

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>