moe(1)																	    moe(1)

NAME

       moe - manifest the optimal expansion of a pathname

SYNOPSIS

       moe [-c] [-32 | -64] [-s | -v] path

       The moe utility manifests the optimal expansion of a pathname containing reserved runtime linker tokens. These tokens can be used to define
       dependencies, filtees and runpaths within dynamic objects. The expansion of these tokens at runtime,  provides  a  flexible  mechanism  for
       selecting objects and search paths that perform best on this machine. See ld.so.1(1).

       For example, the token $HWCAP can be employed to represent filters and dependencies. The runtime interpretation of this token can result in
       a family of objects that are analyzed to determine their applicability for loading with a process. The objects  are  sorted  based  on  the
       hardware  capabilities  that each object requires to execute. moe returns the name of the object optimally suited for execution on the cur-
       rent platform.

       moe analyzes a pathname by passing the supplied path to dlmopen(3C), together with the RTLD_FIRST flag. Reserved token expansion is  there-
       fore  carried out by ld.so.1 as the expansion would occur in an executing process. Although multiple objects can be analyzed as a result of
       the dlmopen() call, the RTLD_FIRST flag insures only the optimal object is processed.

       By default, moe analyzes the specified path twice. The first analysis looks for 32-bit objects. The second analysis, if	applicable,  looks
       for  64-bit  objects.  Typically, 32-bit objects and 64-bit objects are isolated to different directories. These directories are frequently
       named to reflect the class of object the directory contains. The multiple passes of moe catch any instances where 32-bit objects and 64-bit
       objects occupy the same directory. Multiple passes also provide flexibility when the pathname that is specified does not convey to the user
       the class of object the directory might contain.

       For a complete description of the reserved token expansion carried out by the runtime linker, refer to the .

       The following options are supported:

       -32	Only analyze 32-bit objects.

       -64	Only analyze 64-bit objects.

       -c	Prefix each pathname with the class of the object.

       -s	Silent. No optimal name, or error diagnostics are displayed. Only an error return is made available. This option is only  meaning-
		ful with the -32 and -64 options. The -s option can not be used with the -v option.

       -v	Verbose.  If  no optimal expansion name can be determined, an error diagnostic is written to standard error. The -v option can not
		be used with the -s option.

       The following operand is supported:

       path	The pathname to be expanded.

       The following example uses moe to display the optimal expansion of objects in the directory /usr/lib/libc. This directory contains a family
       of Intel objects that are built to use various hardware capabilities.

       % moe '/usr/lib/libc/$HWCAP'
       /usr/lib/libc/libc_hwcap.so.1

       The -c option can be used to clarify the class of the optimal object.

       % moe -c '/usr/lib/libc/$HWCAP'
       32-bit: /usr/lib/libc/libc_hwcap.so.1

       The  following  example	uses moe to display the optimal expansion of objects under the /opt/ISV/cpu directory hierarchy. These directories
       contain a family of SPARC objects that are built for various platforms.

       % moe -c -64 '/opt/ISV/$ISALIST/isa.so.1'
       64-bit: /opt/ISV/sparcv9/isa.so.1

       The -v can be used to diagnose the instance where an optimal name is not returned. An attempt to inspect the previous pathname as a  32-bit
       object, would result in the following diagnostic being produced.

       % moe -c -v -32 '/opt/ISV/$ISALIST/isa.so.1'
       32-bit: /opt/ISV/sparcv9/isa.so.1: wrong ELF class: ELFCLASS64

       When  the -32 or -64 options are in effect, a successful optimal expansion returns 0, otherwise non-zero. Without the -32 or -64 options in
       effect, the return value is always 0.

       See attributes(5) for descriptions of the following attributes:

       +-----------------------------+-----------------------------+
       |      ATTRIBUTE TYPE	     |	    ATTRIBUTE VALUE	   |
       +-----------------------------+-----------------------------+
       |Availability		     |SUNWcsu			   |
       +-----------------------------+-----------------------------+
       |Interface Stability	     |Stable			   |
       +-----------------------------+-----------------------------+

       ld.so.1(1), optisa(1), isalist(1), dlmopen(3C), attributes(5)

								    2 Feb 2005								    moe(1)