[M3devel] $ORIGIN/../lib vs. $ORIGIN/../../../lib?

Jay jay.krell at cornell.edu
Tue Apr 14 17:29:11 CEST 2009


$ORIGIN/../lib vs. $ORIGIN/../../../lib?
 

It doesn't appear simple to know which of these runpaths to use.
It depends on if the file is exported to bin or just "regular".
It would be nice to just use one of these and not concatenate them.
 

Usually "libraries" are in pkg and "executables" are not.
But
 cm3 is an exception, can be ignored
  in general anything "standalone" can be ignored
 vorun is an exception.
 cmpfp is an exception.
   Also standalone.
 

Is that it?
 Ignore cm3, change the others to go to bin, and use that rule then?
 cvsup and cvsupd where also exceptions but I went ahead and changed them.
 m3back is an exception, but isn't really ever used.
 uniq is an exception.
   But it is build static.
 

There, is you know, the notion of an executable that is only meant
to be run by code, not humans directly (e.g. cm3cg, cc1, etc.).
 

These can be located outside of $PATH.
 

I guess I can do this with "non local" information or parameter passing?
I assume it is too painful right now to add a parameter to the quake link function.
or maybe not -- go ahead and add a parameter to m3_link and make_lib,
giving the installed path of the file?
proc make_lib(lib, options, objects, imported_libs, shared, installed_path) is
proc m3_link(prog, options, objects, imported_libs, shared, installed_path) is
 

?
This would affect all configuration files.
Several alternatives..that might be too large:
  Stop shippping any shared libraries or executables to pkg, just bin and lib?
  Or, reverse the sense of the file vs. symlink?
  Or make them hardlinks -- not great, since runpath would be wrong for one of them.
 

Relink-upon-install still seems reasonable -- it knows the destination path.
 
 
Is "../../../lib" moving too far around?
 
 
 
How about the notion of confirming the layout, using:
  $ORIGIN/../pkg/m3core/target/../../..
  $ORIGIN/../../../pkg/m3core/target/../../..
 
 
Does that feel safer? And not too inefficient?
This way generally the ../../../ doesn't hold, unless "pkg/m3core/target" exists.
 

 - Jay


More information about the M3devel mailing list