Peter and Greg,
First, please excuse the LONG post. I have tried to capture my entire RDKit
build experience and posted it below. The short story is that going back to
my build of Python 2.7 and including --enable-shared fixed the problem. I
think there was a conflict between the system Python (v2.4) and my update.
Now, having the libpython2.7.so in /usr/local/lib appears to have eliminated
the issue. Thank you!!!
Here's my build script relative to your suggested build script.
**************************
GCC with MPFR 2.4.1
I have upgraded GCC on my LINUX install to version 4.5.5. Previously, I
found the version of GCC on CentOS to have many bugs, in particular template
handling errors which prevented it from properly compiling boost and
ultimately breaking the entire process at the last step of testing RDKit.
The only remedy I've found is to completely rebuild GCC. I don't know if
the newest version of CentOS' GCC (v4.1.2) has this problem, so I rebuilt as
a precaution.
MPFR is a multi-precision floating point math library required for other
libraries, so I've simply included it in this build. For MPFR 2.4.1, copy
the expanded mpfr directory into the top level gcc directory tree as 'mpfr'
(no version numbers or dates). The build process takes care of it after
that so you don't have to build and link it on your own.
Create a build directory OUTSIDE the gcc directory structure and do all
build steps from there - the build process will take a few hours.
mkdir gcc-build
cd gcc-build
../gcc-4.4.5/configure
make
make install
**************************
Python 2.7
I do NOT have libpython2.7.so in /usr/local/lib. I did find
libpython2.4.soin /usr/lib64 and this makes me wonder if this was
being used during the
boost build. The error that I mentioned has been suggested to be attributed
to either mixing of Python versions (2.4 and 2.7 in my case) or from mixing
32-bit and 64-bit libraries.
I notice that you do not specify CFLAGS=-fPIC nor --enabled-unicode=ucs4 for
the Python build. I've kept this for now as they caused errors during the
RDKit build previously. My Python build sequence looks like this:
./configure CFLAGS=-fPIC --enable-unicode=ucs4 --enable-shared
make
make install
NOTE: After the remainder of this script, I have come to the conclusion
that the --enable-shared switch is the answer to the problem I was having.
While I had set the various subsequent steps to refer to the correct version
of Python, without libpython2.7.so in /usr/local/lib, I think that Bjam was
deferring to the system's Python libraries which were the wrong version.
This is the only step that differs from what I was doing yesterday. Thank
you, Peter!!
************************
Atlas, Lapack, Blas
I already have atlas, lapack, and blas along with their -devel libaries
installed.
I skipped installation of fftw3.
*************************
NumPy
You mention NumPy 1.3 or 1.4, and having problems with them, but don't
mention what the problems are. I've been using v1.5 without any issues.
I'll stick with that for now. The build sequence for this looks like this:
python setup.py build
python setup.py install
**************************
Boost 1.44.0
I built this one as per the RDKit.org instructions. I left the thread and
signals libraries out.
./bootstrap.sh --with-libraries=python,regex
./bjam address-model=64 cflags=-fPIC cxxflags=-fPIC install
**************************
Flex, Bison, CMake
I have already built and installed new versions of flex, bison, and cmake.
I have not removed the old versions, but I don't seem to have any
collisions.
**************************
RDKit
I'm working with the SVN version which I downloaded on 15 Nov 2010. The
Q22010_09_1 release seemed to always have a problem at ~84% build which gave
the very common "compile with -fPIC" error, but it was not fixed by
compiling Python or Boost with this switch. Using the SVN code eliminated
that problem.
I only set the following environment variables. I think some of those in
your list are no longer used.
$RDBASE
$LD_LIBRARY_PATH = /usr/local/lib:/$RDBASE/lib
$PYTHONPATH = $RDBASE
cd $RDBASE
mkdir build
cd build
cmake -D BOOST_USE_STATIC_LIBS=OFF -D BOOST_ROOT=/usr/local ..
make
make install
Upon testing, from rdkit import Chem works!! Whew! Running ctest gives
100% tests passed.
In addition to your scripts, I have done the following:
***************************
FreeType 2.4.3
./configure
make
make install
***************************
PIL 1.1.7
Modify the FREETYPE_ROOT environment variable (line 40) to point to the
directory in which FreeType was built. In my case, /opt/freetype-2.4.3.
python setup.py build
python setup.py install
***************************
Aggdraw
If you use the standard aggdraw package (
http://effbot.org/zone/aggdraw-index.htm) you have to use the following
compiler flag on 64-bit systems.
export CFLAGS="-fpermissive"
One option is to modify the one line of code for 64-bit as discussed here:
http://www.mail-archive.com/[email protected]/msg01107.html
In /agg2/include/agg_array.h
change line #523 from this:
unsigned align = (alignment - unsigned(ptr) % > alignment) % alignment;
to this:
unsigned align = (alignment - (unsigned long)(ptr) % alignment) % alignment;
I can then get aggdraw to build, but running the selftest.py gives a
segmentation fault. If I go ahead and install, it seems to work just fine
and the images produced from RDKit are much improved. The build process is:
export CFLAGS="-fpermissive"
python setup.py build_ext -i
python setup.py install
On Wed, Nov 17, 2010 at 9:51 AM, Robert DeLisle <[email protected]> wrote:
> Peter - This is great! I've only browsed through the script you have, but
> I do see a few differences. I'll give it a shot now and report back. Thank
> you so much for posting this.
>
> Greg - I ran ldd on rdBase.so, and here's the output:
>
> libRDGeneral.so.1 => /opt/RDKit_svn_20101115/lib/libRDGeneral.so.1
> (0x00002ad72659b000)
> libRDBoost.so.1 => /opt/RDKit_svn_20101115/lib/libRDBoost.so.1
> (0x00002ad7267d6000)
> libboost_python.so.1.44.0 =>
> /usr/local/lib/libboost_python.so.1.44.0 (0x00002ad726ba5000)
> libstdc++.so.6 => /usr/local/lib64/libstdc++.so.6
> (0x00002ad726df7000)
> libm.so.6 => /lib64/libm.so.6 (0x00002ad72712f000)
> libgcc_s.so.1 => /usr/local/lib64/libgcc_s.so.1
> (0x00002ad7273b2000)
> libc.so.6 => /lib64/libc.so.6 (0x00002ad7275c9000)
> libutil.so.1 => /lib64/libutil.so.1 (0x00002ad727920000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00002ad727b23000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00002ad727d3f000)
> librt.so.1 => /lib64/librt.so.1 (0x00002ad727f43000)
> /lib64/ld-linux-x86-64.so.2 (0x00000031f7000000)
>
> It does look like it is refering to the correct instances of what I've
> built. There are a few system level C/C++ library references, but I'm not
> seeing anything odd here. What's your take on it?
>
> -Kirk
>
>
>
>
>
>
> On Wed, Nov 17, 2010 at 6:34 AM, Peter Schmidtke <[email protected]>wrote:
>
>> Hey Greg,
>>
>> yep that would be great, as right now they are only on a group internal
>> blog ;) I saw that you recently changed you linux build instructions
>> (concerning database things, boost numerical bindings etc...), but I did
>> this before this came out ;)
>>
>> First lets see if Robert comes through the install process without major
>> problems and then you can post it on your wiki (I might have forgotten some
>> stuff).
>> Some things are based on installing pycuda on those machines, this is why
>> signals and things like that are compiled with boost (might be worth to
>> mention somehow in case people need both).
>>
>> ++
>>
>> Peter
>>
>> On 17/11/2010, at 14:25, Greg Landrum wrote:
>>
>> > Dear Peter,
>> >
>> > Thanks for posting these very detailed instructions. Do you mind if I
>> > post them to the wiki (with credit of course) to make them easier to
>> > find?
>> >
>> > I made a few comments and suggestions below:
>> >
>> > On Wed, Nov 17, 2010 at 11:19 AM, Peter Schmidtke <[email protected]>
>> wrote:
>> >> Dear Robert,
>> >> I recently ran also into several problems while installing rdkit on a
>> fresh
>> >> Centos 5.3. It's a real headache. Anyway, this time I've written up a
>> guide
>> >> of how to do it step by step, I hope I didn't forget anything in the
>> end.
>> >> However, now it works just fine on our Centos machines. Here's the step
>> by
>> >> step installing guide :
>> >>
>> >> Centos is a stable but not very userfriendly OS. This becomes obvious
>> when
>> >> one wants to install python packages like pycuda etc...Centos comes
>> with a
>> >> very old python version, 2.4, but lots of newer features, like pycuda
>> >> require a newer python version. Lets start the lengthy install process
>> under
>> >> Centos :
>> >>
>> >> Installing Python 2.6 or newer
>> >>
>> >> If you already have python2.7 installed, please check that it was
>> installed
>> >> with --enabled-shared. If this is the case you should have
>> libpython2.7.so
>> >> in /usr/local/lib. If not, you should have libpython2.7.a. If the
>> second is
>> >> the case, you have to install python2.7 with the following way :
>> >>
>> >> Download the current version from python (source code). Like with 2.6
>> or 2.7
>> >> (don't grab the 3.x for now) :
>> >>
>> >> wget http://www.python.org/ftp/python/2.7/Python-2.7.tgz
>> >>
>> >> Next untar and unzip the file, go to Python-2.7 directory and issue :
>> >>
>> >> ./configure --enable-shared; make; sudo make install
>> >>
>> >> This installs python in the /usr/local/ directory.
>> >>
>> >> Add the RPMForge repo to yum :
>> >>
>> >> wget
>> >>
>> http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.1-1.el5.rf.x86_64.rpm
>> >>
>> >> su -c 'rpm -Uvh rpmforge-release-0.5.1-1.el5.rf.x86_64.rpm'
>> >>
>> >> Then install atlas, lapack, blas :
>> >>
>> >> yum install atlas-c++.x86_64 atlas-c++-devel.x86_64 lapack.x86_64
>> >> lapack-devel.x86_64 blas.x86_64 blas-devel.x86_64
>> >>
>> >> Now we can install fftw3 :
>> >>
>> >> yum install fftw3.x86_64 fftw3-devel.x86_64
>> >>
>> >>
>> >>
>> >> Now we could potentially install numpy 1.3 or 1.4, but as python2.7 is
>> brand
>> >> new there are some problems. I downloaded :
>> >>
>> >> wget
>> http://sourceforge.net/projects/numpy/files/NumPy/1.3.0/numpy-1.3.0.tar.gz/download
>> >>
>> >> then untar and unzip this whole thing and go to the numpy directory
>> >>
>> >> Download the following patch :
>> >>
>> >> wget
>> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-python/numpy/files/numpy-1.4.0-python-2.7.patch
>> >>
>> >> and apply it in this directory using :
>> >>
>> >> patch -p0 < numpy-1.4.0-python-2.7.patch
>> >>
>> >> Now build numpy using python setup.py build; python setup.py install
>> >>
>> >> Numpy should now be accessible from python2.7, simply try a import
>> numpy
>> >> after launching python to check.
>> >>
>> >> First we need to install the boost libraries and their python bindings.
>> >> Download boost to your downloads directory using, here I use the
>> version
>> >> 1.41 of boost. :
>> >>
>> >> wget
>> >>
>> http://sourceforge.net/projects/boost/files/boost/1.41.0/boost_1_41_0.tar.gz/download
>> >>
>> >> untar and unzip this file and go to the directory.
>> >>
>> >> Then issue the following commands :
>> >>
>> >> ./bootstrap.sh --with-libraries=python,regex,signals,thread
>> >
>> > signals should not be necessary for the rdkit.
>> >
>> >>
>> >> Then you can issue the boost build command :
>> >>
>> >> ./bjam -j24 variant=release address-model=64 cflags=-fPIC
>> cxxflags=-fPIC
>> >> link=shared install
>> >>
>> >> Then add the line "export
>> LD_LIBRARY_PATH=/usr/local/lib:${LD_LIBRARY_PATH}"
>> >> to your .bashrc file and source it.
>> >>
>> >> If you have the default flex and bison packages installed from the yum
>> >> repositories erase them using yum erase flex and yum erase bison. Those
>> are
>> >> extremely old and Rdkit needs newer ones, we have to build them by hand
>> now.
>> >>
>> >> wget
>> http://prdownloads.sourceforge.net/flex/flex-2.5.35.tar.gz?download
>> >>
>> >> untar and unzip, cd flex-2.5.35 and then do a classic :
>> >>
>> >> ./configure; make; make install
>> >>
>> >> Now grab and install bison using the same procedure as for flex :
>> >>
>> >> wget http://ftp.gnu.org/gnu/bison/bison-2.4.2.tar.gz
>> >>
>> >> ...
>> >>
>> >> Now we have to upgrade cmake, because Centos uses, as usual an old and
>> a bit
>> >> buggy on. Download cmake 2.8 from here and untar and unzip it and go to
>> the
>> >> directory. Previously uninstall the existing (if existing) cmake
>> version on
>> >> your Centos platform using "yum erase cmake".
>> >>
>> >> The installation should be easy using :
>> >>
>> >> ./bootstrap; make; make install
>> >>
>> >> Finally we can go to the Rdkit part:
>> >>
>> >>
>> >>
>> >>
>> >> Download RDKit from here.
>> >>
>> >> wget
>> https://sourceforge.net/projects/rdkit/files/rdkit/Q2_2010/RDKit_Q22010_1.tgz/download
>> >>
>> >> wget
>> http://mathema.tician.de/news.tiker.net/download/software/boost-bindings/boost-numeric-bindings-20081116.tar.gz
>> >
>> > The above part is no longer necessary (the boost numeric bindings
>> > aren't used anymore).
>> >
>> >>
>> >> and follow instructions on boost numeric bindings here .
>> >>
>> >> cp -r boost_1_41_0 /usr/local
>> >> cp -r RDKit_Q22010 /usr/local
>> >>
>> >> define environment variables in /etc/bashrc as follows :
>> >>
>> >> export RDBASE=/usr/local/RDKit_Q22010_1
>> >> export BOOSTHOME=/usr/local/boost_1_41_0
>> >> export BOOST_BUILD_PATH=/usr/local
>> >> export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$RDBASE/bin
>> >> export PYTHON_ROOT=/usr/local
>> >> export PYTHON_VERSION=2.7
>> >> export PYTHONPATH=$PYTHONPATH:$RDBASE
>> >>
>> >>
>> >>
>> >>
>> >> got to the /usr/local/RDKit_Q22010 directory and do :
>> >>
>> >> mkdir build; cd build
>> >>
>> >> Add #define BOOST_PYTHON_NO_PY_SIGNATURES at the top of
>> >> ../Code/GraphMol/Wrap/EditableMol.cpp
>> >>
>> >> then issue the command :
>> >>
>> >> cmake -D PYTHON_LIBRARY=/usr/local/lib/libpython2.7.so -D
>> >> PYTHON_INCLUDE_DIR=/usr/local/include/python2.7/ -D
>> >> PYTHON_EXECUTABLE=/usr/local/bin/python -D BOOST_ROOT=/usr/local/
>> >> -DBoost_USE_STATIC_LIBS=OFF ..
>> >>
>> >> make
>> >>
>> >> make install
>> >>
>> >> Next you should install the test databases for rdkit, like said in the
>> >> documentation.
>> >
>> > Installing the test databases is also no longer required.
>> >
>> > Best Regards,
>> > -greg
>>
>> Peter Schmidtke
>>
>> -----------------
>> PhD Student
>> Department of Physical Chemistry
>> School of Pharmacy
>> University of Barcelona
>> Barcelona, Spain
>>
>>
>
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
Rdkit-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
