[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Linking problems



Hello.

While compiling stuff I noticed that there are a lot of packages
(at least 72 by my count) which fail because of X related linking
errors. A simple example is the xwatch package. This is the error:

[...]
cc -o xwatch xwatch.o usage.o ui.o parsegag.o xmalloc.o xrealloc.o xstrdup.o alarmhandler.o addfile.o scanfile.o parsecolorstring.o warning.o addline.o error.o
checksetting.o getcolorindex.o parsegeometry.o parseignore.o colorname2rgb.o parsecolors.o colorname2index.o   -lforms -lX11 -lm -L/usr/X11R6/lib
/usr/bin/ld: warning: libXext.so.6, needed by /usr/X11R6/lib/libforms.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libXpm.so.4, needed by /usr/X11R6/lib/libforms.so, not found (try using -rpath or -rpath-link)
/usr/X11R6/lib/libforms.so: undefined reference to `XpmCreatePixmapFromData'
/usr/X11R6/lib/libforms.so: undefined reference to `XpmFreeAttributes'
/usr/X11R6/lib/libforms.so: undefined reference to `XpmAttributesSize'
/usr/X11R6/lib/libforms.so: undefined reference to `XpmReadFileToPixmap'
/usr/X11R6/lib/libforms.so: undefined reference to `XpmLibraryVersion'
collect2: ld returned 1 exit status
make[2]: *** [xwatch] Error 1
make[2]: Leaving directory `/build/build/xwatch-2.11/src'
make[1]: *** [final] Error 2
make[1]: Leaving directory `/build/build/xwatch-2.11/src'
make: *** [build] Error 2

There was a similar problem in the kfreebsd-i386 architecture and it
was solved by modifying binutils to honor /etc/ld.so.conf.

However, I've always heard (if I remember well) that /etc/ld.so.conf
was a "Linuxism", and that it was not the "right thing" to do for GNU.

So: What's the "right thing" to do here, then?


Note: Another thing that worked, other than modifying binutils, was to
use the following wrapper, inspired by the (now obsolete) gcc-i386-gnu
cross compiler created by make-cross:

#!/bin/sh
rpath_link="-Wl,-rpath-link=/usr/X11R6/lib"
for arg; do
  case "$arg" in
  -c | -S | -E | -M | -MM )
    # No linking to do, so avoid gratuitous warnings.
    rpath_link=
    ;;
  esac
done
exec /usr/bin/`basename $0` ${1+"$@"} $rpath_link

If I put this in /usr/local/bin and symlink gcc, cc, i386-gnu-gcc, etc.
to it, the linking problems disappear as well.

This is of course a hack, but so was the modified dpkg-shlibdeps we
have been using for years because of the /usr -> / symlink, so if I
have to use it to build stuff, I'll use it.



Reply to: