[M3devel] pkg roots/origin/ld_library_path

[jay.krell at cornell.edu]

I see the base contradiction is between custom install location, non  
root install, and Unix binary installs. Whenever I install binaries in  
Unix I have to be root and I get no choice of install location. Only  
when I build from source are both of these relaxed.

Windows varies. Often I can chose install location and sometimes I  
don't have to be admin (but I always am).

$origin is a way to address this, but relative locations remain fixed.

  - Jay (phone)

On Jul 7, 2009, at 6:05 AM, Olaf Wagner <wagner at elegosoft.com> wrote:

> I understand that the $ORIGIN use in library paths does not work
> if we want to have hierarchical overrides for an arbitrary set of
> package pools. We'll either have to use absolute paths or rely
> on a correct (automatically computed?) LD_LIBRARY_PATH setting.
>
> How do $ORIGIN and LD_LIBRARY_PATH work together? Are there
> consistently defined semantics on different systems?
>
> Could we use $ORIGIN just for the one global system installation,
> and rely on absolute paths for all other pools? Of course we'd
> loose the ability to just copy from one pool to another this way,
> but that may not be that important.
>
> Anyway, we (at least I) won't work on it right now...
>
> Olaf
>
> Quoting Jay K <jay.krell at cornell.edu>:
>
>>
>> Really, I understand, but there is a problem nobody seems to see.
>>
>>
>> Let's say there are multiple pkg roots.
>>
>>
>> Remember my question? It is very important.
>>  "How are the dependencies of an .so or executable found?"
>>
>>
>> What if I install to /opt/cm3.
>> You install to $HOME/cm3 -- no need for root!
>> We have some root/bin/executable.
>> It uses of course libm3core.so.
>>
>>
>> I want to be able to copy it from machine to machine, probably   
>> without relinking it or running some tool over it.
>>
>>
>> People want to install libm3core.so to different places on  
>> different  machines.
>>
>>
>> Does root/bin/executable refer
>> to /opt/cm3/lib?
>> or $HOME/cm3/lib?
>> or $ORIGIN/../lib?
>> or no directory and user sets LD_LIBRARY_PATH?
>>  I'm not even sure you can omit the directory.
>>
>>
>> There is a basic contradiction here.
>> $ORIGIN is good. $ORIGIN is bad.
>> LD_LIBRARY_PATH is good. LD_LIBRARY_PATH is bad.
>> Full paths are good. Full paths are bad.
>> The ability to install to different places is good. The ability to   
>> install to different places is bad.
>>
>>
>> You cannot have all of:
>>  ability to specify install location
>> AND multiple package roots, where a package root is sparse
>> AND if I install to a custom location, I don't have to set  
>> LD_LIBRARY_PATH
>>
>>
>> Now, while I advocate(d) $ORIGIN and custom install locations and  
>> no  need for LD_LIBRARY_PATH, that approach does devolve to  
>> everything  being in the same directory, which also seems not great.
>>
>>
>> The difference is often that you don't use $ORIGIN for "well known   
>> important stuff".
>> You don't get "libc.so" from $ORIGIN/../lib. You get it from where   
>> it always is, like /usr/lib or somesuch. You don't actually ever  
>> use  a custom install for it. If you want to build your own, you  
>> are  probably building your own entire system, and might use chroot  
>> as  part of that.
>>
>>
>> But where is the line between "my stuff" and "well known important   
>> stuff"? Where is the line between stuff that can be installed   
>> anywhere vs. stuff that must be installed to its "standard" location?
>>
>>
>> - Jay
>
>
>
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germ 
> any
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>   http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Be 
> rlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
> DE163214194
>
>