Re: "Symbol X has different size in shared object" bug reappears

On non-Linux platforms, we build XEmacs using a runpath that is computed from the link path. For example, we do this while linking: -L/usr/local/lib -L/usr/ccs/lib -Xlinker -R/usr/dt/lib:/usr/openwin/lib -L/usr/dt/lib -L/usr/openwin/lib (Note that there are no shared libs in /usr/local/lib or /usr/ccs/lib...) On Solaris, this is essential, because the default runpath contains only /usr/lib and not /usr/openwin/lib, so we could never build an X-capable XEmacs. I've generally felt that we should be doing this even on platforms like Linux where /etc/ld.so.conf gives us the runtime library search path. However, Steve was strong in his insistence that we don't specify a run-path via -R, and that we let /etc/ld.so.conf win out. I've never understood Steve's opinion on this, and claim that it's led in part to the current Xaw3d disaster. If we do the same thing on Linux, and link like this: -L /usr/X11R6/lib -R /usr/X11R6/lib -L /usr/lib -R /usr/lib (syntax might differ) we would be guaranteed not to get surprised by a rogue Xaw.so which is actually a Xaw3d library, because our link path and our run path would be the same. We can still lose if the system is upgraded or the binary is transported to another system, but that problem exists on every system.