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.
