<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
Hey..I have a crazy notion that maybe<BR>"ship" should first "relink".<BR>
<BR>
<BR>I've seen this thing..when I watch thw grass grow..I mean autoconf output run..<BR>"how to embed full paths upon install"..."relink"... on some systems..<BR>and I think..geez..what a waste, instead of just copying files, first<BR>they get relinked.<BR>
<BR>
<BR>Now..I find myself wanting something this and it seems maybe only this<BR>can provide.<BR>
<BR>
<BR>Let's limit discusion to Linux for now.<BR>These issues are not unique to it.<BR>But the area is full of confusing variables enough.<BR>
<BR>
<BR>When I build a "regular" build, historically, on Linux,<BR>binaries have a big bunch of paths run together in them, like:<BR>
<BR>
<BR> /cm3/pkg/m3core/AMD64_LINUX:/cm3/pkg/libm3/AMD64_LINUX:etc.<BR>
<BR>
<BR>Maybe maybe each one directory is associated with each one library,<BR>though I don't think so.<BR>
<BR>
<BR>This is called the "run path" and is where dependent shared libraries<BR>are sought, among other places. $LD_LIBRARY_PATH is another place<BR>but there is some general vague intent that "real" binaries shouldn't<BR>depend on that, that it is only for "ad hoc development mode".<BR>
<BR>
<BR>These full paths are specific to my machine.<BR>Other people might have /usr/local/cm3/pkg.<BR>Or whatever.<BR>
<BR>
<BR>Now, today I have made things a bit better.<BR>
<BR> <BR>
The first path is $ORIGIN/../lib.<BR>$ORIGIN is a special syntax for "The directory with the executable".<BR>That really is not a sufficient mechanism, but it is a small step forwarder.<BR>YOu want relativity from the referencing file, not just the executable.<BR>Or something more abstract not dealing with paths at all..<BR>
<BR> <BR>
Now, when I make a distribution, I build everything in /tmp/tmprandom.<BR>These paths are in the binaries produce.<BR>Possibly preceded by $ORIGIN/../lib, but still, I'd rather not "infect"<BR>the binaries with these paths.<BR>
<BR>
<BR>Now, we also run binaries before they are installed -- PklFonts in particular.<BR>And user should be expected to be able to run uninstalled binaries.<BR>
<BR>
<BR>
SO long story long... I suggest relink immediately prior to "ship".<BR>But this link will omit the bulk of -Wl,-rpath chunks, leaving<BR>only the -Wl,-rpath $ORIGIN/../lib.<BR>
<BR>
<BR>Thoughts?<BR>
<BR>
<BR>My "research" so far only applies to Linux.<BR>
<BR>
<BR>Maybe the prepending of $ORIGIN/../lib is enough mitigation.<BR>
<BR>
<BR>It does bug me though that if you move the binaries around<BR>such that ../lib is not correct, and you happen to have the same<BR>/tmp/tmprandom/... on your system that I had..very unlikely I realize..<BR>that you will "unintentionally" load the "wrong" file.<BR>
<BR> <BR>
I'm not super keen on making these changes either..actually<BR>digging through and changing all the relevant Modula-3....<BR>
<BR>
<BR>Other options include something like the M3_NEED_STANDALONE_LINKS option.<BR>
<BR>
<BR>Or maybe this is kind of novel/clever/reasonable, always building<BR>standalone and shared, standlone named plain "foo", shared/dynamic<BR>named "foo.dynamic", and have ship install the dynamic one,<BR>built with just -Wl,-rpath,$ORIGIN?<BR>
<BR>
<BR>This would waste a lot of time and diskspace for rarely used files though.<BR>
<BR>
<BR>Well, duh, a little less wasteful, when building dynamic, build<BR>two versions, both dynamic, one with the one small rpath, one with<BR>the usual larger one? This is easier.<BR>However if you assume a high build/run/debug to it works/install ratio,<BR>this is also wasteful. I come back to the original -- relink upon ship.<BR>
<BR>
<BR>
Again, I'm not super excited to do this work, but it really does<BR>
seem like the right thing.<BR>
<BR>
<BR>
More generally, if you think about systems that don't support $ORIGIN<BR>
and you think about some of the Modula-3 distribution formats,<BR>
relinkin during setup/install of a "distribution" is also a good albeit<BR>
onerous idea.<BR>
<BR>
There's this general theme around "how much of the build occurs<BR>
on one machine vs. the machine the binaries will run on" and<BR>
"stopping the build near the end, and finishing it later<BR>
on another machine".<BR>
<BR>
<BR> - Jay<BR><BR></body>
</html>