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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]