Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!ericom!eua.ericsson.se!erix.ericsson.se!per
From: per@erix.ericsson.se (Per Hedeland)
Newsgroups: comp.windows.x
Subject: Re: Suns 4.1 problems with X
Message-ID: <1991Jan8.083229.12235@eua.ericsson.se>
Date: 8 Jan 91 08:32:29 GMT
References: <1991Jan7.084414.2611@eua.ericsson.se> <9101071326.AA00430@expire.lcs.mit.edu>
Sender: news@eua.ericsson.se
Reply-To: per@erix.ericsson.se (Per Hedeland)
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden
Lines: 57

|>     The possibility of linking against old installed libraries is exactly
|>     the same as with the current -L specifications.
|> 
|> I don't think so, since I believe the -L we specify in the command line gets
|> searched before the default place, not after.

As is the case with LD_LIBRARY_PATH - excerpting from SunOS 4.1 ld(1),
"Object File Processing":

     ld searches for the desired object file through  a  list  of
     directories  specified  by -L options, the environment vari-
     able LD_LIBRARY_PATH, and  finally,  the  built-in  list  of
     standard    library   directories:   /lib,   /usr/lib,   and
     /usr/local/lib.

|>     there is as far as I can tell no support for
|>     installation in non-standard directories in the current build procedure,
|> 
|> A bug which should be fixed, as so many have rightfully flamed.
|> 
|>     and addition of this feature (if it was possible) should be independant
|>     of the fixing of the security problem.
|> 
|> How, pray tell?

Please note the "if it was possible" - I just wanted to point out that
they are two separate problems, and that a fix for the security problem
shouldn't necessarily be required to *also* solve the non-standard-install
problem. If it is impossible to solve both (and I certainly don't see a
way to do it "atomically"; see below though), I for one would definitely
prefer to see a fix for the security problem.

|> [ Andreas Stolcke writes: ]
|>     Why not simply relink the binary with the installed libs in the install
|>     target of the makefile  (using absolute paths, of course) ?
|> 
|> Yes, we've thought of that.  But not everyone uses "make install" to
|> install things, so it still leaves open a possibility of error.

But if the build is done with LD_LIBRARY_PATH (and no -L), and relink
(with -L specifying the installation directories) is done in the install
target, the only possible error that I can see is that those who want
to install in non-standard places, but skip the "make install", won't
get (correctly) working installed binaries.

I.e. the security hole is closed without any drawbacks compared to the
current build procedure, and installation in non-standard places is
supported much better than currently, the only requirement being that
those who want it do the "make install", or other commands to the same
effect ("current" here of course refers to the build procedure of R4
after patch 18 - I don't have information about unreleased fixes for
either problem, if such exist). Sounds reasonable to me...

--Per Hedeland
per@erix.ericsson.se  or
per%erix.ericsson.se@uunet.uu.net  or
...uunet!erix.ericsson.se!per