Bug 202256 - prelink unhappy with "... undefined non-weak symbols"
prelink unhappy with "... undefined non-weak symbols"
Product: Fedora
Classification: Fedora
Component: prelink (Show other bugs)
All Linux
medium Severity low
: ---
: ---
Assigned To: Jakub Jelinek
Depends On:
  Show dependency treegraph
Reported: 2006-08-11 15:58 EDT by Michal Jaegermann
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-11 16:17:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2006-08-11 15:58:13 EDT
Description of problem:
After a run, from cron, of '/usr/sbin/prelink -av -mR -q' in prelink.log
there is a number of complaints in this style:

/usr/sbin/prelink: Warning: /usr/lib64/libgnomedb_parser-3.so.4.0.0 has
undefined non-weak symbols

It appears that this happens only with libraries and here a list
of those where such warnings do happen collected from on my current test


Is this is an issue with prelink, or really with those libraries,
or not a problem at all?  If the last one then why "Warning"?

It does not appear that operations of programs using libraries
above are affected in any way.

Version-Release number of selected component (if applicable):
Comment 1 Jakub Jelinek 2006-08-11 16:17:06 EDT
It is usually a bug in those libraries, but not a show stopper, that's why
prelink issues a warning about it, not an error.
The libraries work, but less efficiently than they could if they were linked
properly. See prelink.pdf for details.
Comment 2 Michal Jaegermann 2006-08-11 16:46:32 EDT
> It is usually a bug in those libraries ...
Does that mean that bugzilla reports should be filed for
every package supplying libraries above?
Comment 3 Jakub Jelinek 2006-08-11 16:59:59 EDT
Filling such bugs just because you see it in the prelink output is not very
productive thing to do.
But if you took time to see what symbols are unresolved (e.g. by running
ldd -d -r /the/library.so.M.N.O
) and if that is intentional or not (and in the latter case if and how can
it be easily fixed), then such bugreports surely are desirable.
E.g. one case where this is intentional is libreadline.so.5 - the symbols
it needs are provided by both libncurses.so and libtermcap.so and libreadline
wants to support both libncurses and libtermcap linked programs.
Another valid case are some plugins which are expected to resolve to symbols
defined in the binary or something similar.  But in most other cases this is
just a missing -lsomething on the command line.

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