[M3devel] runpath/unshipped vs. shipped binaries

[Jay]

Here's another point I just discovered...granted, I did say I was only talking about Linux..but on Solaris, I just learned about -s on ldd:
 
 
 ldd -s /cm3/bin/Juno
 
 
   find object=libm3.so.5; required by /home/jay/cm3/bin/../lib/libjuno-compiler.so.5
    search path=/usr/local/lib  (LD_LIBRARY_PATH)
    trying path=/usr/local/lib/libm3.so.5
    search path=$ORIGIN/../lib:/cm3/pkg/juno-machine/SOLgnu:/cm3/pkg/libm3/SOLgnu:/cm3/pkg/m3core/SO
Lgnu  (RPATH from file /home/jay/cm3/bin/../lib/libjuno-compiler.so.5)
    trying path=/home/jay/cm3/pkg/juno-compiler/SOLgnu/../lib/libm3.so.5
    trying path=/cm3/pkg/juno-machine/SOLgnu/libm3.so.5
    trying path=/cm3/pkg/libm3/SOLgnu/libm3.so.5
 
 
   find object=libm3core.so.5; required by /home/jay/cm3/bin/../lib/libjuno-compiler.so.5
    search path=/usr/local/lib  (LD_LIBRARY_PATH)
    trying path=/usr/local/lib/libm3core.so.5
    search path=$ORIGIN/../lib:/cm3/pkg/juno-machine/SOLgnu:/cm3/pkg/libm3/SOLgnu:/cm3/pkg/m3core/SO
Lgnu  (RPATH from file /home/jay/cm3/bin/../lib/libjuno-compiler.so.5)
    trying path=/home/jay/cm3/pkg/juno-compiler/SOLgnu/../lib/libm3core.so.5
    trying path=/cm3/pkg/juno-machine/SOLgnu/libm3core.so.5
 

Which shows us that $ORIGIN is not the executable, it is the referencing file.
Could be ipmlemented to be "both", have it search both, but I don't think it is.
 
 
This begs for another large change.
 Don't ship any /cm3/pkg/foo/platform/libfoo.so.
Ship only
  /cm3/lib/libfoo.so
 
 
The second is already a symlink to the first anyway.
And then add $ORIGIN and $ORIGIN/../lib to RPATH.
Heck -- might as well just shove it all into /cm3/bin and just use $ORIGIN, kind of like how NT works..ok, I know that last step wouldn't likely be popular and it isn't important -- keep lib and bin split.
 
 
One of the qeustions is -- do we believe we have a "useful" "hierarchy", or the world is really kind of flat anyway, embrace it?
Given that lib is full of symlinks into pkg, seems like flat is the case and the hierarchy just looks nice, at least for .so file placement (*.i3/*.m3/*.m3x/*.a files would remain asis).
 
I also think there's an issue here that..the ship structure and source structure should perhaps have been kept in parallel. That might allow for relative rpaths to work for uninstalled or installed binaries. Except, the source structure has more hierarchy than the ship structure, always. That is, shipping is a rearrangement of the source structure -- insert "pkg" and flatten.
 
 src/m3-libs/m3core => install/pkg/m3core 
 src/m3-foo/bar => install/pkg/bar 
 
If instead it went:
 
 src/m3-libs/m3core => install/m3-libs/m3core 
 src/m3-foo/bar => install/m3-foo/bar 
 
or:
 src/m3-libs/m3core => install/pkg/m3-libs/m3core 
 src/m3-foo/bar => install/pkg/m3-foo/bar 
 
Then relative paths could probably be used in both roots with the same meaning.
But they can't.
 
I come back to..I guess..removing all the .so files from the pkg store, or reversing the sense of the symlinks. Or heck, just telling the linker -L /cm3/lib instead of -L/cm3/pkg/foo. That last step might be trivial and helpful.
I'll try it, later.
 
 - Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: carson at taltos.org; m3devel at elegosoft.com
> Subject: RE: [M3devel] runpath/unshipped vs. shipped binaries
> Date: Mon, 6 Apr 2009 04:23:14 +0000
>
>
>
> - The horrid RPATH is not my doing. It has "always" been that way.
>
> - The horrid RPATH is needed, for running not installed binaries, a very real scenario,
>
> - Jay
>
>
>
> ----------------------------------------
>> Date: Sun, 5 Apr 2009 20:17:02 -0700
>> From: carson at taltos.org
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] runpath/unshipped vs. shipped binaries
>>
>> Jay wrote:
>> ...
>>> When I build a "regular" build, historically, on Linux,
>>> binaries have a big bunch of paths run together in them, like:
>>>
>>>
>>> /cm3/pkg/m3core/AMD64_LINUX:/cm3/pkg/libm3/AMD64_LINUX:etc.
>> ...
>>> Now, today I have made things a bit better.
>>>
>>>
>>> The first path is $ORIGIN/../lib.
>>> $ORIGIN is a special syntax for "The directory with the executable".
>>> That really is not a sufficient mechanism, but it is a small step forwarder.
>>> YOu want relativity from the referencing file, not just the executable.
>>> Or something more abstract not dealing with paths at all..
>>
>> If you're saying that today you produce binaries with an RPATH of:
>>
>> $ORIGIN/../lib:/cm3/pkg/m3core/AMD64_LINUX:...
>>
>> That's just... horrid.
>>
>> Assuming all of your libraries are in ${exe_path}/../lib, you need
>> exactly one RPATH entry:
>>
>> $ORIGIN/../lib
>>
>> Get rid of _all_ the other "-R foo" link arguments, and all will be
>> well. No need to relink if you link properly the first time.
>>
>> --
>> Carson