On Fri, 22 Sep 2006 17:05:47 +0100 Darren J Moffat wrote:
> I think my comments are on the border line between architecture review 
> and design or code review, the only reason I'm asking is the $PATH issues.

> Glenn Fowler wrote:
> > the upshot is that, on solaris, ksh first looks for plugins for the
> > "ksh" application, so the "ksh" "cmd" plugin, with solaris physical name
> > "libcmd.so[optional-version]", could reside in
> >     ../lib/ksh/libcmd.so[optional-version]
> > somewhere on $PATH and

> Do you really mean $PATH ?  If so that seems a bit strange since if I 
> understand correctly you are dlopen()ing this so if any variables are 
> used I would have expected them to be the $LD_* ones which you shouldn't 
> interpret yourself but let ld.so.1 do for you.

yes, $PATH
in general all ast PATH style lookups are done using $PATH relative dir lookup
e.g., ../lib/foo on $PATH
this greatly reduces the number of env var preprequites, typically down
to just PATH being set correctly, instead of

        export FIND_MAGIC_FILE_DIR=...
        export NMAKE_RULES_DIR=...
        export PAX_PLUGIN_DIR=...
        export KSH_FUNCTION_DIR=...
        ...

since plugins are in a possibly different namespace from LD_*, and if PATH
points to the correct executables, using ../lib etc. off of PATH leads to
less mismatched plugin searches -- it puts the onus on the installer to
keep binaries and associated plugins installed together in the same
relative hierarchy, e.g.,

        /foo/bin/ksh
        /foo/lib/ksh/libcmd.so.1.2

> >     builtin -f cmd
> > will find the first one with the newest version (or with specific version
> > constraints depending on how ksh coded the load plugin call)

> Does the code explicitly look for libcmd.so.1 libcmd.so.2 etc or does it 
> just assume that libcmd.so is the most recent ?  In the general case 
> multiple copies of the same library at a different "version" don't 
> actually work very well (it is a very complex problem area and has all 
> sorts of nasty interactions but in this simple case it might be okay).

the code looks for shared lib / dll names using local naming and versioning
conventions; the plugin caller can bias towards a specific version, or
absent a preference the name sans version is checked first, and then the
latest version

the version lookup is supported but not encouraged
we usually go through great pains to preserve at least backwards compatibility 
so that old programs will work with the latest plugins

-- Glenn Fowler -- AT&T Research, Florham Park NJ --


Reply via email to