[M3commit] CVS Update: cm3

[Jay Krell]

CVSROOT:	/usr/cvs
Changes by:	jkrell at birch.	09/04/13 12:55:50

Modified files:
	cm3/m3-sys/cminstall/src/config-no-install/: FreeBSD4 

Log message:
	working experiment/prototype for issue of "how to find dependent shared paths"
	vs. "do uninstalled binaries work"
	vs. buildlocal vs. buildglobal
	
	There are many possibilities.
	
	This implements the following.
	Note that libm3 is the easiest file to experiment with.
	m3core has no dependencies, libm3 is dependent only on m3core.
	
	----
	
	prepare, build m3core and libm3
	cd $CVSROOT/m3-libs/m3core
	/cm3/bin/cm3
	cd ../libm3
	/cm3/bin/cm3
	
	----
	
	show some scenarios
	
	----
	
	regular cm3 with no switches/env -- "buildglobal"
	rm FreeBSD4/*a
	/cm3/bin/cm3
	objdump -x FreeBSD4/libm3.so | grep PATH
	RPATH       $ORIGIN/../lib:$ORIGIN/../../lib:$ORIGIN/../../../lib:/cm3/bin/../lib
	
	The resulting file is generally machine portable and in a pinch
	contains a full local path to libraries. Or in a worse pinch, LD_LIBRARY_PATH will still work.
	
	That is, if you install it to cm3installroot/bin or cm3installroot/pkg/package/target,
	it will find dependendent libraries via $ORIGIN.
	
	If you installed it elsewhere or leave it uninstalled, it will still most likely
	find the exactly correct file, still with a short rpath.
	
	Note that this "../../../lib" business is a little sloppy.
	1) ../../lib preceding it is some "insurance", but not much
	2) better slower insurance would be to use
	$ORIGIN/../pkg/m3core/target/../../../lib
	$ORIGIN/../../../pkg/m3core/target/../../../lib
	
	If you assume dots are not smushed out early, as they generally aren't on Unix
	(but they generally are on Windows), then this kind of makes sure the directory
	structure is as expected by walking through known must-exist directories.
	
	What would be even better along these lines is knowing the finall install point
	of the file and compute the exact relative path to the cm3 installed libraries.
	For cm3 itself, this will yield just one of $ORIGIN/../lib or $ORIGIN/../../../lib.
	For files installed arbitrarily elsewhere, this would be otherwise.
	Consider for example:
	/opt/cm3/lib/libm3core.so
	/opt/package-written-in-modula3/bin/foo
	There you would want $ORIGIN/../../cm3/lib.
	
	This exact computation of relative path for installroot/lib should probably be
	implemented, very soon.
	
	It would also be nice if runpath could read like
	if CM3_INSTALL defined, runpath=$CM3_INSTALL/lib.
	but it cannot.
	
	----
	
	buildlocal aka with "overrides"
	
	rm FreeBSD4/*a
	/cm3/bin/cm3 -override
	objdump -x FreeBSD4/libm3.so | grep PATH
	RPATH       /dev2/cm3/m3-libs/m3core/FreeBSD4
	
	This gives you an rpath entry for each dependent file, and they are each found directly, in their non-installed
	locations. This is the historical default. It gives you a long runpath. Almost nobody noticed.
	It requires that extra switch -override or -x, but gives you binaries that do work without installing,
	but are not particularly machine portable and again, long runpath.
	
	----
	
	buildglobal with an extra option
	
	rm FreeBSD4/*a
	M3_PORTABLE_RUN_PATH=1 /cm3/bin/cm3
	objdump -x FreeBSD4/libm3.so | grep PATH
	RPATH       $ORIGIN/../lib:$ORIGIN/../../lib:$ORIGIN/../../../lib
	
	This is the same rpath as the first, but containing only the $ORIGIN entries and
	omitting the last exact full path. This is good for building machine-portable archives.
	
	Again, a more precise origin to lib path should be computed, thereby
	going from three paths to one.
	
	A command line switch for M3_PORTABLE_RUN_PATH should probably be invented.
	It is hard to name this thing though.
	
	----
	
	This does not fit all scenarios easily or automatically, unfortunately.
	However it does seem like a good mix of compromises.
	Main thing to still do is compute relative path for $ORIGIN to cm3installroot/lib.
	Might be trivial with path_of().
	
	----