Description of problem:

After assorted packages got updated the first run of 'prelink' with
'--quick' flag bombs as follows:

(gdb) r
Starting program: /usr/sbin/prelink -av -Rm -q
warning: shared library handler failed to enable breakpoint

Program received signal SIGSEGV, Segmentation fault.
deps_cmp (A=0x7fff9010b968, B=0x7fff9010c848) at cache.c:344
344       if (a->type == ET_NONE && b->type != ET_NONE)
(gdb) bt
#0  deps_cmp (A=0x7fff9010b968, B=0x7fff9010c848) at cache.c:344
#1  0x000000000043d58b in msort_with_tmp ()
#2  0x000000000043d4eb in msort_with_tmp ()
#3  0x000000000043d4d5 in msort_with_tmp ()
#4  0x000000000043d702 in qsort ()
#5  0x0000000000400fbd in prelink_load_cache () at cache.c:465
#6  0x000000000040e0c0 in main (argc=4, argv=0x7fff90110978) at main.c:390
#7  0x0000000000436cb0 in __libc_start_main ()
#8  0x00000000004001b9 in _start ()
(gdb) p a
$1 = (struct prelink_entry *) 0x0
(gdb) p b
$2 = (struct prelink_entry *) 0x0

Precisely that combination of circumstances and flags is pretty likely
when /etc/cron.daily/prelink is firing up.

Once prelink was run without '--quick' then caches are redone and 
a case with two "prelink_entry" pointers beeing NULL does not happen
(or at least is much harder to hit).

Adding, as the first check in deps_cmp() in cache.c:

       if (a == NULL && b == NULL)
         return 0;

should solve the matter.  We do not really care much about such entries
in any case.

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

How reproducible:
always, or at least with a pretty good chance of "success", in
circumstances described above.

Additional info:
This bug was originally described in comments to bug #196941
on a mistaken assumption that this is another manifestation
of a bug reported there.

Skipping -q flag in /etc/cron.daily/prelink should serve as
a workaround until updates are available.