MOE(1) User Commands MOE(1)


moe - manifest the optimal expansion of a pathname


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

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 current platform.

moe analyzes a pathname by passing the supplied path to dlmopen(3C),
together with the RTLD_FIRST flag. Reserved token expansion is therefore
carried out by 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

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 Linker and Libraries Guide.


The following options are supported:

Only analyze 32-bit objects.

Only analyze 64-bit objects.

Prefix each pathname with the class of the object.

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

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:

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'

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/

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/'
64-bit: /opt/ISV/sparcv9/

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/'
32-bit: /opt/ISV/sparcv9/ 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(7) for descriptions of the following attributes:

|Interface Stability | Stable |


isalist(1),, optisa(1), dlmopen(3C), attributes(7)

Linker and Libraries Guide

February 2, 2005 MOE(1)