After experiencing the joys[1] of Solaris 2, and what works and what doesn't work when -R or -rpath-link is fed to the linker, I wish to apologize for any harsh words I might have written with regards to to Sun-heads proposing doing the same thing on Linux. It is absolutely the *wrong* thing to do on Linux[2], but I now fully understand why it is needed on Solaris. I *love* Solaris 2.4: $ echo $PATH /usr/verylocal/bin:/usr/local/bin:/usr/local/abin:/usr/local/sbin:/usr/local/libexec:/usr/local/share/bin:/usr/bin:/bin:/usr/ucb:/usr/games:/etc:/usr/lib/uucp:/usr/sbin:/sbin:/usr/ccs/bin:/usr/openwin/bin:/localwork/java/bin:. $ which xmkmf /usr/openwin/bin/xmkmf $ xmkmf mv Makefile Makefile.bak imake -I/usr/openwin/lib/config "/usr/openwin/lib/config/sun.cf", line 46: Can't find include file sunLib.rules "/usr/openwin/lib/config/Project.tmpl", line 762: Can't find include file noop.rules imake: Exit code 2. Stop. I still believe the /usr/dt shit getting pasted to the front of search paths regardless of what is being requested to be linked in at configure time is a serious mistake. Footnotes: [1] "joys" is a registered trademark of somebody. [2] $ which emacs-19.34 /usr/local/bin/emacs-19.34 $ readelf $(which emacs-19.34) Shared library: [libXaw.so.6] Shared library: [libXmu.so.6] Shared library: [libXt.so.6] Shared library: [libSM.so.6] Shared library: [libICE.so.6] Shared library: [libXext.so.6] Shared library: [libX11.so.6] Shared library: [libncurses.so.3.0] Shared library: [libm.so.5] Shared library: [libc.so.5] Library rpath: [/usr/X11R6/lib] $ emacs-19.34 zsh: 18086 segmentation fault (core dumped) emacs-19.34 On Linux, location of libraries can change everytime the C library is updated. My XEmacs 19.14 binary built at the same works correctly because `-R' AKA `-rpath-link' wasn't set.