Tim, Darrell,
This is probably arch, but I've hit a new tdebase failure regarding rpcgen:
[ 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
Googling, this looks like it is due to some hardcoded path somewhere in tde. I do not know what changed with the latest gcc update, but it looks like we need to add preprocessor directives to the code to handle this change. I'll provide patch update information later on this week.
This is probably arch, but I've hit a new tdebase failure regarding rpcgen:
[ 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
Googling, this looks like it is due to some hardcoded path somewhere in tde. I do not know what changed with the latest gcc update, but it looks like we need to add preprocessor directives to the code to handle this change. I'll provide patch update information later on this week.
There is bug report 714, kio_man does not work with some distros. The reported problem affects run-time and not compiling, but try applying the patch to tdebase and see what happens?
I rebuilt everything Saturday and experienced no such build error. I have been applying that patch for many months.
There was one commit several days ago (513ffc6e) that requires rebuilding tdelibs as well as tdebase, but I don't think that patch is related to your problem description.
Darrell
On 07/09/2012 12:53 PM, Darrell Anderson wrote:
There is bug report 714, kio_man does not work with some distros. The reported problem affects run-time and not compiling, but try applying the patch to tdebase and see what happens?
Will give it a go and report back.
I rebuilt everything Saturday and experienced no such build error. I have been applying that patch for many months.
There was one commit several days ago (513ffc6e) that requires rebuilding tdelibs as well as tdebase, but I don't think that patch is related to your problem description.
That is probably the issue. This is CMake, so it's a black-box from the build script side. In this run, I had rebuilt _everything_ from hal -> tdebase when the failure occurred. So any changes to GIT would have been incorporated into the build.
The commit looks like the candidate, but I'll report back in ~1hr. with results of building with the 714 patch.
On 07/09/2012 01:42 PM, David C. Rankin wrote:
There is bug report 714, kio_man does not work with some distros. The reported problem affects run-time and not compiling, but try applying the patch to tdebase and see what happens?
Will give it a go and report back.
Darrell,
714 cannot be the issue. Arch uses mandb:
14:00 providence:~/tde/pkg> which mandb /usr/bin/mandb
The issue is something that has changed or been introduced since 6/24/12, my last build of tdebase. I have kicked off another full build with this mornings sources and will see what happens. I built tdebase with debug so hopefully it will give more details about any failure.
Dne po 9. července 2012 David C. Rankin napsal(a):
On 07/09/2012 01:42 PM, David C. Rankin wrote:
There is bug report 714, kio_man does not work with some distros. The reported problem affects run-time and not compiling, but try applying the patch to tdebase and see what happens?
Will give it a go and report back.
Darrell,
714 cannot be the issue. Arch uses mandb:
14:00 providence:~/tde/pkg> which mandb /usr/bin/mandb
The issue is something that has changed or been introduced since 6/24/12, my last build of tdebase. I have kicked off another full build with this mornings sources and will see what happens. I built tdebase with debug so hopefully it will give more details about any failure.
David,
It is no coincidence in tdebase currently on branch 3.5.13-sru?
Slavek --
On 07/09/2012 02:14 PM, Slávek Banko wrote:
David,
It is no coincidence in tdebase currently on branch 3.5.13-sru?
Slavek
Slavek,
Thanks! No, these are from the regular GIT sources I pull with the script:
"switch_all_submodules_to_head_and_clean"
What can I check in my GIT tree to make sure I have the latest source? I did my last update this morning at 0700 CDT (1200 zulu). Here is my latest FETCH_HEAD:
14:24 providence:~/tde/tde/.git> cat FETCH_HEAD ce6b0ebe5802b7eb26ce9ab599577bdb083d5e53 branch 'master' of http://scm.trinitydesktop.org/scm/git/tde
That is what I should have right?
Dne po 9. července 2012 David C. Rankin napsal(a):
On 07/09/2012 02:14 PM, Slávek Banko wrote:
David,
It is no coincidence in tdebase currently on branch 3.5.13-sru?
Slavek
Slavek,
Thanks! No, these are from the regular GIT sources I pull with the script:
"switch_all_submodules_to_head_and_clean"
What can I check in my GIT tree to make sure I have the latest source? I did my last update this morning at 0700 CDT (1200 zulu). Here is my latest FETCH_HEAD:
14:24 providence:~/tde/tde/.git> cat FETCH_HEAD ce6b0ebe5802b7eb26ce9ab599577bdb083d5e53 branch 'master' of http://scm.trinitydesktop.org/scm/git/tde
That is what I should have right?
Yes, switch_all_submodules_to_head_and_clean use "git checkout master", so this should definitely switch to the main branch.
Slavek --
On 07/09/2012 02:07 PM, David C. Rankin wrote:
The issue is something that has changed or been introduced since 6/24/12, my last build of tdebase. I have kicked off another full build with this mornings sources and will see what happens. I built tdebase with debug so hopefully it will give more details about any failure.
Looking at my update logs, the following are the likely candidates that could have caused the problem (if it is on my end):
[2012-06-26 12:05] upgraded glibc (2.15-11 -> 2.15-12) [2012-06-26 16:00] upgraded linux (3.4.3-1 -> 3.4.4-2)
[2012-07-03 11:15] upgraded gcc-libs (4.7.1-1 -> 4.7.1-3) [2012-07-03 11:15] upgraded gcc (4.7.1-1 -> 4.7.1-3) [2012-07-03 11:15] upgraded gcc-fortran (4.7.1-1 -> 4.7.1-3) [2012-07-03 11:15] upgraded gcc-objc (4.7.1-1 -> 4.7.1-3)
[2012-07-05 19:59] upgraded linux-api-headers (3.3.8-1 -> 3.4.4-1) [2012-07-05 19:59] upgraded glibc (2.15-12 -> 2.16.0-1) [2012-07-05 19:59] upgraded gcc-libs (4.7.1-3 -> 4.7.1-4) [2012-07-05 19:59] upgraded gcc (4.7.1-3 -> 4.7.1-4) [2012-07-05 19:59] upgraded gcc-fortran (4.7.1-3 -> 4.7.1-4) [2012-07-05 19:59] upgraded gcc-objc (4.7.1-3 -> 4.7.1-4)
Of all the updates, this is probably the one:
[2012-07-05 19:59] upgraded glibc (2.15-12 -> 2.16.0-1)
Can somebody who know how glibc figures into the error below, please take a look at the glibc changes in (2.15-12 -> 2.16.0-1). The Arch link to the diffs (nicely laid out is):
https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages...
The original tde failure to build error was:
[ 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
Of all the updates, this is probably the one:
[2012-07-05 19:59] upgraded glibc (2.15-12 -> 2.16.0-1)
Can somebody who know how glibc figures into the error below, please take a look at the glibc changes in (2.15-12 -> 2.16.0-1). The Arch link to the diffs (nicely laid out is):
The glibc update makes sense as the cause with respect to your error message. Note: The next Slackware release is getting closer to release candidate status, but the last I read about that progress was the next release was not going to bump to glibc 2.16 because that would start a whole new round of stability and testing issues. I'm not saying glibc is buggy (could be), only that glibc 2.16 is different enough from 2.15 that some ABI breakage is possible or like the gcc 4.7 headaches, is more strict with respect to compiling.
Can you roll back glibc? That would not patch the problem but at least makes the cause knowable for patching.
Darrell
On 07/09/2012 02:39 PM, Darrell Anderson wrote:
Can you roll back glibc? That would not patch the problem but at least makes the cause knowable for patching.
Darrell
Well -- dunno :(
Of course I 'can' roll back, but that is basically creating a new 'archroot' 'chroot' environment and specifically limiting glibc to the last 2.15-12 release on Arch. What I don't know is "How many other packages are changed and dependent on 2.16 now?" I can figure that out, but it will take some figuring.
The _BIG_ question is "Why is tdebase failing with 2.16?" Think about it... Everything _else_ in the build order up to tdebase, builds _fine_ on glibc 2.16. That is:
# array for Archlinux specific dependencies (remote sources) declare -a archdeps archdeps=('apetag' 'hal-info' 'hal' 'libutempter' 'xmedcon' 'libnjb' 'libkarma' 'mt-daapd')
_and_
## array of TDE modules to build (source from local GIT tree tarballs) declare -a tbo tbo=("dependencies/$useqt" 'dependencies/tqtinterface' 'dependencies/arts' 'dependencies/dbus-tqt' 'dependencies/dbus-1-tqt' 'dependencies/tqca-tls' 'dependencies/libart-lgpl' 'dependencies/avahi-tqt' 'dependencies/libcaldav' 'dependencies/libcarddav' 'dependencies/sip4-tqt' 'dependencies/python-tqt' 'dependencies/tqscintilla' # not currently building 'dependencies/tqscintilla-plugin' # not currently building 'tdelibs' 'tdebase' <snip>
TQt3 and tdelibs are some huge packages to build. If there was a generic problem in glibc 2.16, I would expect to see build failures in one of those, or in the other 19 packages that build.
From googling similar failures, the problem seems to be the hardcoded location of rpcgen in tdebase. Here is a similar issue found in the arch hamlib packages. I'll try a similar solution:
https://bbs.archlinux.org/viewtopic.php?pid=1126084
On 07/09/2012 03:11 PM, David C. Rankin wrote:
From googling similar failures, the problem seems to be the hardcoded location of rpcgen in tdebase. Here is a similar issue found in the arch hamlib packages. I'll try a similar solution:
Crud, How would I change this in the tdebase CMake files? I'll peck around, but if somebody knows, let me know -- thanks!
On 07/09/2012 03:16 PM, David C. Rankin wrote:
On 07/09/2012 03:11 PM, David C. Rankin wrote:
From googling similar failures, the problem seems to be the hardcoded location of rpcgen in tdebase. Here is a similar issue found in the arch hamlib packages. I'll try a similar solution:
Crud, How would I change this in the tdebase CMake files? I'll peck around, but if somebody knows, let me know -- thanks!
Just finished another run and still tdebase ftbfs:
[ 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
Any idea where I should look first? CMakefiles? TDE code/regular Makefiles?
Also -- doesn't rpcgen get called before this point in the build? Either with tdebase or in tdelibs? If so, that should at least point us to how the rpcgen call should be handled. This smells like a messed up CMakeFiles issue that wasn't caught until glibc 2.16. Like with:
kioslave/man/CMakeFiles/libkmanpart-module.dir
I'll pick around later tonight. Any ideas - please send them on :)
From googling similar failures, the
problem seems to be the hardcoded location of rpcgen in tdebase. Here is a similar issue found in the arch hamlib packages. I'll try a similar solution:
Crud, How would I change this in the tdebase CMake
files? I'll peck around, but if somebody knows, let me know -- thanks!
I'll pick around later tonight. Any ideas - please send them on :)
Just a guess, based on the forum link you provided.
As a test you could run sed -i in real time in your build script against the following two files, or edit them and create a patch:
tdebase/kioslave/nfs/CMakeLists.txt:34: COMMAND rpcgen -c -o mount_xdr.c ${CMAKE_CURRENT_SOURCE_DIR}/mount.x tdebase/kioslave/nfs/CMakeLists.txt:38: COMMAND rpcgen -c -o nfs_prot_xdr.c ${CMAKE_CURRENT_SOURCE_DIR}/nfs_prot.x
tdebase/kioslave/nfs/Makefile.am:21: cd $(srcdir) && rpcgen ./mount.x tdebase/kioslave/nfs/Makefile.am:25: cd $(srcdir) && rpcgen ./nfs_prot.x
On my system, 'whereis -b cpp' indicates the location is /usr/bin --- an FHS standard location. Where is that file installed in Arch? Or is the file name changed in Arch? That would be the path to add with the -Y switch.
Long term we probably need to patch the CMakeLists.txt file:
* Discover the path of cpp * Add the -Y switch
Searching the GIT repository indicates tdebase is the only packages that calls rpcgen.
Darrell
On 07/09/2012 07:16 PM, Darrell Anderson wrote:
Just a guess, based on the forum link you provided.
As a test you could run sed -i in real time in your build script against the following two files, or edit them and create a patch:
tdebase/kioslave/nfs/CMakeLists.txt:34: COMMAND rpcgen -c -o mount_xdr.c ${CMAKE_CURRENT_SOURCE_DIR}/mount.x tdebase/kioslave/nfs/CMakeLists.txt:38: COMMAND rpcgen -c -o nfs_prot_xdr.c ${CMAKE_CURRENT_SOURCE_DIR}/nfs_prot.x
tdebase/kioslave/nfs/Makefile.am:21: cd $(srcdir) && rpcgen ./mount.x tdebase/kioslave/nfs/Makefile.am:25: cd $(srcdir) && rpcgen ./nfs_prot.x
Sounds like you do some 'pretty darn good guessing'...
On my system, 'whereis -b cpp' indicates the location is /usr/bin --- an FHS standard location. Where is that file installed in Arch? Or is the file name changed in Arch? That would be the path to add with the -Y switch.
In the same spot:
22:13 archangel:/dat_e/abs/util-linux> whereis -b cpp cpp: /usr/bin/cpp
Long term we probably need to patch the CMakeLists.txt file:
- Discover the path of cpp * Add the -Y switch
Searching the GIT repository indicates tdebase is the only packages that calls rpcgen.
That looks like the information we need for a bug report. Since the fix looks simple from this standpoint, I'll open the bug and mark it a "Blocker" for R14. Hopefully, this will be the last little 'surprise' of the gcc/glib update season. But, since we are working on making R14 the best stable TDE release to date, I want it to build and run on the current libs -- that way we get a bit of longevity from the initial release and not a flood of bug reports filed right off the bat as each distro moves to glibc 2.16.
Darrell
((You really need to install and run at least one partition of Arch. Talk about the excitement of trying to iterate down to a final finished project the size of TDE when the foundation is constantly changing -- wow! It never gets old...))
Seriously, I think there has rarely been any 3 month stretch before in recent history where so many of the underlying libraries have had significant upstream changes as TDE has tried to dial in a next release -- not to mention one with the polish and improvement that TDE has undergone to get to the point of this R14 release.
Little more time on the front end -- better reviews, less bugs on the backend :)
On 07/09/2012 10:23 PM, David C. Rankin wrote:
On 07/09/2012 07:16 PM, Darrell Anderson wrote:
Just a guess, based on the forum link you provided.
As a test you could run sed -i in real time in your build script against the following two files, or edit them and create a patch:
tdebase/kioslave/nfs/CMakeLists.txt:34: COMMAND rpcgen -c -o mount_xdr.c ${CMAKE_CURRENT_SOURCE_DIR}/mount.x tdebase/kioslave/nfs/CMakeLists.txt:38: COMMAND rpcgen -c -o nfs_prot_xdr.c ${CMAKE_CURRENT_SOURCE_DIR}/nfs_prot.x
tdebase/kioslave/nfs/Makefile.am:21: cd $(srcdir) && rpcgen ./mount.x tdebase/kioslave/nfs/Makefile.am:25: cd $(srcdir) && rpcgen ./nfs_prot.x
Sounds like you do some 'pretty darn good guessing'...
On my system, 'whereis -b cpp' indicates the location is /usr/bin --- an FHS standard location. Where is that file installed in Arch? Or is the file name changed in Arch? That would be the path to add with the -Y switch.
In the same spot:
22:13 archangel:/dat_e/abs/util-linux> whereis -b cpp cpp: /usr/bin/cpp
Long term we probably need to patch the CMakeLists.txt file:
- Discover the path of cpp * Add the -Y switch
Searching the GIT repository indicates tdebase is the only packages that calls rpcgen.
That looks like the information we need for a bug report. Since the fix looks simple from this standpoint, I'll open the bug and mark it a "Blocker" for R14. Hopefully, this will be the last little 'surprise' of the gcc/glib update season. But, since we are working on making R14 the best stable TDE release to date, I want it to build and run on the current libs -- that way we get a bit of longevity from the initial release and not a flood of bug reports filed right off the bat as each distro moves to glibc 2.16.
Darrell
((You really need to install and run at least one partition of Arch. Talk about the excitement of trying to iterate down to a final finished project the size of TDE when the foundation is constantly changing -- wow! It never gets old...))
Seriously, I think there has rarely been any 3 month stretch before in recent history where so many of the underlying libraries have had significant upstream changes as TDE has tried to dial in a next release -- not to mention one with the polish and improvement that TDE has undergone to get to the point of this R14 release.
Little more time on the front end -- better reviews, less bugs on the backend :)
1082 Opened:
http://bugs.pearsoncomputing.net/bugzilla/show_bug.cgi?id=1082
On my system, 'whereis -b cpp' indicates the location is /usr/bin --- an FHS standard location. Where is that file installed in Arch? Or is the file name changed in Arch? That would be the path to add with the -Y switch.
In the same spot:
22:13 archangel:/dat_e/abs/util-linux> whereis -b cpp cpp: /usr/bin/cpp
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.
((You really need to install and run at least one partition of Arch. Talk about the excitement of trying to iterate down to a final finished project the size of TDE when the foundation is constantly changing -- wow! It never gets old...))
I don't have that kind of energy. :-) Rolling releases tend to sound like a great idea, but these kinds of problems discourage me from going down that road.
Seriously, I think there has rarely been any 3 month stretch before in recent history where so many of the underlying libraries have had significant upstream changes as TDE has tried to dial in a next release -- not to mention one with the polish and improvement that TDE has undergone to get to the point of this R14 release.
Little more time on the front end -- better reviews, less bugs on the backend :)
I suspect people working with other projects have experienced the same issues. A significant difference is they have more people participating, group knowledge levels are higher and deeper, and therefore they can resolve these bumps faster. Possibly, because those other projects have many more people staying in contact with these upstream groups, I suspect these types of changes get forewarned in one manner or another to those other groups but not to us.
These upstream changes greatly reflect the scratch-your-own-itch mentality. The upstream developers might forewarn everybody of upcoming changes, they might not, but they are going to do whatever they want. Not to mention that the developers who participate in these dependent upstream projects like gcc and glibc are mostly paid programmers working for the big shots in the industry, such as RedHat. They aren't going to wait for people in small projects to voice an opinion.
I think the overall problem is free/libre software changes at a relentless and unforgiving pace. Free source code is just too much to resist for most software geeks, so they tweak, and they tweak, and they tweak.... :-)
Darrell
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
On 07/10/2012 11:57 AM, Darrell Anderson wrote:
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.
Yes, the change for arch is from /lib to /usr/lib, though I haven't found the specifics for cpp. My guess at this point is that a sym link isn't being made.
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
I'm checking all ends -- if it isn't a whacky path in tdebase, I'll report back and close the report. I haven't had the couple of hours needed to pick through this line-by-line yet. I'll hopefully get some time tonight. Nothing like having 3 kids between 7 and 13 to make that evaporate though :)
Yes, the change for arch is from /lib to /usr/lib, though I haven't found the specifics for cpp. My guess at this point is that a sym link isn't being made.
I'm checking all ends -- if it isn't a whacky path in tdebase, I'll report back and close the report. I haven't had the couple of hours needed to pick through this line-by-line yet. I'll hopefully get some time tonight. Nothing like having 3 kids between 7 and 13 to make that evaporate though :)
I don't think this a a whacky path in tdebase. tdebase merely uses rpcgen as a build tool. rpcgen gets built when building glibc, and although Arch has moved to 2.16, the code snippets for the cpp executable path have not changed at least since 2.11.1.
If those code snippets in glibc have not changed then updating to 2.16 would not cause breakage. Since cpp is built in the gcc package, from your previous post I'm guessing you'll find the missing sym link breakage in one of these two places:
[2012-07-03 11:15] upgraded gcc (4.7.1-1 -> 4.7.1-3) [2012-07-05 19:59] upgraded gcc (4.7.1-3 -> 4.7.1-4)
One or both of those packages no longer creates the /lib/cpp -> /usr/bin/cpp sym link. I'm guessing the 4.7.1-1 package creates the sym link because you were able to build tdebase and were so happy to find the kate/kwrite issues gone. :-)
Darrell
On 07/09/2012 07:16 PM, Darrell Anderson wrote:
Searching the GIT repository indicates tdebase is the only packages that calls rpcgen.
Darrell
GIT for dummies Q:
Do you use some web based tool to query the tree on the remote server, or do you just do a good 'ole grep of your local copy? (I presume grep of the local, but I didn't know if there was some tool that provided results with links to the past commits for the found sections of code, etc...)
GIT for dummies Q:
Do you use some web based tool to query the tree on the remote server, or do you just do a good 'ole grep of your local copy? (I presume grep of the local, but I didn't know if there was some tool that provided results with links to the past commits for the found sections of code, etc...)
I use grep locally. Nothing fancy. Takes probably a 10 minutes or so to perform a first-time grep on the entire tree. Subsequent searches are a bit faster as long as I don't do anything to disrupt caching.
I keep my local repository reasonably current. Usually no less than weekly I pull everything and rebuild everything, although I pull local modules more often as they affect my builds. When there is a flurry of patching I'll pull everything daily, even more often if necessary.
Darrell
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.
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.
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]
On 14 Jul 2012, David C. Rankin verbalised:
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>
Actually nothing upstream installs /lib/cpp anymore. It's supposed to be a traditional C preprocessor (non-token-based), unused by GCC for many years since -traditional mode was dropped, but kept on for the sake of other programs that used the C preprocessor to preprocess non-C code. It was believed that its last users were imake and the Xresources parser: it looks like we've found another one, in glibc no less.
I'm fairly sure a patch to glibc changing the path to cpp used by rpcgen would be accepted (even though glibc's rpcgen is semi-deprecated), and shall write one shortly. (But of course this won't show up until glibc 2.17.)
On 07/14/2012 10:12 AM, Nix wrote:
On 14 Jul 2012, David C. Rankin verbalised:
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>
Actually nothing upstream installs /lib/cpp anymore. It's supposed to be a traditional C preprocessor (non-token-based), unused by GCC for many years since -traditional mode was dropped, but kept on for the sake of other programs that used the C preprocessor to preprocess non-C code. It was believed that its last users were imake and the Xresources parser: it looks like we've found another one, in glibc no less.
I'm fairly sure a patch to glibc changing the path to cpp used by rpcgen would be accepted (even though glibc's rpcgen is semi-deprecated), and shall write one shortly. (But of course this won't show up until glibc 2.17.)
Allan McRae, one of the primary Arch developers is talking with the upstream folks about the issue. That tells me Arch will get a patch that resolves it within a day or two.
-
Darrell Anderson -
David C. Rankin -
Nix -
Slávek Banko