Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!mintaka!bloom-beacon!dont-send-mail-to-path-lines
From: mouse@lightning.mcrcim.mcgill.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: Re:  Sun shared libs - openwin vs MIT R4
Message-ID: <9105110653.AA15920@lightning.McRCIM.McGill.EDU>
Date: 11 May 91 06:53:47 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 60

>> Did you try -Bstatic? :-)
> Best suggestion, if the user has the source to his program.

The original post explicitly mentioned that the poster was playing with
all sorts of cc options to get its program to link.

> Gets around the shared library problems all together.

But introduces another: the libraries are made into shared objects for
a reason, and having to use -Bstatic defeats the whole point of that.

> (Note: only the X11R4 libraries would need to be statically link.
> The standard libraries can still be dynamically linked.  [...])

Your bias is showing.  Some of us (like me) think of the MIT stuff as
the standard and OW as the bastardization.

>> A couple of suggestions:

>> 1) Replace all the OW programs with shell script wrappers that bash
>>    $LD_LIBRARY_PATH and then exec the real binary.
> Actually this could be done the other way around.

Well yes.  But (a) my bias shows too - I think of OW as the alien stuff
intruding into the "real" X environment and (b) the original post left
me with the impression that the poster felt the same way, in which case
it is more appropriate to wrap the OW binaries.

>> 2) Use your favorite binary editor to bash the LD_LIBRARY_PATH
>>    string in the OW binaries to OW_LIBRARY_PATH or some such.
> Won't work.  LD_LIBRARY_PATH is only used in /usr/lib/ld.so.

This was pointed out to me in mail as well.  Yes; I was engaging my
fingers before putting brain in gear.  The necessary fix is to edit
/usr/lib/ld.so in the OW binaries to (say) /owinlib/ld.so, then copy
/usr/lib/ld.so there and edit LD_LIBRARY_PATH in the copy.

> ENVIRONMENT
>      LD_LIBRARY_PATH
>           [...] NOTE: when running a set-user- or set-group-ID
>           program, ld.so will only search for libraries in
>           directories it "trusts", which are /usr/lib, /usr/5lib,
>           /usr/local/lib, and any directories specified within the
>           executable as a result of -L options given when the
>           executable was constructed.

Hmmm, there's a possible solution: make all the troublesome executables
setuid or setgid, so they'll ignore LD_LIBRARY_PATH.  (Of course, the
immediate problem is to decide what UID or GID to make them set-ID to.
It's hardly a general solution, but might be useful to some sites.)

Much better would be to provide a way for users to rebuild ld.so (eg,
to change the environment variable used) and a way to configure ld to
use an alternate ld.so...I *wish* someone would sell a civilized
machine! mutter grumble gripe complain....

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu