Build visit issues

VisIt's build_visit script has made the process of building all of VisIt's 3rd party library dependencies a much more tractable problem. However, as with any complex piece of scripting/software, there are bound to be issues. This is a place holder for some workarounds and solutions until they can be incorporated into the build_visit script.

thirdparty_path

It's been reported that when you don't provide a value for --thirdparty_path on the build_visit command line, causing a local visit directory to contain your libraries, the libraries will not contain their full path in their soname. This can cause VisIt to fail to link/run later since it uses rpath to locate the libraries instead of copying them into VisIt's lib directory during development.

The build_visit script should be modified to make the path used for thirdparty_path absolute in all cases.

Static build

NETCDF/HDF4

NETCDF and HDF4 both contain some of the same symbols and thus cannot be linked into the same static application. It has been suggested that compiling HDF4 with -DHAVE_NETCDF will fix the issue. This has not been tried yet.

MacOS 10.4

The current build_visit script has some issues when used on a MacOS 10.4 system. Newer versions of MacOS X do not have these issues.

Mesa

The Mesa 7.5 build fails because the MesaGLU library cannot be created. We create the MesaGLU library on MacOS X because it is used later for its tessellation library. The following change to build_mesa corrects the problem:

# Do not build libMesaGLU unless we're on MacOS X
DISABLE_GLU="--disable-glu"
if [[ "$OPSYS" == "Darwin" ]]; then
    DISABLE_GLU=""
fi

becomes

# Do not build libMesaGLU unless we're on MacOS X
DISABLE_GLU="--disable-glu"
if [[ "$OPSYS" == "Darwin" ]]; then
    DISABLE_GLU=""
    # If we're on 10.4 or earlier, change the GLU exports file
    VER=$(uname -r)
    if [[ ${VER%%.*} -le 9 ]]; then
        rm src/glu/sgi/glu.exports.darwin.edit
        sed "s/_\*/_m/g" src/glu/sgi/glu.exports.darwin > src/glu/sgi/glu.exports.darwin.edit
        cp src/glu/sgi/glu.exports.darwin.edit src/glu/sgi/glu.exports.darwin
    fi
fi

Python

The build_visit script builds Python just fine and it builds it as a shared library. This later causes problems in VisIt due to an unresolved environ symbol from the Python library. Python itself does not suffer from this problem because Python's main defines that symbol. However, VisIt's Python-related programs do not define environ and fail to link. The real solution is to build Python as a framework on MacOS X since it handles environ differently. We can't use a Python framework with our current version of VTK, unfortunately.

To work around this problem, open Python-2.6.4/Modules/posixmodule.c and look for #ifdef WITH_NEXT_FRAMEWORK. This macro is defined when building Python as a framework. Add #define WITH_NEXT_FRAMEWORK just above the ifdef test. Continue building and installing Python. VisIt will be able to link against the resulting Python.