[M3devel] runpath/unshipped vs. shipped binaries

[Jay]

ok, nevermind, thanks Carson, that helped.
 
Like you said:
 
 RUNPATH shall be small and portable and just $ORIGIN/../lib.
 
 I saw $ORIGIN within pkg and not lib, but now I see it only within lib.
 Maybe a clean rebuild fixed that, not sure (I had been just deleting all the .a files).
 If it flips and becomes consistently pkg, I'll try ORIGIN/../../../lib. Too many dot dots seems bad, could be escaping some part of the file system into who-knows-where. I have an idea you could verify your location something like $ORIGIN/../../../pkg/package/platform/.../../../lib. The extra traversal "../../../pkg/package/platform" ensure things are kind of how you expect, though wasteful. Anyway, hopefully not this.
 
 
 Running uninstalled binaries shall require either LD_LIBRARY_PATH or build_standalone(). m3tests uses build_standalone. This is maybe why more stuff is build_standalone -- anything that runs uninstalled when doing buildlobal, the various stub code generators.
 
 
 Systems that don't support $ORIGIN, hopefully that is not many, such as NetBSD, will require LD_LIBRARY_PATH. Another option is to relink on the target and point at /cm3/lib or such, but that requires the notion of relinking on target, which is in limbo.
 
 
  No full path is likely to be baked into any binary, for any system.
 
 
  Darwin is different but achieves similar goals. I changed my configuration files for PPC_DARWIN. I don't have the other architectures available (hm, maybe non-OSX Darwin in a VM, maybe).
 
 
 NT386 is different but achieves similar goals.
  There all the .exes and .dlls are shipped to the same directory.
  .exe directories are generally searched for .dlls.
 
 
 A lot of this is still speculative. Solaris seems in good shape, and Darwin, but I have to look into others still.
 

  - Jay



----------------------------------------
> From: jay.krell at cornell.edu
> To: carson at taltos.org
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] runpath/unshipped vs. shipped binaries
> Date: Mon, 6 Apr 2009 08:08:50 +0000
>
>
> Well, the big polluted runpath is how Modula-3 has always built things.
> The only reason for /tmp/tmprandom is because I build up an entire new install from scratch. Otherwise it would be /usr/local/cm3/pkg/... or such.
> If you look at the distributions Olaf has put out you can see he does similar.
> I think the Tinderbox builds are the same.
>
>
> This is tied up in the Quake code:
> M3_SPLIT_LIBNAMES = TRUE
> % --- split library names and pass -L/-l arguments to the linker
> if not defined("M3_SHARED_LIB_ARG")
> M3_SHARED_LIB_ARG = "-Wl,-R"
> end
>
> plus the fact that "install" is very interested in a "package store" and each set of files going in their own directory, and "imported libraries" coming from there, not a flattened /cm3/lib.
>
>
> I'm not sure I like it either, but it has been this way.
>
> Running uninstalled binaries seems very reasonable to me, and is also a long standing practise in the cm3 system, but maybe only one instance.
>
>
> I'm trying to find a way to
> - have a small portable runpath
> - allow uninstalled binaries to work
>
> but I think you might be right that LD_LIBRARY_PATH is how to get the second scenario to work. But that does require LD_LIBRARY_PATH be set within making a distribution. Or maybe just build PklFonts standalone, or ship it and then run it. Standalone is easiest.
>
> But this is really tying people's hands it seems, in terms of how much uninstalled binaries work. Maybe there should be an option to install .sos to /usr/lib so LD_LIBRARY_PATH can be left alone?
>
>
> I'm still looking into it all though.
> Could be that -L/cm3/pkg/foo -lfoo is fine, as long as the -R is dropped.
> I'll have to check that the full path to libfoo.so isn't recorded, but just the leaf libfoo.so.
>
> I guess for .so files we can use rpath like $ORIGIN/../../../lib.
> Where the ".." are backing up over pkg/package/platform to get back to root.
>
>
>
> - Jay
>
>
> ----------------------------------------
>> Date: Sun, 5 Apr 2009 23:54:00 -0700
>> From: carson at taltos.org
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] runpath/unshipped vs. shipped binaries
>>
>> Jay wrote:
>>>
>>> - 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,
>>
>> No. It's not needed. Please provide a use case where a crappy polluted
>> RPATH provides any benefit, and be specific.
>>
>> If you need to _temporarily_ run binaries in the build tree, where
>> ${exe_path}/../lib does not contain libraries, set LD_LIBRARY_PATH
>> (which overrides RPATH). Or, better still, fix the build to put things
>> in $foo/bin and $foo/lib before you run them.
>>
>> Hard-coding /tmp/frobnitz/blah/lib in RPATH is _extremely_ bad from many
>> perspectives, including security. Don't do it. No really, don't.
>>
>> --
>> Carson