[M3devel] runpath/unshipped vs. shipped binaries

Sun Apr 5 14:56:07 CEST 2009

Hey..I have a crazy notion that maybe
"ship" should first "relink".

I've seen this thing..when I watch thw grass grow..I mean autoconf output run..
"how to embed full paths upon install"..."relink"... on some systems..
and I think..geez..what a waste, instead of just copying files, first
they get relinked.

Now..I find myself wanting something this and it seems maybe only this
can provide.

Let's limit discusion to Linux for now.
These issues are not unique to it.
But the area is full of confusing variables enough.

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.

Maybe maybe each one directory is associated with each one library,
though I don't think so.

This is called the "run path" and is where dependent shared libraries
are sought, among other places. $LD_LIBRARY_PATH is another place
but there is some general vague intent that "real" binaries shouldn't
depend on that, that it is only for "ad hoc development mode".

These full paths are specific to my machine.
Other people might have /usr/local/cm3/pkg.
Or whatever.

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..

Now, when I make a distribution, I build everything in /tmp/tmprandom.
These paths are in the binaries produce.
Possibly preceded by $ORIGIN/../lib, but still, I'd rather not "infect"
the binaries with these paths.

Now, we also run binaries before they are installed -- PklFonts in particular.
And user should be expected to be able to run uninstalled binaries.

SO long story long... I suggest relink immediately prior to "ship".
But this link will omit the bulk of -Wl,-rpath chunks, leaving
only the -Wl,-rpath $ORIGIN/../lib.

Thoughts?

My "research" so far only applies to Linux.

Maybe the prepending of $ORIGIN/../lib is enough mitigation.

It does bug me though that if you move the binaries around
such that ../lib is not correct, and you happen to have the same
/tmp/tmprandom/... on your system that I had..very unlikely I realize..
that you will "unintentionally" load the "wrong" file.

I'm not super keen on making these changes either..actually
digging through and changing all the relevant Modula-3....

Other options include something like the M3_NEED_STANDALONE_LINKS option.

Or maybe this is kind of novel/clever/reasonable, always building
standalone and shared, standlone named plain "foo", shared/dynamic
named "foo.dynamic", and have ship install the dynamic one,
built with just -Wl,-rpath,$ORIGIN?

This would waste a lot of time and diskspace for rarely used files though.

Well, duh, a little less wasteful, when building dynamic, build
two versions, both dynamic, one with the one small rpath, one with
the usual larger one? This is easier.
However if you assume a high build/run/debug to it works/install ratio,
this is also wasteful. I come back to the original -- relink upon ship.

Again, I'm not super excited to do this work, but it really does

seem like the right thing.

More generally, if you think about systems that don't support $ORIGIN

and you think about some of the Modula-3 distribution formats,

relinkin during setup/install of a "distribution" is also a good albeit

onerous idea.

There's this general theme around "how much of the build occurs

on one machine vs. the machine the binaries will run on" and

"stopping the build near the end, and finishing it later

on another machine".

 - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090405/e8fa151d/attachment-0001.html>