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.