<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
Before I explain, more options:<BR>
<BR> copy and commit the source to cm3 is viable<BR>
<BR>
<BR> heck, use a relative instead of absolute from ROOT<BR>
<BR>
<BR> go back to the old way (I'll explain)<BR>
<BR>
<BR> There is also the option to relink or "fixup"<BR> upon ship and/or install. Some platforms have a "fixup"<BR> utility for exactly "these reasons".<BR> MacOS X has one.<BR>
<BR>
<BR>The question is:<BR>
<BR>
How does program foo find libbar.so?<BR> At runtime.<BR><BR>
How does libbar.so find libfoo.so?<BR>
<BR>
<BR>
There are a bewildering array of choices.<BR>They are combinable.<BR>
It varies somewhat from platform by platform, but not much really.<BR>
<BR>The main options are:<BR>
<BR>
<BR>1: A full path written into program foo<BR>or libbar pointing to e.g. /usr/lib/libfoo.so.<BR>
Actually this is usually separate libfoo.so and<BR>
a list of directories that apply to all .so files.<BR>
There isn't generally a matching up of directory to file,<BR>
I think, but a "search path" aka "run path".<BR>
<BR>
<BR>2: A relative path written into program foo<BR>or libbar.so point to e.g. $ORIGIN/../lib/libfoo.so.<BR>
Again, the directories are split from the files.<BR>
<BR>
<BR>MacOS X doesn't have $ORIGIN by that name, but it<BR>has three similar things, like @executable_path.<BR>
@executable_path goes way back and is presumably<BR>
relative to the primary main executable.<BR>
There are two other similar options.<BR>
One is new in 10.5. Presumably one is relative<BR>
to the reference. And maybe one is some concatenation<BR>
of all directories anything found in so far? I don't know.<BR>
The documenation was not clear to me.<BR>
<BR>
<BR>NetBSD prior to 5.0 doesn't have $ORIGIN.<BR>
<BR> <BR>
NT searches $PATH always.<BR>
We put the .dlls in bin.<BR>
Cygwin same.<BR>
<BR>
<BR>Approximately all other systems seem to support about the same $ORIGIN feature:<BR> OpenBSD, FreeBSD, Linux, Solaris, NetBSD 5.0, even Interix, and others (Aix? Irix? HP-UX?)<BR> The MacOS X feature is close enough to lump in.<BR>
<BR>3: Search $LD_LIBRARY_PATH or similar.<BR> This has a few different names.<BR>
LD_LIBRARY_PATH32, LD_LIBRARY_PATH64, DYLD_SOMETHING.<BR>
<BR>
<BR>
Now, our historical implementation was<BR> - record a full path /usr/local/cm3/pkg/foo/LINUX/libfoo.so,<BR> a path for every dependency<BR>
The file formats are generally such that there are leaf file names<BR> separate from an array of directories to look in. A "normal"<BR> non-Modula-3 program would generally I assume have a prety small<BR> such array of directories. A "normal" Modula-3 program would have<BR> a fairly large array.<BR>
As well, doing builds for distribution would often leave you with /tmp/cm3<BR> which is a possible security problem. This definitely did occur.<BR>
<BR> <BR>
Now, again, there are many options, and they can be combined.<BR>Portability is perhaps a concern, but perhaps not so much, given today's landscape.<BR>
<BR>
<BR>
Now, if we are to use relative paths, well, my understanding is that<BR>the "real" files need to be in relatively few directories, e.g. /usr/local/cm3/lib,<BR>and not /usr/local/cm3/pkg/foo/linux etc.<BR>
<BR> <BR>
This way, files in lib and bin can point to $ORIGIN/../lib.<BR>
<BR> <BR>
Now, keep in mind, that unshipped binaries sometimes people like to work,<BR>as well, perhaps also programs (not shared libraies, as far as I know)<BR>buried in the pkg store /usr/local/cm3/pkg/foo/linux/foo.<BR>
I know cm3 sits in there, though that copy isn't used.<BR>
<BR>
<BR>I make no account for binaries buried in the package store.<BR>
<BR>I do make some account for unshipped binaries.<BR>
<BR>By default the run paths we are recording in current config files <BR>are<BR>
$ORIGIN/../lib:/usr/local/cm3/lib<BR>
Not a bunch of paths into pkg, just two entries.<BR>
<BR>
<BR>The "security" issue still is present by default.<BR>But the run path is "prettier" and probably more efficient.<BR>
<BR>
<BR>When you build a distribution however, you are expected to omit /usr/local/cm3/lib (it might be /tmp/cm3).<BR>This is controled by an environment variable, which I set in Olaf's scripts, but oops<BR>I think I set it too late. I'll fix that very very soon.<BR>
<BR>
<BR>To recap:<BR>
- full paths<BR> - relative paths from $ORIGIN<BR> - LD_LIBRARY_PATH<BR>
<BR>
They each have advantages and disadvantages.<BR>$ORIGIN provides for a "movable" install. I can install to /usr/local/cm3,<BR>you can install to /opt/cm3. It'll just work. No need to change LD_LIBRARY_PATH.<BR>
<BR>
<BR>However if I want to move just some of the files, not the whole binary tree<BR>together, then $ORIGIN breaks down.<BR>
<BR>
<BR>If really want one file here, another there, and another somewhere else, $ORIGIN doesn't do.<BR>You are left with full paths or LD_LIBRARY_PATH.<BR>
<BR>
<BR>Oh, and moral equivalent of LD_LIBRARY_PATH, like /etc/ld.so.conf or such.<BR>Look on birch for example, it is /usr/local/cm3/lib.<BR>
That tripped me up actually, because, you know, my cm3 is in $HOME/cm3 there.<BR>
This demonstrated another problem in this area!<BR>
$ORIGIN keeps things more tightly together, which you often want, sometimes might not not.<BR>
LD_LIBRARY_PATH lets things be spread around, again, sometimes you want that, sometimes not.<BR>
I figure tightly point is the more common, but imagine if you just want to replace one file.<BR>
Is that reasonable? You replace it by putting it elsewhere? (Imagine "patching" an install<BR>
this way.)<BR>
<BR> <BR>
So, here now I'm rambling.<BR>I've laid out the options and /some/ of the disadvantages/advantages.<BR>
<BR>
<BR>There is no perfect solution, and the various solutions are combinable.<BR>I find combining them though, I start to get confused.<BR>Because you end up in a "probing" situation and you start wondering<BR>which supercedes which, and you just hope there aren't any "duplicates"<BR>so that the probe order is mostly moot (assuming there remain no duplicates).<BR>
<BR>
<BR>
Somewhat clear?<BR>
<BR>
<BR>
You run, e.g. elfdump -p foo | grep -i path or somesuch, or ldd foo or ldd -v or -V foo and<BR>
investigate the various options and their effects. Solaris has a very nice and verbose<BR>
ldd form.<BR>
<BR>
<BR>
Now, the files in pkg.<BR>I consider it somewhat philosophically significant that "everything is in pkg".<BR>
There is a well structured "repository" not a randomly organized bunch of files.<BR>I think. Maybe this is just a suggestion?<BR>You know, if they are hardlinks and we don't really use the ones in pkg, is<BR>there a point?<BR>
<BR>
<BR>Or, on the other hand, is the philosophy a big deal and we should go back to<BR>lib symlinking to pkg to appease the philosophy?<BR>
<BR>
<BR>
"ship/install" certainly "likes" to put things in pkg.<BR>
I don't think the option of using lib and not pkg is doable without builder changes.<BR>
But that is doable.<BR>
<BR>
<BR>
A few other folks here did pipe up some on this in the recent past and<BR>I think there was kinda sorta consensus that the old ways were not great<BR>(particularly 1) the big runpath 2) the runpath into /tmp)<BR>and the new ways maybe better, but I admit there was no clear consensus.<BR>I acted somewhat unilaterally. You know, I'm impatient and arrogant so...<BR>
and Tinderbox is there to cause some restraint.<BR>
<BR>
<BR>There was definitely pushback on wanting unshipped binaries to keep working,<BR>which they largely do as a result of the discussion/pushback.<BR>
<BR>
<BR>As well, any unshipped binaries that we know we use in the build, like PklFonts,<BR>stubgen, m3bundle, we build standalone, to evade/avoid problems here,<BR>since $ORIGIN/../lib won't work and the full paths are meant to be omitted.<BR>I consider this not great.<BR>
<BR>I think, really, we should be able to dynamically link everything really,<BR>including cm3. I don't think we should static link just to make up for<BR>the need for a backup. There are plenty of backups available and you can<BR>make plenty more. However this will have to wait and probably take<BR>more arguing and maybe demonstration of its viability.<BR>I will require some work to make work anyway.<BR>
<BR>
<BR>
At one point I was confused about the need for static linking so accepted it strongly.<BR>
Now I don't see it. If you just need backups, again, they exist, and you can make more.<BR>
Static linking isn't imho a substitute for backups.<BR>
There are technical problems to be solved though.<BR>
<BR>
Could be that these issues are related though. If your backup might<BR>
load the wrong m3core.so too easily, making it not a very reliable backup,<BR>
static linking could mitigate that. But $origin seems like a good mitigation.<BR>
I'm strongly considering add just plain $origin, in addition to $origin/../lib to runpath.<BR>
That way you can just put everything in one messy but easier to move/copy directory.<BR>
<BR>
<BR> - Jay<BR><BR><BR><BR><BR> <BR>> Date: Thu, 2 Jul 2009 20:04:36 +0200<BR>> From: wagner@elegosoft.com<BR>> To: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] ROOT<BR>> <BR>> Quoting Tony Hosking <hosking@cs.purdue.edu>:<BR>> <BR>> > That sounds plausible. Is there anything in the current setup that<BR>> > depends on the .so files being in pkg instead of lib?<BR>> <BR>> I don't think so offhand. But I must admit that I've lost the overview<BR>> in this area, too :-/<BR>> <BR>> Olaf<BR>> <BR>> > On 2 Jul 2009, at 13:34, jay.krell@cornell.edu wrote:<BR>> ><BR>> >> How about we put .so files only in lib and not in pkg? Or symlink <BR>> >> from pkg to lib instead of how it used to be the other way around? <BR>> >> Those would also fix all this.<BR>> >><BR>> >> - Jay (phone)<BR>> >><BR>> >> On Jul 2, 2009, at 9:21 AM, Jay <jay.krell@cornell.edu> wrote:<BR>> >><BR>> >>><BR>> >>> Are you up to date in m3-libs/m3core?<BR>> >>> Lots of builds have succeeded with this..<BR>> >>> It isn't great, but that requirement to build from previous 5.4 release..<BR>> >>><BR>> >>> - Jay<BR>> >>><BR>> >>> ________________________________<BR>> >>>> From: hosking@cs.purdue.edu<BR>> >>>> To: hosking@cs.purdue.edu<BR>> >>>> Date: Thu, 2 Jul 2009 11:54:51 -0400<BR>> >>>> CC: m3devel@elegosoft.com<BR>> >>>> Subject: Re: [M3devel] ROOT<BR>> >>>><BR>> >>>> If I define ROOT then I get the following error. I think this all <BR>> >>>> needs reverting!<BR>> >>>><BR>> >>>> --- building in SOLgnu ---<BR>> >>>><BR>> >>>> ignoring ../src/m3overrides<BR>> >>>><BR>> >>>> "/.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/m3makefile", line <BR>> >>>> 12: quake runtime error: unable to copy <BR>> >>>> "~/cm3/m3-libs/m3core/src/ unix/Common/UnixLink.c" to <BR>> >>>> "./UnixLink.c": errno=2<BR>> >>>><BR>> >>>> --procedure-- -line- -file---<BR>> >>>> cp_if --<BR>> >>>> include_dir 12 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/src/ m3makefile<BR>> >>>> 6 /.gollum/u110/u86/hosking/cm3/m3-sys/cm3/SOLgnu/m3make.args<BR>> >>>><BR>> >>>> Fatal Error: package build failed<BR>> >>>> n<BR>> >>>><BR>> >>>> On 2 Jul 2009, at 11:49, Tony Hosking wrote:<BR>> >>>><BR>> >>>> Where did variable ROOT come from? Do I really need to define it? <BR>> >>>> Seems broken to me to depend on the source directory structure <BR>> >>>> as it sets that structure in stone.<BR>> >>>><BR>> >>>><BR>> <BR>> <BR>> <BR>> -- <BR>> Olaf Wagner -- elego Software Solutions GmbH<BR>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<BR>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<BR>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<BR>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR>> <BR></body>
</html>