J.2 Building

1. Why does the Makefile assume that I am building mpatrol on platform X when I am really building on platform Y?

   The src/config.h and src/target.h header files attempt to obtain as much information from the compiler as possible, mainly from any predefined preprocessor macros that it defines during compilation. If this information is incorrect then you can override the TARGET, SYSTEM, ARCH, ENVIRON, FORMAT and DYNLINK preprocessor macros defined in src/target.h to suit your particular system by explicitly defining them in CFLAGS within the Makefile when you build mpatrol. You could also choose to build different versions of mpatrol with different settings of ENVIRON, FORMAT or DYNLINK on a single system if you wish to by changing ENVIRON, FORMAT or DYNLINK for different builds.

2. The processor family I am compiling on supports both 32-bit and 64-bit modes of operation. How do I specify which I want?

   You will have to look at the documentation for the compiler you are using in order to find out how to specify which operating environment you wish to target. For example, if you are using the Sun C compiler on a SPARC V9 Solaris machine then you should specify the -xarch=v9 option in the Makefile when you are building mpatrol in order to target the 64-bit environment. If you think that you are already using the correct option, but the mpatrol code is still being built to support the wrong environment then you could try explicitly setting the ENVIRON preprocessor macro in the Makefile.

3. I cannot include mpatrol.h from my C++ source code as I get lots of compilation errors. Why is this and what can I do to prevent them?

   The most likely reason that you are getting errors is because you are calling placement new, and the way that mpatrol derives source information from calls to operator new is by defining a macro called new, thus causing lots of problems when calling placement new or explicitly calling operator new. You can either try not to use placement new or you can define the preprocessor macro MP_NOCPLUSPLUS when compiling your source file, which will disable the overriding of any C++ operators in mpatrol.h. Alternatively, if you define MP_NONEWDELETE then you can use MP_NEW, MP_NEW_NOTHROW and MP_DELETE in order to call the mpatrol versions of the C++ operators.

4. I still have the above problem, but I don't think it's due to placement new since the compiler complains about operator new[], so could that be a clue?

   Yes. The most likely reason is that the C++ compiler does not support the array new and delete operators. These were introduced some time before the standardisation of the C++ language but some compilers may not yet have support for them. It may be that you have to use a special compiler option to enable support for these operators, but if not you will probably have to edit mpatrol.h to temporarily allow your files to compile.

5. I tried both of the above suggestions, but I still can't get my C++ source code to compile. I'm using an old C++ compiler so could that be a problem?

   Yes. The mpatrol.h header file defines new versions of the C++ dynamic memory allocation operators using exceptions and namespaces as required by the ANSI C++ standard. If your C++ compiler has no support for these then you should compile your C++ source files with MP_NOCPLUSPLUS defined. You may also be using an older C++ library in which the new header file does not define set_new_handler() to be in the std namespace. You will then have to change the mpatrol.h header file and cplus.c source file accordingly.

6. I'm calling operator new (not the nothrow version) from my C++ source code but when my program runs out of memory the `OUTMEM' error is given in the mpatrol log file rather than throwing a std::bad_alloc exception. Why is this?

   Sounds like the mpatrol library was built with a C compiler. In order for the mpatrol versions of operator new and operator new[] to throw an exception when they run out of memory, the mpatrol library must have been built with a C++ compiler. The `OUTMEM' error is only given when there is no way to throw an exception.

7. Why am I unable to call the mpatrol version of alloca()? I only ever seem to call the default version.

   Most implementations of the alloca() function are compiler builtins which will be converted to inline assembler or object code in order for them to be able to dynamically modify the calling function's stack frame at run-time. As a result, the call to alloca() is recognised as an intrinsic keyword and is dealt with specially by the compiler. However, if this can be intercepted by the preprocessor before the compiler parses the source code then the call can be redirected to another function. This is one of the functions of the mpatrol.h header file, which means that it must be included before the first call the alloca(). If alloca.h is also being included then mpatrol.h must be included after it, otherwise it may redefine alloca() back to the default version.

8. Why do some of the Makefiles contain the -fno-inline-functions option as part of OFLAGS?

   The -fno-inline-functions option is a gcc-specific option which instructs the compiler not to inline any functions. This is necessary on some platforms where function call stack traversal is supported, since function inlining may significantly alter the layout of a program's stack. Normally this option is only required when building the mpatrol library, but on some platforms function call stack traversal may not work properly unless this option (or equivalent) is used for all compiled code.

9. What does the MP_ALIGN definition in mpatrol.h do?

   It is a preprocessor macro function that is used to return the minimum alignment in bytes required for a specified type at compile-time. It is used in the MP_MALLOC family of functions to specify the required alignment of the memory allocation that is to be used to store the specified type. Some compilers provide a built-in function that can be used to determine the minimum alignment of a type at compile-time. For all others, this macro makes use of some structure trickery in combination with the offsetof macro.

10. What does the MP_INLINE definition in mpatrol.h do?

    It is used in the definition of the debugging versions of the C++ operators in mpatrol.h so that they are inlined correctly. We want to define the C++ operators so that they will be inlined in every source file that uses them and also not clash with the versions defined in the mpatrol library or the standard C++ library. Traditionally, this is done by defining them to be static inline, which means that any non-inlined definition will be local to each object file. An even better technique is available with the new C++ standard which allows extern inline definitions, meaning that no definition will be available if the function is not inlined. Unfortunately, if optimisation is turned off in the compiler then no inlining will usually be performed and so the definitions will be real functions. Luckily, on ELF platforms the extern inline function definition will have a weak visibility and so will not clash with library functions.

11. Why do I get different stack traces in the mpatrol log file from the C++ operators in mpatrol.h when optimisation is turned on and off in the compiler?

    When the compiler is optimising it will invariably be performing inlining, in which case each inlined function will share the stack frame of its caller when it is called — the mpatrol library cannot detect this. In order to cope in both situations, the non-inlined case will contain the name of the C++ operator at the top of its stack, even though it will be removed in the inlined case.

12. How do I build the mptrace command with GUI support?

    The GUI support for the mptrace command is currently written to use Motif and X Windows and so can only be built on systems with these libraries and run on systems with an X server. This will most likely be possible only on UNIX platforms. LessTif can be used instead of Motif if that is all that is available on your system. The UNIX Makefile has a macro called GUISUP which can be set to true or false depending on whether you wish to have GUI support or not. The default is false. GUI support is automatically enabled on platforms that support it if the configure script in pkg/auto is used.

13. How do I build the mptrace command without GUI support?

    This is done by default on most platforms when using the Makefiles in the build directory. However, if for some reason that is not the case then on UNIX platforms you will have to set the GUISUP Makefile macro to false when compiling mptrace. You might need to do this if your UNIX system does not have the correct header files and libraries installed needed for GUI support. If you are using the configure script in pkg/auto then GUI support will be automatically disabled on platforms that do not support it, but you can force it to be disabled by using the --without-x option.