Bug 330811 - Prelinking dmraid prints a warning
Summary: Prelinking dmraid prints a warning
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: dmraid
Version: 10
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Heinz Mauelshagen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: bzcl34nup
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-10-13 17:20 UTC by Daniel Qarras
Modified: 2008-12-12 23:04 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-12-10 18:20:32 UTC
Type: ---


Attachments (Terms of Use)

Description Daniel Qarras 2007-10-13 17:20:41 UTC
When prelinking dmraid the following warning is printed:

Prelinking /usr/lib/libdmraid.so.1.0.0.rc14
prelink: Warning: /usr/lib/libdmraid.so.1.0.0.rc14 has undefined non-weak symbols

Comment 1 Heinz Mauelshagen 2007-10-18 13:41:15 UTC
Not able to reproduce this here.
Which symbols are those ?
Does this cause any negative impact other than the warning ?

Comment 2 Daniel Qarras 2007-10-18 14:28:13 UTC
Steps to reproduce:

1. prelink -au
2. prelink -avmR
3. Notice the warning:

Prelinking /usr/lib/libdmraid.so.1.0.0.rc14
prelink: Warning: /usr/lib/libdmraid.so.1.0.0.rc14 has undefined non-weak symbols

This with today's rawhide.

No negative impacts per se, but see Jakub's comment in Bug 330821:

This is not an error, just a warning.  There are legitimate cases where having
undefined symbols in
ldd -d -r .../lib*so*
is ok and one of them is if the library is not generally dlopenable, but relies
on the binary to satisfy those symbols.

On the other side, if the symbols are provided by some shared library, usually
it is just an on unintentional omission on the packager's part, which is bad
for multiple reasons:
1) if the symbols are versioned in the library where they are defined, the
   library with undefined non-weak symbols might use wrong versions of those 
   symbols
2) in prelink it causes unnecessary prelink conflicts which need to be resolved
   at runtime
3) if you e.g. dlopen that library and don't know you need the other library
   as well, the dlopen will likely fail

Comment 3 Bug Zapper 2008-04-04 14:05:09 UTC
Based on the date this bug was created, it appears to have been reported
during the development of Fedora 8. In order to refocus our efforts as
a project we are changing the version of this bug to '8'.

If this bug still exists in rawhide, please change the version back to
rawhide.
(If you're unable to change the bug's version, add a comment to the bug
and someone will change it for you.)

Thanks for your help and we apologize for the interruption.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 4 Bug Zapper 2008-05-14 03:22:56 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 5 Bug Zapper 2008-11-26 02:00:48 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 6 Heinz Mauelshagen 2008-12-10 18:20:32 UTC
I tried to reproduce the flaw on Fedora 10 and couldn't.
prelink run unveiled 18 DSOs (mileage can vary depending on package configuration) with "undefined non-weak symbols", not including libdmraid.

Closing in lack of evidence.

Comment 7 Daniel Qarras 2008-12-12 23:04:05 UTC
Thanks, I now tested F10 and can verify that this has been fixed.


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