error due building " canonicalization unexpectedly shrank by one character"

[Eugene Budanov]

When I try to build libselinux I getting error message "/usr/lib/rpm/bin/debugedit: canonicalization unexpectedly shrank by one character"

Some output info:

extracting debug info from /root/rpmbuild/BUILDROOT/libselinux-2.1.9-3-mdv2012.0.x86_64-buildroot/lib64/libselinux.so.1
extracting debug info from /root/rpmbuild/BUILDROOT/libselinux-2.1.9-3-mdv2012.0.x86_64-buildroot/sbin/matchpathcon
extracting debug info from /root/rpmbuild/BUILDROOT/libselinux-2.1.9-3-mdv2012.0.x86_64-buildroot/usr/lib64/python2.7/site-packages/selinux/_selinux.so
extracting debug info from /root/rpmbuild/BUILDROOT/libselinux-2.1.9-3-mdv2012.0.x86_64-buildroot/usr/lib64/python2.7/site-packages/selinux/audit2why.so
extracting debug info from /root/rpmbuild/BUILDROOT/libselinux-2.1.9-3-mdv2012.0.x86_64-buildroot/usr/lib64/ruby/site_ruby/1.8/x86_64-linux/selinux.so
/usr/lib/rpm/bin/debugedit: canonicalization unexpectedly shrank by one character

As I understood this error was fixed by Christophe Fergeau in RPM 4.6

How can I fix it with RPM 5.4.4 from Cooker? Or workaround exists?

[Jeff Johnson (n3npq)]

The root cause of the error is usually a doubled / character like
    /some/path//to/src/*.c
that ends up in ELF debugging information.

Even if Chrsitophe Fergeau "fixed" in rpm-4.6, debugedit.c has
changed since. I track the debug edit.c sources as closely as
possible: I have no interest whatsoever in deviating from
what ELF developers are doing.

Meanwhile the whole debugedit.c implementation has been called
        ... my greatest hack ever ...
by the person (Alex Larrson) who coded debugedit.c originally.

See his speaker's bio in FOSDEM/2005.

I would tend to (politely agree) "hack". There are several outstanding
known problems.

The blueprint is here:
    https://blueprints.launchpad.net/rpm/+spec/rpm-debugedit-uplift
where this bug is now attached to several others.

AFAIK, upgrading debugedit.c (and attempting to "fix" this stupidness) is
deemed "low priority" by ROSA (and Denis Silakov). I forget why I think
that: iirc it was a comment against some bug by Denis.

[Denis Silakov (dsilakov)]

Yes, that was stated for lower level blueprint, https://blueprints.launchpad.net/rpm/+spec/rpm-debuginfo-features (and I still think that such features as splitting debuginfo on per-binary rpm level is not only low priority, but questionable).

But I haven't caught you idea for this particular bug, does it make sense to take a look at debugedit.c changes mentioned by Eugene and probably pick up some 'hacks' from there?

[Jeff Johnson (n3npq)]

I don't believe Christophe Fergeau really fixed: I've watched/explained
this problem for years (and I believe I remember the bug report where
the claim of "fix" was made).

The near term fix is to get debugedit.c out of rpm somehow. The code
ended up in RPM because RPM was one of the first applications to
use elfutils, the code was actually embedded in RPM sources before
being packaged (which I also was responsible for).

So debugedit.c chased elfutils and the code sits and rots: producing
-debuginfo is "rpm therapy" intensive, several e-mail exchanges this month
and that is typical.

The longer term answer uses a distributed store for debugging symbols
indexed by buildid and path and ripping Berkeley DB out of gdb and
other tools that are linking rpm libraries for no sane reasons, creating
application contention (like with abrt) for an rpmdb for no sound
engineering reason. The world is full of "Berkeley DB haters" and
the engineering choices are creating locking contention and
deadlock watchdog's to keep applications running when colliding
on accessing an rpmdb. Ditto SElinux and systemtap.

Diffing @rpm.org code against @rpm5.org hurts little. Note that
the main difference is whether NSS or BeeCrypt is used for digests:
which creepy-toe library is used is only a part of a much larger puzzle.

[Jeff Johnson (n3npq)]

This seems to be the discussion thread re Chrosyophe Fergeau's patch and fix:

    http://mandriva.598463.n5.nabble.com/Cooker-gcc-4-5-td2640835.html

Note the very last comment in the thread:

    Well, there are more problematic cases (most notably builddir being shorter
    than debugdir) that are not handled and would be very difficult to fix.

To try to illustrate what that means in plain english, here are the "traditional"
paths in RPM:

    builddir = /usr/src/redhat
    debugdir = /usr/src/debug

So -debuginfo is possible only because
     sizeof ("redhat") >= sizeof("debug")

i.e. paths are being rewritten in a fixed size ELF section. The final paths must
be less than or equal to the initial paths (or producing -debuginfo isn't possible).

This was the state since forever: might be fixed in latest debugedit.c *shrug*.

[Jeff Johnson (n3npq)]

If you *do* want to include the patch, then I need some explicit
testing, or a fairly long acceptance test.

Once debugedit.c starts being patched, then "rpm therapy" is expected.

I'd rather the patch -- if it truly fixes something -- be posted to
<email address hidden> first. I'm pretty sure that was done at the time,
but I don't recall whether the patch has been added or not.

There are other changes in need of doing: Tom Tromey has
rewritten the gdb caching (where debug edit moved symbols
end up) to me RO and mappable for performance. There is
also a lot of effort put into buildid's, an identifier that is
supposedly unchanged with a rebuild on "sufficiently similar"
build system.

[Per Øyvind Karlsen (proyvind)]

Notice that I deliberately dropped Christophe/Anssi's patch from rpm in Mandriva simply because it didn't *actually* fix anything but rather hid packaging bug that prevented the debug symbols to actually be of any use (although the package did obviously build of course..), so as the actual cause of this should be fairly simply to fix and also be crucial to actually make the resulting debug packages of any use, I chose to drop it..
Arguably the error could be better and more sensible, but just not me to blame.. :p

[Denis Silakov (dsilakov)]

Well, it really looks like a hack, I've expected something smarter. I would agree with Per Øyvind and not include that patch.

Error message could be more sensible, but nothing prevents us from adding one more hint to Mandriva's wiki (which already describes quite a few packaging errors, but not this one).