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.

On Mon, Jan 17, 2000 at 13:02:42 +0900, Stephen J. Turnbull wrote: Hmmpf, the same problem here with a RedHat 6.1 - okay, somewhat homebrewed, but still a RedHat. Only with selfcompiled neXTaw-libs. Stefanie -- "Windows: The first user interface where you click Start to turn it off."

mb> I've generally felt that we should be doing this even on mb> platforms like Linux where /etc/ld.so.conf gives us the mb> runtime library search path. However, Steve was strong in his mb> insistence that we don't specify a run-path via -R, and that mb> we let /etc/ld.so.conf win out. mb> I've never understood Steve's opinion on this, and claim that mb> it's led in part to the current Xaw3d disaster. SJT> I don't see the current Xaw3d situation as a disaster [for XEmacs] SJT> with Daniel's patches. There is a serious problem for people who roll SJT> their own under Debian, it's also easy to detect under Debian. If you SJT> want, you can just puke "buggy Debian system, XEmacs.org washes its SJT> hands, write bugs(a)debian.org for more help"[1] and refuse to build. Well, you're right that having two incompatible libraries with the same major number is a violation of the OS'es contract with the user. SJT> The problem with using a runpath under Linux is that there's no reason SJT> to believe that the build system and the run system have similar SJT> ld.so.confs. Since ld.so.conf is the normal way to handle these SJT> things on Linux, it will take real sophistication on the part of SJT> users, even developers, to figure out what goes wrong if we silently SJT> hardcode rpath and something does go wrong. Again, I don't actually see what can go wrong if we hardcode rpath, since ld.so.conf is a fallback. We should never use an incompatible library, if library versioning is done correctly. The way I see ld.so.conf is as a replacement for the hardcoded /usr/lib:/lib system library path fallback that other OSes tend to have. Now that path is much more under system administrator control. If you look at it that way, it makes much more sense to put the rpath into the executable. Hrvoje> Jan Vroonhof <vroonhof(a)math.ethz.ch&gt; writes: Hrvoje> Is this a problem? If XEmacs worked right in the first Hrvoje> place, I don't see why I'd want to play games with Hrvoje> LD_LIBRARY_PATH. SJT> XEmacs, yes. But suppose you're not sure _X11_ works right? SJT> One guy in XFree86 I know tests his next-generation X libraries in SJT> exactly that way. I used to do that back when the Japanese patches to SJT> Debian X packages tended to really suck (especially, they didn't get SJT> pre- and postrm scripts right); getting the old behavior was just a SJT> matter of pointing LD_LIBRARY_PATH to where I'd copied my working SJT> libs. SJT> All this is theory; I don't really care any more myself and my XF86 SJT> buddy is a vi guy anyway. But who knows what bugs are going to appear SJT> next? I would like to see an option in ./configure, default it to SJT> hardcode the rpath is ok with me, announce the value in Installation. Yes, we should provide a way to not have a baked-in rpath. The obvious way is configure --site-runtime-libraries='' Anyways, there's no easy fix.