**************************************************************************** BUILD NOTES FOR SAMRAI-v2.1.0 on Mac OS X (10.3.9 and 10.4) Compilers: GCC 3 + (xlf|g77) Kevin T. Chu (MAE, Princeton University) Daniel Thorpe (University of Southampton) 2006/04/01 **************************************************************************** ----------------------------------------------------------------------------- - Problem: Mac OS X installs malloc.h in a slightly unusual location (/usr/include/malloc/malloc.h) Fix (temporary): (1) Add the absolute path to malloc.h to the MemoryUtilities.C (2) Alternatively, added /usr/include/malloc to CPATH environment variable to add it to the standard search path used by GCC to find header files. (3) (due to Brian Taylor) Create the following symbolic link after running the configure script but before building the library: ln -s /usr/include/malloc/malloc.h ../SAMRAI/include/malloc.h Fix (permanent): Modify configure script to check if /usr/include/malloc needs to be added to the include path. ----------------------------------------------------------------------------- ----------------------------------------------------------------------------- - Problem: mallinfo structure is not defined on Mac OS X platform. Fix: added "#ifdef HAVE_TAU" wrapper to MemoryUtilties::printMemoryInfo(). (line 63 of toolbox/memory/MemoryUtilities.C) ----------------------------------------------------------------------------- ----------------------------------------------------------------------------- - Problem: Mac OS X is case insensitive, so SAMRAI's MPI.h gets mixed up with the MPI header file mpi.h Fix (temporary): use the full path for the MPI header file Fix (permanent): rename SAMRAI's MPI.h to avoid the naming conflict ----------------------------------------------------------------------------- ---------------------------------------------------------------------------- - Problem: ISO C++ standard does not include isnan() in . Fix: Explicitly access api functions __isnan() and __isnand() in toolbox/base/IEEE.C and toolbox/templates/special/MathUtilitiesSpecial.C For float version, added the following lines: ========================================================== #if defined(__GNUC__) && (__GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 2)) int i = __isnan(f); #else int i = isnan(f); #endif ========================================================== For double version, added the following lines: ========================================================== #if defined(__GNUC__) && (__GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 2)) int i = __isnan(d); #else int i = isnan(d); #endif ========================================================== Note: Paul Henning's fix doesn't seem to work for GCC 3.3 on Mac OS X 10.3.9 ----------------------------------------------------------------------------- ----------------------------------------------------------------------------- - Problem: Configure process explicitly specifies system libraries causing confusion for the linker. Fix (temporary): Post-processing of config/Makefile.config to remove offending libraries. Unfortunately, Paul Henning's fix only takes care of the problem when the configure script determines the fortran libraries. If the libraries for other software packages are not explicitly specified (e.g. MPI), then we get the same problem anyways. Fix (permanent): fix the configure script to check for the Mac OS X architecture (darwin) and strip out the offending libraries. ----------------------------------------------------------------------------- ----------------------------------------------------------------------------- - Problem: 'make install' does not work ... it just returns comment "make: `install' is up to date." The reason for this is that the file system on Mac OS X is not case sensitive, so the make system gets "install" mixed-up with the file "INSTALL" Fix: changed the name of install target in the Makefile after running the configure script. ----------------------------------------------------------------------------- ----------------------------------------------------------------------------- - Problem: Special considerations for IBM xlf compiler. (1) Need to add -qextname to FFLAGS_EXTRAS so that the compiler extends procedure names with an additional underscore. Or change the configure script to correctly handle the Fortran name mangling with xlf. (2) Need to use "--with-fortran-libs=-lxlfmath" to correctly pick up the math library functions during the link stage. For some reason, there is an error when trying to link in the dynamic math library: libxlfmath.dylib ----------------------------------------------------------------------------- ----------------------------------------------------------------------------- - Problem: Inclusion of MPICH libraries is out of order (-lpmpich -lmpich) Fix (temporary): manually fix order after the configure script is run Fix (permanent): fix the configure script to make sure that the libraries are linked in the correct order ----------------------------------------------------------------------------- ----------------------------------------------------------------------------- - Problem: the table of contents for the library archives needs to be updated before applications will successfully link to the library Fix: Run "ranlib -s *.a" in the lib directory after the library is built (also on the installed version of the library if 'make install' is run). ----------------------------------------------------------------------------- ----------------------------------------------------------------------------- - Problem: the StringSpecial.o object file included in libSAMRAI.a conflicts with the g++ string library when the library is built with HDF5 but not when HDF5 is not included. This problem shows up with both HDF5 1.6.2 and HDF5 1.6.4 Fix (temporary): Since Paul's build seemed to work, I'm assuming that this is a bug due to either (1) the version of HDF5 or (2) changes in the C++ compiler in GCC 4.0. I fixed the problem for me by adding a C-preprocessor check around the explicit string template instantiation in source/toolbox/templates/special/StringSpecial.C: ========================================================== #if defined(__GNUC__) && (__GNUC__ == 3 && __GNUC_MINOR__ >= 2) #if defined(__ppc__) && !defined(HAVE_HDF5) // Templates for complex functions template std::basic_string, std::allocator > std::operator+, std::allocator >(std::basic_string, std::allocator > const&, std::basic_string, std::allocator > const&); #endif #endif ========================================================== To get this to work, I also needed to #include "SAMRAI_config.h" at the beginning of the file. ----------------------------------------------------------------------------- ----------------------------------------------------------------------------- Problem: Using H5T_NATIVE_CHAR for "data_is_defined" field of VisIt causes VisIt data files to be unreadable by VisIt. Fix: (due to Brian Taylor) Change the HDF5 data type to H5T_NATIVE_INT for "data_is_defined" field in SAMRAI/source/apputils/plotting/VisItDataWriter.C ----------------------------------------------------------------------------- ----------------------------------------------------------------------------- Problem: A few of the templates in libSAMRAI.a are multiply defined. These show up when running ranlib on the archive files. This does not seem to pose a problem for linking applications -- it is just unsightly. For example: ========================================================== ranlib: same symbol defined in more than one member in: libSAMRAI.a (table of contents will not be sorted) ranlib: file: libSAMRAI.a(tbox__List-tbox__TimerPointer.o) defines symbol: _ZN6SAMRAI4tbox12ListIteratorIPNS0_5TimerEE14rewindIteratorEv.eh ranlib: file: libSAMRAI.a(tbox_List-tbox_TimerPointer.o) defines symbol: _ZN6SAMRAI4tbox12ListIteratorIPNS0_5TimerEE14rewindIteratorEv.eh ========================================================== Fix: ?? -----------------------------------------------------------------------------