Note: I'm moving this conversation over to tools-linking at opensolaris.org.
To follow up, please use tools-linking and drop opensolaris-discuss.
Holger Berger wrote:
> On 4/30/06, Rod Evans <Rod.Evans at sun.com> wrote:
>
>> The colon has been the standard separator of multiple pathnames within
>> the link-editing environment since Solaris 2.0 (it was even used in
>> Solaris 1 (4.x) if I recall).
>
>
> Is there a way to override, replace or escape the ':' separator?
Presently, no. But it seems like a mechanism to allow ':' within
a path is now desirable.
I've a couple of thoughts. First, if you wish to allow ':' within
a dlopen() path, would you also want to allow this character in
a RUNPATH, LD_LIBRARY_PATH, or some other ld.so.1 processed path?
We could invent an escape character that can be embedded in a path.
This provides generic flexibility, but in the case of dlopen()
might require the user to translate a string (read from some config
file?) to include the escape character.
Or, we could allow dlopen() path processing to differ/be-more-flexible
than other path processing. We could force a dlopen() string to be
used as-is. This changes todays behavior, and would break the example
I had cited below. But, would anyone care? Or we could be explicit
in regards our new requirement:
dlopen("foo:bar", RTLD_LAZY | RTLD_FULLPATH)
and use a new token to define a path should be used as is.
Thoughts?
Rod Evans wrote:
> The following conversation occurred recently on opensolaris-discuss.
> I've replicated the conversation on this alias so the we can continue to
> explore ideas with a more appropriate focal group.
>
> > Rod Evans wrote:
> >
> > > Robert Lunnon wrote:
> > >
> > > Wine now uses softlinks named x: (where x is the device name
> > > to link to) placed in the filesystem. Wine preserved the
> > > Windows naming including the colon in the link name.
> > > Unfortunately ld.so.1 doesn't seem to be able to load a
> > > library across these links being confused by the colon in the
> > > name for the moment I have changes in the wine codebase to
> > > resolve the path of the library before loading it, but I'm
> > > inclined to think it is the behaviour of ld.so that is wrong.
> >
> > The link-editors can process path name information in a number
> > of forms. Each form allows multiple paths to be expressed as a
> > series of individual paths separated by a colon:
> >
> > LD_AUDIT, LD_AUDIT_32, and LD_AUDIT_64
> >
> > A colon-separated list of objects that are loaded by the
> > runtime linker. ....
> >
> > LD_LIBRARY_PATH, LD_LIBRARY_PATH_32, and LD_LIBRARY_PATH_64
> >
> > ......... specifies a colon-separated list of directories
> > that are searched before the default directories.
> >
> > -R path
> >
> > A colon-separated list of directories used to specify
> > library search directories to the runtime linker.
> >
> > -Y P,dirlist
> >
> > Changes the default directories used for finding
> > libraries. dirlist is a colon-separated path list.
> >
> > The colon has been the standard separator of multiple pathnames
> > within the link-editing environment since Solaris 2.0 (it was even
> > used in Solaris 1 (4.x) if I recall).
>
>
> > Rod Evans wrote:
> >
> > > > Robert Lunnon wrote:
> > > >
> > > > In short you cannot dlopen a library with a : in the pathname
> > >
> > > Casper Dik wrote:
> > >
> > > That seems like a bug.
> >
> > Perhaps, but the intent has been to make all pathname processing
> > within ld.so.1 consistent. FILTERS, RUNPATHS, LD_LIBRARY_PATH,
> > dependencies, in fact, all pathnames are funneled through the same
> > engine, where tokens are expanded ($ORIGIN, $HWCAP, etc), and
> > multiple pathnames separated.
> >
> > For example, you can use a token that can expand into multiple
> > pathnames:
> >
> > #include <dlfcn.h>
> >
> > main()
> > {
> > dlopen("$ISALIST/foo.so", RTLD_FIRST | RTLD_LAZY);
> > }
> > % LD_DEBUG=files,libs ./main
> > .....
> > 01488: 1: file=$ISALIST/foo.so; dlopen() \
> > called from file=main [ RTLD_LAZY RTLD_LOCAL ... RTLD_FIRST ]
> > 01488: 1: trying path=amd64/foo.so
> > 01488: 1: trying path=pentium_pro+mmx/foo.so
> > 01488: 1: trying path=pentium_pro/foo.so
> > .....
> >
> > Effectively, the ISALIST token results in a ":" separated series
> > of pathnames, which are then processed one by one.
> >
> > Similarly, you can hardcode the lookup yourself:
> >
> > #include <dlfcn.h>
> >
> > main()
> > {
> > dlopen("amd64/foo.so:pentium_pro+mmx/foo.so:pentium_pro/foo.so",
> > RTLD_FIRST | RTLD_LAZY);
> > }
> > % LD_DEBUG=files,libs ./main
> > .....
> > 01489: 1:
> file=amd64/foo.so:pentium_pro+mmx/foo.so:pentium_pro/foo.so; \
> > dlopen() called from file=main [ RTLD_LAZY RTLD_LOCAL ...
> RTLD_FIRST ]
> > 01489: 1: trying path=amd64/foo.so
> > 01489: 1: trying path=pentium_pro+mmx/foo.so
> > 01489: 1: trying path=pentium_pro/foo.so
> > .....
> >
> > Granted, the last scenario hasn't been widely advertised, and you
> > could achieve this, or the ISALIST scenario, by making a family of
> > individual dlopen() calls. But the consistency of pathname
> > processing, for all pathnames used by ld.so.1, is intentional -
> > whether everything has fallen out to be as intuitive as we'd hoped ...
> >
> > If a colon is required as part of a pathname, then perhaps it
> > should be available in any pathname processes by ld.so.1. Either
> > we need a way of specifying an alternative pathname specifier, and
> > simply escaping a ":", or something else ....
>
--
Rod.
