[525] in Release_7.7_team

home help back first fref pref prev next nref lref last post

Conclusions about X links in /usr/lib

daemon@ATHENA.MIT.EDU (Greg Hudson)
Tue May 7 13:04:33 1996

Date: Tue, 7 May 1996 13:04:10 -0400
From: Greg Hudson <ghudson@MIT.EDU>
To: release-team@MIT.EDU, sol24@MIT.EDU

Upon investigation, I discovered that:

	* The Solaris dynamic linker is less intelligent than I
	  suspected.  If it can't find anything in the directories
	  specified by LD_LIBRARY_PATH or the binary's run-time path
	  (as specified by a -R option to the linker), it checks
	  /usr/ccs/lib and /usr/lib and then gives up.

	  (The systems I was familiar with have a linker cache or a
	  configuration file which let you specifoy additional default
	  directories for all binaries.)

	* As of Solaris 2.4, the imake templates shipped by Sun would
	  generate executables that don't run.  Executables would be
	  linked with -L/usr/openwin/lib (causing them to link against
	  the shared libraries) but not with -R/usr/openwin/lib, so
	  they wouldn't have a runtime path allowing them to find the
	  shared libraries.  The binaries in /usr/openwin/lib do have
	  a runtime path, so they clearly weren't built with the
	  shipped templates.

	  This is fixed in Solaris 2.5 (the imake templatesf specify
	  /usr/openwin/lib), but that doesn't help us deal with the
	  binaries already out there, or the binaries that will be
	  built under Solaris 2.4.

	* /usr/openwin/bin/openwin, the script for starting the X
	  server in the Open Windows environment, does an "export
	  LD_LIBRARY_PATH" but doesn't actually set any linker
	  variables, suggesting that at some point they relied on
	  LD_LIBRARY_PATH to find X libraries but don't any more.  Not
	  terribly relevant.

	* Because we had the symlinks in /usr/lib in the 7.7 release,
	  there are (presumably) a lot of binaries out there that
	  work right now, and would break if the symlinks were taken
	  away.

	  (A better solution for the 7.7 release would have been to
	  set LD_LIBRARY_PATH in the global environment, but I wasn't
	  working here at the time.)

So we have to leave the symlinks in there for now.  The only way I can
conceive of getting rid of them is to hope that a future release of
Solaris has a more configurable dynamic linker.  It doesn't look like
2.6 helps any.


home help back first fref pref prev next nref lref last post