Bug 202256 - prelink unhappy with "... undefined non-weak symbols"
Summary: prelink unhappy with "... undefined non-weak symbols"
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: prelink
Version: rawhide
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-08-11 19:58 UTC by Michal Jaegermann
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-08-11 20:17:06 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Michal Jaegermann 2006-08-11 19:58:13 UTC
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
installation:

/lib64/libthread_db-1.0.so
/usr/lib64/dia/libdia.so
/usr/lib64/libdmraid.so.1.0.0.rc11
/usr/lib64/libedataserverui-1.2.so.8
/usr/lib64/libfftw3f_threads.so.3.1.1
/usr/lib64/libfftw3l_threads.so.3.1.1
/usr/lib64/libfftw3_threads.so.3.1.1
/usr/lib64/libgcj-tools.so.7rh.0.0
/usr/lib64/libgdk_imlib.so.1.9.13
/usr/lib64/libgnomedb-3.so.4.0.0
/usr/lib64/libgnomedb_graph-3.so.4.0.0
/usr/lib64/libgnomedb_handlers-3.so.4.0.0
/usr/lib64/libgnomedb_parser-3.so.4.0.0
/usr/lib64/libgnome.so.32.4.3
/usr/lib64/libgnomeui.so.32.14.1
/usr/lib64/libgnorbagtk.so.0.0.0
/usr/lib64/libgnorba.so.27.1.8
/usr/lib64/lib-gnu-classpath-tools-gjdoc.so.0.0.0
/usr/lib64/libgpilotdcm.so.2.0.2
/usr/lib64/libgpilotdconduit.so.2.0.3
/usr/lib64/libgpilotd.so.2.1.1
/usr/lib64/libIIOP.so.0.5.17
/usr/lib64/liblftp-jobs.so.0.0.0
/usr/lib64/libmathview_backend_svg.so.0.7.6
/usr/lib64/libogrove.so.0.0.1
/usr/lib64/libopcodes-2.17.50.0.3-2.so
/usr/lib64/libORBitCosNaming.so.0.5.17
/usr/lib64/libORBit.so.0.5.17
/usr/lib64/libospgrove.so.0.0.1
/usr/lib64/libostyle.so.0.0.1
/usr/lib64/libots-1.so.0.4.2
/usr/lib64/libpisock++.so.0.0.0
/usr/lib64/libpisync.so.0.0.1
/usr/lib64/libpoppler.so.1.0.0
/usr/lib64/libreadline.so.5.1
/usr/lib64/xorg/modules/libscanpci.so

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):
prelink-0.3.9-2

Comment 1 Jakub Jelinek 2006-08-11 20:17:06 UTC
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 20:46:32 UTC
> 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 20:59:59 UTC
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.