fix 64-bit UNIX source for the Win64 environment 



clean64 [-C] [-c] [-Dname[=value]] [-e epsym] [-E] [-g] [-Idirectory] [-llibrary] [-Ldirectory] [-M] [-m] [-O] [-o output] [-P] [-S] [-s] [-static] [-U symname] [-u symname] [-VS num] [-Woption] [-Xc] [-x] files...


The clean64 utility is used to automatically massage source code and header files and replace instances of the long datatype with intptr_t, and replace instances of unsigned long with uintptr_t. This is done to assist in those cases where 64-bit clean UNIX code is being ported to Win64, and in cases where on UNIX systems it was important that sizeof(long) == sizeof(pointer).

If source code modifications take place, the original file is renamed with a .orig extension appended to the file name, and the new modified file is written in its place. System header files that are found by searching paths specified by the INCLUDE environment variable are assumed to be already correct for the Win64 platform, and are excluded from modification. Finally, the source file is compiled in the same manner as would happen had you used the cc utility in the development environment designed for use with the MKS Toolkit UNIX APIs. All of the command line arguments to clean64 are in fact used for the purposes of compilation of the file. Given that the clean64 utility functions like the cc utility, it is frequently sufficient to simply issue the command:

make CC=clean64

to compile a source tree with the clean64 utility. When source code modifications are made, the clean64 utility does not attempt to make sure that the intptr_t and uintptr_t datatypes are already defined. You may need to manually insert #include <inttypes.h> in your source code or one of your header files for compilation to proceed. The recommended usage of this tool is to essentially use it once at the start of the porting process. Any source code modifications that were made by clean64 can then be reviewed and those that are relevant can then be checked into your configuration management system.

The intptr_t and uintptr_t datatypes are also defined on all modern UNIX systems, so any such changes will most likely not need to be considered platform-specific.

You do not need to use the clean64 utility to process code to be compiled for the 64-bit Windows platform. There are other strategies for finding the places where sizeof(long) is important—this is simply one option that can be used, and in general is the most effective option for situations where the use of the long datatype to hold pointer sized objects is pervasive throughout your source code. It may be the case that no source code changes are required to build an application for 64-bit Windows. Hence, it is recommended that the initial step in porting to this platform is to first assess your source code to determine the scope of the problem before using tools such as clean64.



passes comments through to preprocessor output.


compiles only — does not link.


defines a preprocessor symbol with an optional value.


sends all preprocessor output to standard output.

-e epsym 

sets entry point (passed through to linker).


produces debugging information in the compiled object modules.


adds directory to the beginning of the list of directories to be searched for include files (the value of the %Include% environment variable). Any directories supplied on the command line are searched first, in the order in which they appear on the command line.

-L directory 

if linking, adds the directory to the beginning of the list of directories that the linker searches for libraries (the value of the %Lib% environment variable). Any directories supplied on the command line are searched first, in the order in which they appear on the command line.

This option is passed through to the linker.


if linking, adds the specified library to the list of libraries to be searched. In searching for libraries (for example, with -lfoo), each library directory is first searched for the UNIX-style archive name (that is, libfoo.a) and then for the Windows-style library name (that is, foo.lib).


complains about multiply defined symbols.


produces a link map.


instructs the compiler to generate optimized code.

-o output 

specifies the name of the output file generated by the linker.


stores preprocessor output to a file, where the file name is obtained by replacing the .c (or .cpp) extension with .i.


produces an assembly code listing.


when linking, strips debugging information from the output file.


requests linking against the static C++ runtime libraries. This is not recommended.

-u symname 

when linking, adds an undefined reference to symname.

-U symname 

undefines the specified preprocessor symbol.

-VS num 

passes through to the /VERSION linker option.


forces C++ linking.


selects verbose mode.


specifies an option that is to be passed either to the C compiler or to linker with the leading -W removed. The options — subsystem, def, base, entry, implib, machine, map, out, stack, and dll — are passed to the linker; all others are passed to the compiler.


when linking, strips debugging information related to local symbols from the output file.


compiles with strict ANSI C conformance. Only symbols specified by the ANSI C specification are visible during compilation.


Possible exit status values are:


Successful completion.


An error occurred.



PTC MKS Toolkit for Professional Developers
PTC MKS Toolkit for Professional Developers 64-Bit Edition
PTC MKS Toolkit for Enterprise Developers
PTC MKS Toolkit for Enterprise Developers 64-Bit Edition


cc, ld

PTC MKS Toolkit 10.4 Documentation Build 39.