The components of the distribution are
To install HippoDraw, just double click on the .msi file and follow the instructions. The installer file includes everything you need except Python. To use HippoDraw with Python, pre-built binaries for Python are available from the Python download page. You'll need to add HippoDraw to your Python path. Right click on MyComputer icon and go to
MyComputer->Properties->Advanced->Environmental Variables.
Create a new variable, PYTHONPATH, if you don't already have one, and add HippoDraw to it, for example, C:\Program Files\HippoDraw
Building HippoDraw with Qt 3 from source under Windows requires a Trolltech Qt commercial license, Microsoft VC++ 8.0 project files and instructions on how to use them are located in the vs.net2005 directory. Building HippoDraw with Qt 4 under Windows has not been tested with this release.
In most cases, just doing the standard configure, make, and make install dance should work. The configure script will find the required software if they are installed in their default locations (usually /usr/local). If it doesn't, read the Configuring HippoDraw section below for configuring with HippoDraw with some external packages located on usual places (especially for Mac OS X).
The major sections on the remainder of this page are
The current release was tested with gcc 3.2.3 on Red Hat Enterprise 3,4.6 pm Red Jat Emter[rose 4 gcc 4.2.1 on Fedora Core 7, gcc 4.0.1 on Mac OS X, and Windows XP with Visual Studio 8 (aka .NET 2005). Older versions of these compilers have been know to be sufficient in the past. That is, gcc 2.95.3 should still work. There are #ifdef in the source mainly for Visual Studio 6 but more may be needed.
Modern Linux distributions have a compatible version of the Qt 3 libraries installed. However, the header files might be missing unless the "developer" package of Qt was also installed. On some distributions, this is part of the KDE developer package.
The current release of Qt is 3.3.7. and Qt 4.1.4. HippoDraw has been tested with both version on Linux, Mac OS X, and Windows
If an adequate version of Qt is not already installed on your system, it must be built and installed from source. See Installing Trolltech's Qt section below.
This release was developed with Qt 3.3.7 on Linux, Mac OS X, and Windows, but also tested with Qt 3.1.2 on Red Hat Enterprise 3 system and Qt 4.1.2, on Fedora Core 6.
Python can be obtained from http://www.python.org. This release was tested with Python 2.2, 2.3, and 2.4.
Boost.Python version 1.32.0 or later is required for full functionality of HippoDraw's Python extension modules.
Only one class, FunctionWrap, requires this recent version of Boost, all others could use Boost-1.29.0 or later. See Boost path and library. for configuring HippoDraw for older versions of Boost. This release was developed with Boost-1_33_1.
See the Installing Boost section for tips on installing Boost.
Do not get confused by the older libMinuit.so shared library that comes with the ROOT distribution, it is not the same thing. That library is an f2c'd version of the original Fortran.
HippoDraw can return a numerical array to Python from any of the type of DataSource objects that are supported. One can also import data to a HippoDraw DataSource from a numerical array. This requires that at least one of numerical array Python modules has been installed and HippoDraw configured to build with to use it.
In source directory, just type ...
> ./autogen
This will create the Makefile.in in each subdirectory and the configure script that will be used in the next step. It will also create symbolic links in the config directory for scripts required by autoconf, automake, and libtool.
> ../hippodraw/configure
one should be configured with with the required external packages and any optional packages that were found to be installed. If this doesn't work, then read on in this section for configuring with external packages installed in non-standard places and see section If Configure Fails. for possible causes of the failure. The latter section also contains some special problems with Mac OS X.
It is recommended that you build in a separate directory from the source code. For example, if the name of the directory where the hippodraw source code is located is hippodraw/, then from the directory above it you might do
> mkdir hippodraw-BUILD > cd hippodraw-BUILD > ../hippodraw/configure --with-Qt-dir=/usr/local/qt
This will force using Qt in /usr/local. The configure script will test the Qt installation and fail if faulty or incorrect path.
The configure script setups the build for the version of Python in your path. If this is not the version you want to build with, set your PATH environmental variable before running configure.
On Mac OS X, there are some special steps to be taken before running configure. See Building from CVS checkout and Failing to find Qt. below.
The configure script has many other options, which you can see by typing...
> ./configure --help
Most options are the same as other packages that use the GNU auto-tools suite. Some specific to HippoDraw are
--with-Qt-lib= sets the name of the Qt shared library. The default is qt-mt corresponding to libqt-mt.so which has multi-threading enabled which is required to use HippoDraw with Python.
Normally, under the directory where Qt has been installed, one finds Qt's bin, include, and lib directories. If this is not the case, then you need to use the remaining Qt related options to set the appropriate paths.
To use Qt 4 use the corresponding --with-qt4 options. For example
../hippodraw/configure --with-qt4-dir=/usr/lib/qt4 --with-qt4-lib=/usr/lib \ --with-qt4-include=/usr/include
If you are using Qt 4 and you plan to use the ListTuple class in Python, and you have a multi-processor machine, then one should configure like this
./hippodraw/configure CPPFLAGS=-DHAVE_SMP --with-qt4-dir=/usr/local/Trolltech/Qt-4.1.2
Failure to do so may lead to mysterious crashes due to thread conflicts.
With this release, using Qt 4 has not been fully tested yet, but there are no known bugs that do not exist when built with Qt 3.
--with-boost-root= sets the path to the root of the boost installation. The default is /usr/local. This option only works if under this directory there is a subdirectory include/Boost-1_33_1/ subdirectory and a lib subdirectory.
--with-boost-include= sets the path to directory that contains a subdirectory boost/ which contains the header files. The default is /usr/local/include/boost-1_33_1/.
--with-boost-lib= sets the path to the boost libraries. The default is /usr/local/lib/.
--with-boost-libname= sets the name of the Boost.Python library. The default, if not given, is boost_python-gcc-1_33_1. A normal Boost install creates a dozen or so variations of each library. Because the compiler name is part of the library you may need to use this option when not compiling with gcc.
http://seal.web.cern.ch/seal/snapshot/work-packages/mathlibs/minuit/index.html
For this version the library name is liblcgMinuit.so and the last released version is 1.7.9.
The latest version is called Minuit2 and is found here...
http://seal.web.cern.ch/seal/MathLibs/Minuit2/html/index.html
The library name is libMinuit2Base.so and has no external dependencies other than the C++ standard library.
In addition, if you have ROOT installed, you may find libMinuit2.so as part of the installation. This library contains libMinuit2Base plus some other ROOT specific classes thus has dependencies on other ROOT libraries.
HippoDraw can be configured to work with the original interface, the Minuit2 interface as a standalone, or the Minuit2 interface installed as part of your ROOT installation.
This release was tested Minuit-1.7.9 and Minuit2-5.12. Versions earlier than Minuit-1.4.0 incompatible.
In the following, one can use either --with-minuit-xxx or --with-minuit2-xxx. The former use the version of C++ Minuit with the original API and the latter uses the new (ROOT compatbile) API of Minuit2.
--with-minuit-include= sets the path to the Minuit header files. The default, if not given, is /usr/local/include/Minuit which is the default install of the Minuit package. For Minuit2, the defaults are first /usr/local/include/Minuit2 then/usr/include/Minuit2.
--with-minuit-lib= sets the path to the directory where the libMinuit.so shared library is installed. The default, if not given, is /usr/local/lib which is the default install of the Minuit package. For Minuit2, the defaults are first /usr/local/lib then /usr/lib.
--with-minuit-libname= sets the name the Minuit shared library. The default is lcg_Minuit corresponding to the installed liblcg_Minuit.so file. If the version of Minuit you have installed is 1.5.1 or earlier, then this option should be used to set the library name to Minuit.
If both versions of Minuit are found by default, then the Minuit2 implementation will be used. If neither version is found, and if ROOT installation is found, and if Minuit2 is found as part of it, then that version will be used.
If Minuit is not found in the default locations, then HippoDraw will be built without Minuit support.
--with-cfitsio-lib= sets the path to the directory where the libcfitsio.so shared library is installed. The default, if not given, is first /usr/local/lib then /usr/lib.
CFITSIO might be installed as part of the FTOOLS package, in which case one should use its installation path.
If CFITSIO is not found in the default location, or if the path of one of the above options is set to `no' or incorrect, then HippoDraw will be built without CFITSIO support.
--with-wcslib-lib= sets the path to the directory that contains the libwcs.a The default, if not given, is /usr/local/lib.
--with-root-lib= sets the path to the ROOT library files. The default if not given, is /usr/local/lib/root.
If you want to build without ROOT support and ROOT is installed in the above default paths, then use --without-root-include or --without-root-lib.
If ROOT is not found in its default location, or if the path is set to `no' or incorrect, then HippoDraw will be built without ROOT support.
There is one warning coming from the build ...
g++ -DHAVE_CONFIG_H -I. -I../../hippodraw/numarray -I.. -I../../hippodraw -I../../hippodraw/python -I/usr/local/include/boost-1_33_1 -ftemplate-depth-60 -I/usr/local/include/python2.4 -g -O2 -Wall -c ../../hippodraw/numarray/NumArrayTuple.cxx -MT NumArrayTuple.lo -MD -MP -MF .deps/NumArrayTuple.TPlo -fPIC -DPIC /usr/local/include/python2.4/numarray/libnumeric.h:47: warning: 'libnumeric_API' defined but not used
which can be ignored.
checking whether the C++ compiler works...
configure: error: cannot run C++ compiled programs.
then configure is not finding the libstdc++.so version corresponding to the version of gcc it is using. This can happen, for example, if gcc in /usr/local/bin is being used and your system doesn't use /usr/local/lib in its shared library paths. The fix is to run configure like this ...
> ../hippodraw/configure LD_LIBRARY_PATH=/usr/local/lib
--disable-libtool-lock
Failure to do so will lead to the following error message to appear every two seconds
Waiting for BinnerBase.o.lock to be removed
With libtool locking disabled, one should not attempt to do parallel builds, i.e. using the `-j' option with the make command.
> make
If compiling on a multiple processor machine (or dual core one), one can use the do a parallel build with
> make -j2
This will cut the time needed to build by almost a factor of two.
This command first compiles core library, than the Qt specific parts and standalone executable, and finally the Python extension module. It will take about 6 minutes on 2 GhZ Pentium Mobile laptop.
During the build, you may see warnings like this ...
/usr/lib/qt-3.3/include/private/qucom_p.h:69: warning: \ 'struct QUBuffer' has virtual functions but non-virtual destructor /usr/lib/qt-3.3/include/private/qucom_p.h:77: warning: \ 'struct QUType' has virtual functions but non-virtual destructor
when compiling some classes in the Qt or ROOT libraries. These appear if compiling with gcc 4.0 or later and can be safely ignored.
To generate the documentation for the C++ library, requires installation of Doxygen and Graphviz. You can change the Doxygen configuration file, `doc/Doxyfile.in', so Graphviz is not needed, but you will lose ability to generate some graphs.
If these tools are installed type ...
> make docs
to generated the HTML documentation in your build directory. The main page will be doc/html/index.html.
If you want to generated PDF documentation, type
> make pdfdoc
This takes much longer than just generating the HTML. It leads to a 38MB PDF file which contains almost 5000 pages (5 boxes of paper if printed double sided).
/usr/bin/ld: cannot find -l-lqassistantclient collect2: ld returned 1 exit status make[4]: *** [libhippoqt.la] Error 1 make[4]: Leaving directory `/build/HippoDraw-1.16.0/qt'
then when running configure, you need to add
--with-Qt-lib=qt-mt
For some reason, the autoconf macro for Qt, finds it sucessfully, yet doesn't set the QT_LIBS macro correctly in the make files.
../../qt/.libs/libhippoqt.so: undefined reference\ to `QWaitCondition::~QWaitCondition [in-charge]()' ../../qt/.libs/libhippoqt.so: undefined reference\ to `QApplication::lock()' ../../qt/.libs/libhippoqt.so: undefined reference\ to `QWaitCondition::wakeAll()' ../../qt/.libs/libhippoqt.so: undefined reference\ to `QApplication::unlock(bool)' ../../qt/.libs/libhippoqt.so: undefined reference\ to `QWaitCondition::QWaitCondition[in-charge]()' ../../qt/.libs/libhippoqt.so: undefined reference\ to `QWaitCondition::wait(unsigned long)'
Then it is most likely that the configure script found the non-threaded version of Qt. HippoDraw should be built with the thread version, so that it can be used with Python. The Qt library name that has threaded support is libqt-mt.so.
http://www.trolltech.com/developer/tasktracker.html?method=entry&id=85440
The fix is to open the qtui/Inspector.ui file and remove the includehints XML node.
To install HippoDraw just type ...
> su Password: # make install
By default, installation is in /usr/local/bin. usr/local/include/HippoDraw and usr/local/lib. Also, the Python module will be installed in /usr/local/lib/python<n.m>/site-packages where `<n.m>' is the Python version (without any further. bug fix releases number). You can change the path to the install area with the --prefix= option to the configure command.
To install the class library documentation, type
# make install-docs
If you did not install HippoDraw in the default area, then you need to add the path to the HippoDraw executable to your PATH environment variable or type the full path to the executable. To use HippoDraw as a Python extension module in this case, you need to add the path to the module to your PYTHONPATH environment variable. For example, if you installed HippoDraw in /usr/local/test, then csh users would do ...
> setenv PATH /usr/local/test/bin:$PATH > setenv PYTHONPATH /usr/local/test/lib/python2.4/site-packages:$PYTHONPATH
> configure --prefix=$HOME
then they will be installed in your home directory under bin/, include/, and lib/. This will it easier to install and use them and other packages that depend on them. Just set your PATH environment variable in include $HOME/bin and your LD_LIBRARY_PATH (DYLD_LIBRARY_PATH on Mac OS X) to include $HOME/lib.
Some external packages cause some trouble if you don't read the instructions carefully. This sections give some tips that have been learn over time by the developers of HippoDraw.
The first option is to configure Qt with multi-threading support. The configure option is -thread. This is needed in order to be able to run HippoDraw as a Python extension module.
The second option is to set the run-time library path for the Qt library. This is needed so that you do not have to set the LD_LIBRARY_PATH environment variable when the HippoDraw's build invokes Qt's uic and moc executables. The Qt configure option is -R. If you are using a compiler whose corresponding library is not in /usr/lib, then you should also add its path to the -R option.
Trolltech recommends unpacking the sources in /usr/local and doing a build in place. If you do that, then all the example files will be built in your /usr/local which you may not want. I do a build in a work area, and then an install to /usr/local.
A recent build of Qt 3 was done as follows:
> tar zxvf qt-x11-free-3.3.4.tar.gz > cd /home/pfkeb/qt-x11-free-3.3.4/ > setenv QTDIR /home/pfkeb/qt-x11-free-3.3.4 > setenv PATH $QTDIR/bin:$PATH > setenv MANPATH $QTDIR/doc/man > setenv LD_LIBRARY_PATH $QTDIR/lib:/usr/local/lib > ./configure -prefix /usr/local/qt-x11-free-3.3.4 -R/usr/local/qt-x11-free-3.3.4/lib -R/usr/local/lib -thread -qt-gif > make > su Password: # make install
You must also build Qt with the same compiler as you will use to build HippoDraw.
Building with Qt 4 is easier, just follow the instructions that come with the distribution.
Boost versions 1_31_0 and later are easier to build than earliler versions by following the its web pages. At least for version 1_33_1 it is even easier than documented on their Web pages. The following just works....
> configure > make > make install
The above sequence of commands will build and install all the Boost librries. You can save 200MB of disk space and considerable amount of time by building only the Boost.Python libraries. This is done by adding --with-libraries=python to the confiugre command.
Apparently, the configure script creates a Makefile as a wrapper to the bjam command. So you still need the bjam executable, but don't need to know the bjam command syntax.
If you are going to try to follow Boost's instructions for building, then its seems that setting the environment variable `PYTHON_VERSION' and `PYTHON_ROOT' is missing from these pages, but documented within the Boost.Python web pages, otherwise it builds as instructed. This is true for both Windows and Unix like systems. With Boost version 1_31 there are warning messages about redefining _POSIX_C_SOURCE which apparently can be ignored. These warning don't appear with version 1_33 or later.
The following was done for installing Boost with bjam directly
> tar zxvf boost_1_33_1.tar.gz > cd boost_1_33_1 > su Password: # export PYTHON_VERSION=2.4 # export PYTHON_ROOT=/usr/local # bjam "-sTOOLS=gcc" install
For Mac OS X, see Installing Boost on Mac OS X.
This puts dozens of shared and static library files in /usr/local/lib. One probably doesn't need them all. If short on disk space, one might try the --without-<library> option to the bjam command. Or one might use the `stage' option and only copy the header directory boost and the required library files to /usr/local manually.
[pfkeb@localhost testsuite]$ python -i canvas.py
Traceback (most recent call last):
File "canvas.py", line 13, in ?
from hippo import HDApp
ImportError: /usr/local/lib/libboost_python-gcc-1_33.so.1.33.0:
undefined symbol: PyUnicodeUCS4_FromEncodedObject
it is most likely caused by building Boost.Python with version of Python with UCS-4 mode and building Hippodraw with another version of Python without it. handling. For example, the Boost version that comes with Fedora Core 4 will have this problem if you install a new version of Python in /usr/local bin.
The fix is to make sure you are using the same version of Python for building Boost.Python and HippoDraw. My recommendation is to build and install Python in /usr/local. You'll then get the pydoc and idle commands which are missing from the Red Hat distributions. Also, you may want to install external Python modules in /usr/local/lib/python2.4/site-packages that are not available as Fedora rpms. Then you can rebuild Boost and go to a new version, say 1_33 at the same time.
As of cfitsio 2.510, its configure script does not behave like most configure scripts of other Open Source packages. In particular, the defult prefix path is the directory in which the script is invoked. If you want to install cfitsio in a public area like /usr/local, only the --prefix option works, but not the --includedir or --libdir.
Also, the cfitsio Makefile does not build shared library required by HippoDraw by default. So the installation of cfitsio that will work well with HippoDraw would be...
> configure --prefix=/usr/local > make > make shared > make install
An unfortunate side effect of building like this is that two .h files are copied to /usr/local/include whose names give no clue that they belong to the cfitsio package. They are drvrsmen.h and longnam.h and for the former, even its contents give no clue that it belongs to the cfitsio package.
/usr/include/boost/python/detail/def_helper.hpp:80: internal compiler error: Segmentation fault
then the following might help...
Modified "boost/python/detail/translate_exception.hpp"(line 40) From: catch(exception_cref e) To: catch(exception_cref& e)
This problem was reported by Akito Kusaka. He was using SuSE 9.1, boost.python 1.31.0 from RPM package, gcc 3.3.3 from RPM package. He found the fix in http://mail.python.org/pipermail/c++-sig/2004-June/007587.html
/usr/include/boost/python/converter/as_to_python_function.hpp:28: sorry, unimplemented: `method_call_expr' not supported by dump_expr
Suggested work around is found on Python C++-sig mailing list . It allows compilation and linking but two the the test scripts, datareps.py and cuts.py, both fail at runtime.
>>> QThread: internal error: zero data for running thread.
> cd Python-2.4 > ./configure > make > su Password: # make install
When installing Python as root user with its make install it might fail with
/usr/bin/install -c -m 644 ./LICENSE /usr/local/lib/python2.3/LICENSE.txt
PYTHONPATH=/usr/local/lib/python2.3 \
./python -Wi -tt /usr/local/lib/python2.3/compileall.py \
-d /usr/local/lib/python2.3 -f \
-x 'badsyntax|site-packages' /usr/local/lib/python2.3
./python: error while loading shared libraries: libstdc++.so.6:
cannot open shared object file: No such file or directory
make: *** [libinstall] Error 127
The problem can be caused by the compiler being installed in /usr/local and the root user not having /usr/local/lib in his LD_LIBRARY_PATH. Just do
export LD_LIBRARY_PATH=/usr/local/lib
and try again.
> cd numarray-1.15.1 > python setup.py install >
error while loading shared libraries: /home/pfkeb/hippodraw-NATIVE/lib/.libs/libhippo.so.0: cannot restore segment prot after reloc: Permission denied
or the following message when importing the Python extension module
importError: /home/pfkeb/hippodraw-NATIVE/lib/.libs/libhippo.so.0: cannot restore segment prot after reloc: Permission denied
then you are problably running SELinux. Newer Linux distributions have enabled new kernel security extensions from the SELinux project at the NSA. These extensions allow finer-grained control over system security. However, SELinux also changes some default system behaviors, such as shared library loading, that can be problematic to third party programs.
To fix this problem you can change the default security context of HippoDraw with the command...
chcon -t texrel_shlib_t <path-to-hippodraw>/libhippo.so.0.0.o
or putting SELinux in Permissive or Disabled mode.
grep: /usr/local/lib/libstdc++.la: No such file or directory /bin/sed: can't read /usr/local/lib/libstdc++.la: No such file or directory libtool: link: `/usr/local/lib/libstdc++.la' is not a valid libtool archive make[2]: *** [libhippo.la] Error 1 make[2]: Leaving directory `/home/pfkeb/hippodraw-BUILD/lib'
then the fault is not in HippoDraw but in one of the external libraries it is linking against. This can happen when the external library uses libtool for building and was built with gcc in /usr/local. If gcc in /usr/local gets removed, say because upgrading the OS brought a newer version, then the external library will need to be rebuilt.
gcc -DHAVE_CONFIG_H -g -O2 -c wcsulex.c In file included from lex.wcsulex.c:8848: /usr/include/unistd.h:441: error: conflicting types for 'read' lex.wcsulex.c:8523: error: previous implicit declaration of 'read' was here make[2]: *** [wcsulex.o] Error 1 gcc -DHAVE_CONFIG_H -g -O2 -c wcsutrn.c In file included from lex.wcsutrn.c:5103: /usr/include/unistd.h:441: error: conflicting types for 'read' lex.wcsutrn.c:4793: error: previous implicit declaration of 'read' was here make[2]: *** [wcsutrn.o] Error 1 make[2]: Target `lib' not remade because of errors. make[1]: *** [../C/libwcs-4.2.a] Error 2
The problems appears to be that files wcsulex.c and wcsutrn.c were generated by a flex incompatible with the unistd.h file on a 64 bit machine. The fix is to touch the files wcsulex.l and wcsutrn.l to change their file dates. Then when you issue make, the 64 bit flex will be used to reproduce these files and they can compile.
Also there a lots of warning of the kind
wcs.c:1306: warning: cast from pointer to integer of different size
All are within a printf expressios.