9 Jul
2012
9 Jul
'12
8:11 p.m.
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.