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.