Hello,

thank you both for your replies!

On Wed, Sep 10, 2008 at 02:26:45PM -0400, Jeff Johnson wrote:
> <segfault debtails snippped)
> 
> >The respective xmalloc calls seem to be fine and have apparently not
> >changed compared to 4.4.7. Has anyone got an idea why the segmentation
> >fault is occurring?
> >
> 
> Originally, the misc/glob.[ch] was added as a replacement function for
> platforms that do not support the GNU glob extensions. The routines
> have moved into rpmio directly after a bug report from PLD.
> 
> The "replacement" assumes that all portability issues are detected  
> through AutoFu and handled correctly in the code. Furthermore
> "replacement" assumes interoperation with the system glob(3) which is
> trickier than  it looks.
> 
> Instead, with glob(3) internal (and unexported) in librpmio,  
> equivalently functional, a weaker constraint that is likely easier to
> maintain portably, instead of "replacement" is all that rpm itself
> needs.
> 
> So try building the rpm-5_1 branch from cvs and see whether that helps  
> your segfaults. If not, something else can be attempted.

Thanks for the pointer! rpm-5.1.SNAPSHOT.20080909 works and does not
cause a segfault in misc/glob.c.
RPM does however mess up %{arch}, so that e.g. package names are e.g.:
  $ rpm -q rpm
  rpm-5.1.4-1.005e3e6c4c00
instead of:
  $ rpm -q gdb
  gdb-6.6-1.ppc
with a package build with rpm-4.4.9. lib/rpmrc.c seems to pull the
string "005e3e6c4c00" from utsname.machine via uname(). On AIX this
is more of a machine/node-ID rather than the platform. I recall a
mail on rpm5-devel about ripping out some heuristics to determine
the platform/arch.

Thanks & Regards,

        Frank