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 -- David C. Rankin, J.D.,P.E.