1moe(1)                           User Commands                          moe(1)
2
3
4

NAME

6       moe - manifest the optimal expansion of a pathname
7

SYNOPSIS

9       moe [-c] [-32 | -64] [-s | -v] path
10
11

DESCRIPTION

13       The  moe utility manifests the optimal expansion of a pathname contain‐
14       ing reserved runtime linker tokens. These tokens can be used to  define
15       dependencies,  filtees  and runpaths within dynamic objects. The expan‐
16       sion of these tokens at runtime,  provides  a  flexible  mechanism  for
17       selecting  objects  and search paths that perform best on this machine.
18       See ld.so.1(1).
19
20
21       For example, the token $HWCAP can be employed to represent filters  and
22       dependencies.  The runtime interpretation of this token can result in a
23       family of objects that are analyzed to  determine  their  applicability
24       for  loading  with a process. The objects are sorted based on the hard‐
25       ware capabilities that each object requires to execute. moe returns the
26       name  of the object optimally suited for execution on the current plat‐
27       form.
28
29
30       moe analyzes a pathname by passing the supplied  path  to  dlmopen(3C),
31       together  with  the RTLD_FIRST flag. Reserved token expansion is there‐
32       fore carried out by ld.so.1 as the expansion would occur in an  execut‐
33       ing  process.  Although multiple objects can be analyzed as a result of
34       the dlmopen() call, the RTLD_FIRST flag insures only the optimal object
35       is processed.
36
37
38       By  default,  moe analyzes the specified path twice. The first analysis
39       looks for 32-bit objects. The second analysis, if applicable, looks for
40       64-bit  objects.  Typically, 32-bit objects and 64-bit objects are iso‐
41       lated to different directories. These directories are frequently  named
42       to  reflect  the  class  of object the directory contains. The multiple
43       passes of moe catch any  instances  where  32-bit  objects  and  64-bit
44       objects  occupy the same directory. Multiple passes also provide flexi‐
45       bility when the pathname that is specified does not convey to the  user
46       the class of object the directory might contain.
47
48
49       For  a complete description of the reserved token expansion carried out
50       by the runtime linker, refer to the Linker and Libraries Guide.
51

OPTIONS

53       The following options are supported:
54
55       -32    Only analyze 32-bit objects.
56
57
58       -64    Only analyze 64-bit objects.
59
60
61       -c     Prefix each pathname with the class of the object.
62
63
64       -s     Silent. No optimal name, or  error  diagnostics  are  displayed.
65              Only  an  error  return  is  made available. This option is only
66              meaningful with the -32 and -64 options. The -s option  can  not
67              be used with the -v option.
68
69
70       -v     Verbose.  If  no  optimal  expansion  name can be determined, an
71              error diagnostic is written to standard error. The -v option can
72              not be used with the -s option.
73
74

OPERANDS

76       The following operand is supported:
77
78       path    The pathname to be expanded.
79
80

EXAMPLES

82       The  following  example  uses  moe  to display the optimal expansion of
83       objects in the directory /usr/lib/libc. This directory contains a  fam‐
84       ily  of  Intel objects that are built to use various hardware capabili‐
85       ties.
86
87         % moe '/usr/lib/libc/$HWCAP'
88         /usr/lib/libc/libc_hwcap.so.1
89
90
91
92
93       The -c option can be used to clarify the class of the optimal object.
94
95         % moe -c '/usr/lib/libc/$HWCAP'
96         32-bit: /usr/lib/libc/libc_hwcap.so.1
97
98
99
100
101       The following example uses moe to  display  the  optimal  expansion  of
102       objects  under  the /opt/ISV/cpu directory hierarchy. These directories
103       contain a family of SPARC objects that are built for various platforms.
104
105         % moe -c -64 '/opt/ISV/$ISALIST/isa.so.1'
106         64-bit: /opt/ISV/sparcv9/isa.so.1
107
108
109
110
111       The -v can be used to diagnose the instance where an  optimal  name  is
112       not  returned.  An attempt to inspect the previous pathname as a 32-bit
113       object, would result in the following diagnostic being produced.
114
115         % moe -c -v -32 '/opt/ISV/$ISALIST/isa.so.1'
116         32-bit: /opt/ISV/sparcv9/isa.so.1: wrong ELF class: ELFCLASS64
117
118
119

EXIT STATUS

121       When the -32 or -64 options are in effect, a successful optimal  expan‐
122       sion  returns  0, otherwise non-zero. Without the -32 or -64 options in
123       effect, the return value is always 0.
124

ATTRIBUTES

126       See attributes(5) for descriptions of the following attributes:
127
128
129
130
131       ┌─────────────────────────────┬─────────────────────────────┐
132       │      ATTRIBUTE TYPE         │      ATTRIBUTE VALUE        │
133       ├─────────────────────────────┼─────────────────────────────┤
134       │Availability                 │SUNWcsu                      │
135       ├─────────────────────────────┼─────────────────────────────┤
136       │Interface Stability          │Stable                       │
137       └─────────────────────────────┴─────────────────────────────┘
138

SEE ALSO

140       ld.so.1(1), optisa(1), isalist(1), dlmopen(3C), attributes(5)
141
142
143       Linker and Libraries Guide
144
145
146
147SunOS 5.11                        2 Feb 2005                            moe(1)
Impressum