[M3devel] runpath/unshipped vs. shipped binaries

[Jay]

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