I feel I can diagnose and solve most linking issues using nm and ldd, but
the PLplot linking problem I demostrate below for a Linux (Debian sarge)
platform really has some strange and inconsistent symptoms so I hope
somebody here can help me figure this out.
This linking issue occurs on my platform (Debian sarge, but with a modern
pango stack, where the pango stack is the fairly large number of libraries
which libpango depends upon). The error below concerns linking of libXFT to
libfreetype so here are all the details of those libraries in the
pango stack.
[EMAIL PROTECTED]> \ls -l *Xft* *freetype*
-rwxr-xr-x 1 software software 1035 May 5 14:54 libXft.la
lrwxrwxrwx 1 software software 15 May 5 14:54 libXft.so ->
libXft.so.2.1.2
lrwxrwxrwx 1 software software 15 May 5 14:54 libXft.so.2 ->
libXft.so.2.1.2
-rwxr-xr-x 1 software software 1112007 May 5 14:54 libXft.so.2.1.2
-rwxr-xr-x 1 software software 837 May 5 14:15 libfreetype.la
lrwxrwxrwx 1 software software 21 May 5 14:15 libfreetype.so ->
libfreetype.so.6.3.15
lrwxrwxrwx 1 software software 21 May 5 14:15 libfreetype.so.6 ->
libfreetype.so.6.3.15
-rwxr-xr-x 1 software software 1688054 May 5 14:15 libfreetype.so.6.3.15
Note the permissions and symbolic links are fine.
These libraries are installed at /home/software/pango_stack/install/lib, and
I have set LD_LIBRARY_PATH to that location (actually it is
/usr/local/wxwidgets/lib:/home/software/libharu/install/lib:/home/software/pango_stack/install/lib
but I have checked that none of the other locations have versions of the
above libraries, that is
[EMAIL PROTECTED]> ls /usr/local/wxwidgets/lib/lib*.so
/usr/local/wxwidgets/lib/libwx_base-2.6.so@
/usr/local/wxwidgets/lib/libwx_base_net-2.6.so@
/usr/local/wxwidgets/lib/libwx_base_xml-2.6.so@
/usr/local/wxwidgets/lib/libwx_gtk2_adv-2.6.so@
/usr/local/wxwidgets/lib/libwx_gtk2_core-2.6.so@
/usr/local/wxwidgets/lib/libwx_gtk2_html-2.6.so@
/usr/local/wxwidgets/lib/libwx_gtk2_media-2.6.so@
/usr/local/wxwidgets/lib/libwx_gtk2_qa-2.6.so@
/usr/local/wxwidgets/lib/libwx_gtk2_xrc-2.6.so@
[EMAIL PROTECTED]> ls /home/software/libharu/install/lib/*.so
/home/software/libharu/install/lib/libhpdf.so@
libLASi (which depends on the pango stack) builds and installs without
issues. -dev psttf (which depends indirectly on the pango stack via
libLASi) and all the cairo devices (which depend directly on the pango
stack) build, install, and run without issues.
However, when I run "make" in the installed examples/c tree I get the
following linking error:
/usr/bin/gcc plplotcanvas_demo.c -o plplotcanvas_demo -Wl,-rpath
-Wl,/home/software/plplot_cvs/installcmake/lib:/home/software/autotools/install/lib
\
`PKG_CONFIG_PATH=/home/software/plplot_cvs/installcmake/lib/pkgconfig
pkg-config --cflags --libs plplotd-gnome2`
/home/software/pango_stack/install/lib/libXft.so.2: undefined reference to
`FT_GlyphSlot_Embolden'
collect2: ld returned 1 exit status
make: *** [plplotcanvas_demo] Error 1
The result of the -libs part of the above pkg-config command is
[EMAIL PROTECTED]> \
PKG_CONFIG_PATH=/home/software/plplot_cvs/installcmake/lib/pkgconfig \
pkg-config --libs plplotd-gnome2
-L/home/software/plplot_cvs/installcmake/lib
-L/home/software/autotools/install/lib -lplplotgnome2d -lplplotd -lltdl -ldl
-lm -lcsirocsa -lcsironn -lqhull -lfreetype
Note especially the -lfreetype option.
Furthermore,
[EMAIL PROTECTED]> nm -a \
/home/software/pango_stack/install/lib/libXft.so | \
grep FT_GlyphSlot_Embolden
U FT_GlyphSlot_Embolden
and
[EMAIL PROTECTED]> nm -a \
/home/software/pango_stack/install/lib/libfreetype.so | \
grep FT_GlyphSlot_Embolden
00014d70 T FT_GlyphSlot_Embolden
which means that the symbol FT_GlyphSlot_Embolden is undefined in libXft but
resolved by libfreetype. This is confirmed by the following test:
[EMAIL PROTECTED]> ldd -r /home/software/pango_stack/install/lib/libXft.so
libfontconfig.so.1 =>
/home/software/pango_stack/install/lib/libfontconfig.so.1 (0xb7fc1000)
libfreetype.so.6 =>
/home/software/pango_stack/install/lib/libfreetype.so.6 (0xb7f51000)
libz.so.1 => /usr/lib/libz.so.1 (0xb7f2b000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb7f23000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xb7e5c000)
libc.so.6 => /lib/tls/libc.so.6 (0xb7d27000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb7d07000)
libdl.so.2 => /lib/tls/libdl.so.2 (0xb7d03000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
So why am I getting the above error at link time for plplotcanvas_demo?
Further investigation shows an unexpected result. If I go ahead and link
plplotcanvas_demo with the additional option -Wl,--warn-unresolved-symbols
(which turns unresolved symbols into warnings rather than fatal errors), the
resulting plplotcanvas_demo passes the "ldd -r" test, i.e., the libXft and
libfreetype libraries are found at /home/software/pango_stack/install/lib/
and there are no unresolved references! Furthermore, plplotcanvas_demo runs
without problems.
So basically the linker says one thing (contrary to the nm -a evidence) and
ldd (which I believe invokes the run-time loader) says another about
unresolved references.
Does anybody have a clue about any way (other than a linker bug) that
such an inconsistency might be possible?
If you agree this is a really strange linking result that might be due to a
bug in my Debian sarge linker, I would appreciate some attempts at
confirmation on other platforms by building and installing the latest PLplot
from svn (on a fully loaded development platform that includes what is
needed to build the gnome canvas interface) and running make in the
installed examples/c directory.
In fact, I am going to try the same test on my Ubuntu Dapper platform (where
I have a pango stack built from exactly the same source as on my Debian
sarge platform), but it is going to take a while (it is a 600MHz box) so I
will report later.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
