preprpl[32|64] -x <file> -o <file> -l <file> -r <rpl-name> \ [-log <file>] [-v] [@<file>] preprpl[32|64] [-o <file>] [-log <file>;] [-x <file>] \ [-xall] [-xnot <file>] [-v] [@<file>;] [<file> ...]
||Specify the output
||Specify the output
||Specify the name of the final RPL/RPX.|
||Search file in path.|
||Emit a text log to the specified file.|
||Export symbols specified in
||Export all global non-weak loadable symbols. Not recommended; use
||Exclude symbols specified in
||Do not generate library header.|
List of object files which are also passed to the linker. Optional
||Deprecated. Pass this option to
||When passed, static initializers are allowed as exports with warning. Default: attempt to export a static initializer is an error.|
||When passed, symbols in linkonce sections are allowed as exports with warning. Default: attempt to export a linkonce symbol is an error.|
This Windows tool is provided in two flavors:
32-bit and 64-bit operating systems, respectively.
preprpl[32|64] is called before linking. It generates an object (
which must then be passed to the linker.
preprpl[32|64] can generate an import library (
.a) to which
other modules can link.
preprpl[32|64] streamlines the build process
by generating the export object file (
.o) and the import library file (
from an export definition file (via the “
-x <file>” option).
The “pre-v1.0” method of invoking
preprpl[32|64] with the same file list that is
provided to the linker is still supported. In this mode, all application object files and
system object files (such as
mtx.a, etc) must be
preprpl[32|64]have been modified to exclude static initializers and linkonce symbols because these symbols can cause problems if they are exported. You can read more information about linkonce symbols in the GHS documentation (see
$GHS_ROOT/manuals/build_ppc.pdf). Static initializers are a problem because static initializers from a RPL will become imported if any other symbol from that RPL is imported. This could cause the static initializer to be recalled for every RPL that imports the static initializer.
exports.deffile and pass one or both of the new
preprpl[32|64]options to allow them to be added to your RPL's exports (
-warnlinkonce). However, we consider that these new options should only be used as a last resort.
Examplemakedemo package. The package demonstrates various aspects of the build system, including the latest RPL tool enhancements. The version of
Examplemakeincluded in the SDK is compatible with the current SDK. For comparison with older SDK versions, obtain the
Examplemakepackage from your local Nintendo developer support group.
When building RPX and RPL files, you export the symbols that other modules wish to access.
Examplemake demo program
In this example, the primary application
hello.rpx is loaded first.
The application implicitly loads (or “acquires”) the RPL
All modules export symbols. The exported symbols are specified in the
world.def export definition files.
The build process for each component invokes
preprpl[32|64] before linking,
and generates a
.o file and a
.o file contains exported symbol information, making the symbols accessible
to other RPX and RPL modules. The
.a file contains import symbol information,
used by other RPX and RPL modules to reference the exported symbols.
-x <file> option can be used with the
-l <rpl_name.a> arguments to generate an export object
and an import library
.a. By this method,
not require any object files.
This is the method used in the
world.def files in the demo for more information.
The default file extension for the
<file> argument is
C++ code is at a disadvantage in this scenario, given the mangling of symbols
at link-time. The
rplexportall script generates an export definition
.def) from a list of object files. This generated file can be edited
and then passed to
preprpl[32|64]. For example:
$ rplexportall hello.o
; Generated Export List [CODE] main ; main rpx_gethello ; rpx_gethello [DATA] hello ; hello
-x <file> option will only export symbols listed in the
specified text file. This is the method used in the
For information, see the
world.def files in the demo.
-xall option will export all global, non-weak symbols from
.o files. While not generally useful, this method may be the
most viable for C++ applications given the mangling of symbol names at link-time.
-xnot <file> option will exclude the symbols listed in
the specified text file.
If you use the
-xall option for an RPX, you may inadvertently export a
symbol that conflicts with a symbol from an RPL. To resolve this, you can exclude the
conflicting symbol using
-xnot <file> for the RPX.
If you discover that you have a static initializer in your exports file, you can safely remove it if you have not released your module and if every other module that has used your module can be rebuilt. If that is incorrect, then you can occasionally neutralize potential problems with this technique:
__sti___10_foobar_cpp_f5d9abb2. This static initializer is in the source file
foobar.cpp. Also, all of the characters are legal C language characters.
foobar_fixed.cpp. This will rename your static initializer; make sure it does not get exported.
phony_initializer.c. Make it C to avoid warnings from MULTI if you use C++.
extern "C"function with the old static initializer name and have it do nothing.
phony_initializer.cand will not reinitialize your class objects.
Exporting and importing symbols simultaneously between two modules is supported. For more information, see the notes on RPX/RPL Cross-Referencing.
Examplemake demo program
helloworld_rpl illustrates how
to create RPX and RPL modules using
preprpl[32|64]. For convenience,
we will use the definitions below to describe the various parameters for building
To create an RPX, the tool is used like this:
$(CAFE_TOOL_DIR)/preprpl64 -x hello.def -r hello.rpx -l hello.a -o hello_rpl_export.o
To create an RPL:
$(CAFE_TOOL_DIR)/preprpl64 -x world.def -r world.rpl -l world.a -o hello_rpl_export.o
There are no major differences between the preparation of an RPX versus an RPL.
2013/12/13 New exclusions from
2013/05/08 Automated cleanup pass.
2012/07/23 Removed references to old SDKs. Updated Examplemake references.
2011/10/19 Examplemake addition.
2011/02/21 Initial version.