Bug 118422 - RPM assertion failed when building xalan-j
Summary: RPM assertion failed when building xalan-j
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: rpm   
(Show other bugs)
Version: 3.0
Hardware: ia64
OS: Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-03-16 17:04 UTC by Jeremy Handcock
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-03-20 20:25:27 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Jeremy Handcock 2004-03-16 17:04:28 UTC
Description of problem:  I can't seem to build xalan-j.  I observed
this behavior on ia64, but it may be present on other architectures.

Version-Release number of selected component (if applicable):

How reproducible: Always

Steps to Reproduce:
1. Build xalan-j
Actual results:
Processing files: xalan-j-devel-2.4.1-11
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Requires: xalan-j = 2.4.1-11
Obsoletes: xalan-devel
Processing files: xalan-j-debuginfo-2.4.1-11
rpmbuild: rpmfc.c:957: rpmfcELF: Assertion `s != ((void *)0)' failed.

Additional info: I don't know if this is related or not, but rpmbuild
of eclipse also fails on x86_64 when stripping the binaries - it just
hangs for a bit and exits without any explanation.

Comment 1 Jeff Johnson 2004-03-20 16:24:09 UTC
The assertion is covering a "can't happen" condition of a NULL
return from an elfutils routine while trying to process
DT_SONAME for generating a Provides: soname_here

         s = elf_strptr(elf, shdr->sh_link, dyn->d_un.d_val);
assert(s != NULL);

Does xalan-j have a DSO w/o an soname? Add if not.

Otherwise this is some deep compiler voodoo on ia64.

Comment 2 Jeremy Handcock 2004-03-20 20:25:27 UTC
I reinstalled my ia64 box with one of the RHEL3 U2-Beta respins and
this went away.  <shrug>

Note You need to log in before you can comment on or make changes to this bug.