Re: [Rdkit-discuss] Building RDKit on CentOS 5

2010-11-17 Thread Peter Schmidtke 
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

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

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

Re: [Rdkit-discuss] Building RDKit on CentOS 5

2010-11-17 Thread Greg Landrum 
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 pschmid...@ub.edu 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

Re: [Rdkit-discuss] Building RDKit on CentOS 5

2010-11-17 Thread Peter Schmidtke 
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 pschmid...@ub.edu 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

Re: [Rdkit-discuss] Building RDKit on CentOS 5

2010-11-17 Thread Robert DeLisle 
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
(0x2ad72659b000)
libRDBoost.so.1 = /opt/RDKit_svn_20101115/lib/libRDBoost.so.1
(0x2ad7267d6000)
libboost_python.so.1.44.0 =
/usr/local/lib/libboost_python.so.1.44.0 (0x2ad726ba5000)
libstdc++.so.6 = /usr/local/lib64/libstdc++.so.6
(0x2ad726df7000)
libm.so.6 = /lib64/libm.so.6 (0x2ad72712f000)
libgcc_s.so.1 = /usr/local/lib64/libgcc_s.so.1 (0x2ad7273b2000)
libc.so.6 = /lib64/libc.so.6 (0x2ad7275c9000)
libutil.so.1 = /lib64/libutil.so.1 (0x2ad72792)
libpthread.so.0 = /lib64/libpthread.so.0 (0x2ad727b23000)
libdl.so.2 = /lib64/libdl.so.2 (0x2ad727d3f000)
librt.so.1 = /lib64/librt.so.1 (0x2ad727f43000)
/lib64/ld-linux-x86-64.so.2 (0x0031f700)

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 pschmid...@ub.edu 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 pschmid...@ub.edu
 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

Re: [Rdkit-discuss] Building RDKit on CentOS 5

2010-11-17 Thread Robert DeLisle 
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:

Re: [Rdkit-discuss] Building RDKit on CentOS 5

2010-11-17 Thread gia...@gmail.com 
On Wed, Nov 17, 2010 at 11:27 PM, Robert DeLisle rkdeli...@gmail.com wrote:
 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.

FTR, I reported the only issue I found with CentOS 5 related to gcc/boost here:
https://bugzilla.redhat.com/show_bug.cgi?id=582682

and looks like it's going to be fixed in the next update (5.6)

-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://identi.ca/giallu - http://twitter.com/giallu

--
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
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss

Re: [Rdkit-discuss] Building RDKit on CentOS 5

2010-11-16 Thread Robert DeLisle 
I'm sorry for the slow response.  Busy day.

For this install, I started on a CentOS 5.5 system that was up to date with
all package upgrades.  Following is what I've done so far:

installed blas, blas-devel, lapack, lapack-devel through yum

I had problems in the past with the standard GCC package on CentOS which is
version 4.1.2, so I rebuilt the GCC 4.4.5 package and included mpfr 2.4.1

Installed cmake 2.8.2
Installed flex 2.5.35

CentOS's Python installation is v2.4.1, so I built and installed 2.7.  Due
to errors found later in the process, I built this with the -fPIC switch and
also enabled Unicode UCS4 support

./configure CFLAGS=-fPIC --enable-unicode=ucs4

Built and installed NumPy 1.5.0

Boost on CentOS 5.5 is v1.33, so I built and installed boost 1.44 with the
following commands:

./bootstrap.sh --with-libraries=python,regex
./bjam address-model=64 install


Finally, with RDKit I have $LD_LIBRARY_PATH








On Mon, Nov 15, 2010 at 10:11 PM, rkdeli...@gmail.com wrote:

 No, I made sure to include the address-model=64 switch to bjam.

 Tomorrow when I get in I'll update the thread with all the steps I've
 followed.

 -Kirk




 On Nov 15, 2010 9:52pm, Greg Landrum greg.land...@gmail.com wrote:
  Kirk,
 
 
 
  On Tue, Nov 16, 2010 at 12:38 AM, Robert DeLisle rkdeli...@gmail.com
 wrote:
 
   Yes, that is also true.
 
  
 
   The error in my most recent messages stems from the default build of
 Python
 
   supporst Unicode UCS2, but apparently boost expects UCS4.  A rebuild of
 
   Python with UCS4 enabled fixed that problem.
 
  
 
   Now I get a similar error related to Py_InitModule4 not being defined.
 From
 
   what I can find, this is a 32-bit - 64-bit problem in which this was
 defined
 
   as Py_InitModule4_64 in the 64-bit Python libraries but that change may
 not
 
   have cascaded to all necessary parts of the build process.  Most of the
 
   changes involve some substantial changes to the accessing code, but I'm
 
   still looking for a better option.
 
 
 
  Could it be that the boost libraries you are using were not built in
 
  64bit mode? I've managed to force a 64bit build in the past with the
 
  following command line:
 
  ./bjam address-model=64 cflags=-fPIC cxxflags=-fPIC install
 
 
 
  Best Regards,
 
  -greg
 

--
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
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss

Re: [Rdkit-discuss] Building RDKit on CentOS 5

2010-11-16 Thread Robert DeLisle 
-- Forwarded message --
From: Robert DeLisle rkdeli...@gmail.com
Date: Tue, Nov 16, 2010 at 3:03 PM
Subject: Re: Re: [Rdkit-discuss] Building RDKit on CentOS 5
To: Greg Landrum greg.land...@gmail.com, Robert DeLisle 
rkdeli...@gmail.com


'm sorry for the slow response.  Busy day.

For this install, I started on a CentOS 5.5 system that was up to date with
all package upgrades.  Following is what I've done so far:

installed blas, blas-devel, lapack, lapack-devel through yum

I had problems in the past with the standard GCC package on CentOS which is
version 4.1.2, so I rebuilt the GCC 4.4.5 package and included mpfr 2.4.1

Installed cmake 2.8.2
Installed flex 2.5.35

CentOS's Python installation is v2.4.1, so I built and installed 2.7.  Due
to errors found later in the process, I built this with the -fPIC switch and
also enabled Unicode UCS4 support

./configure CFLAGS=-fPIC --enable-unicode=ucs4

Built and installed NumPy 1.5.0

Boost on CentOS 5.5 is v1.33, so I built and installed boost 1.44 with the
following commands:

./bootstrap.sh --with-libraries=python,regex
./bjam address-model=64 install


Finally, with RDKit I have $LD_LIBRARY_PATH set with /usr/local/lib first to
avoid conflicts with the system packages.  GCC and Python are both in
/usr/local and these are the instances referred to by my user and root.  For
RDKit, the following commands were done:

cmake -DBoost_USE_STATIC_LIBS=OFF -DBOOST_ROOT=/usr/local ..
make
make install



I have also installed FreeType2 and PIL - both seem fine with Python 2.7.  I
attempted aggdraw, but the self-test seem to always give me a Segmentation
Fault.  I found that I can build aggdraw using the code as-is as long as I
include CFLAGS=-fpermissive, or there is a one line code change that makes
the compiler happy on 64-bit.  Either way I still get the seg fault upon
testing.


Regarding RDKit, the first group of errors I received consisted of that
requiring Python be built with -fPIC and what seems to be the typical
USE_STATIC_LIBS error.

Initially, an -fPIC error would occur around 87% which was not cured by the
Python rebuild or any other modification.  I found that by switching to the
SVN code, the problem was solved.  Upon inspecting the errors logs, it
appeared that the build process was always referring to the system Boost
install and not my new install despite having set -DBOOST_ROOT correctly.

Currently, the build goes to completion but upon issuing 'from rdkit import
Chem' wihtin Python 2.7, I get an error related to Py_InitModule4 not being
defined.  From a little Google searching for Py_InitModule4 the only thing
I've seen thus far is a conflict in various packages on code built on 32-bit
or 64-bit systems.  It seems that this name has been renamed to
Py_InitModule4_64 on 64-bit systems but that change may not be reflected in
all code necessary.  It seemed a widespread problem and not specific to any
one application or library, which makes me think it is something in a Python
include file.

I appreciate any help that anyone can provide.  Please let me know if I need
to clarify or add any details.

-Kirk






On Mon, Nov 15, 2010 at 10:11 PM, rkdeli...@gmail.com wrote:

 No, I made sure to include the address-model=64 switch to bjam.

 Tomorrow when I get in I'll update the thread with all the steps I've
 followed.

 -Kirk




 On Nov 15, 2010 9:52pm, Greg Landrum greg.land...@gmail.com wrote:
  Kirk,
 
 
 
  On Tue, Nov 16, 2010 at 12:38 AM, Robert DeLisle rkdeli...@gmail.com
 wrote:
 
   Yes, that is also true.
 
  
 
   The error in my most recent messages stems from the default build of
 Python
 
   supporst Unicode UCS2, but apparently boost expects UCS4.  A rebuild of
 
   Python with UCS4 enabled fixed that problem.
 
  
 
   Now I get a similar error related to Py_InitModule4 not being defined.
 From
 
   what I can find, this is a 32-bit - 64-bit problem in which this was
 defined
 
   as Py_InitModule4_64 in the 64-bit Python libraries but that change may
 not
 
   have cascaded to all necessary parts of the build process.  Most of the
 
   changes involve some substantial changes to the accessing code, but I'm
 
   still looking for a better option.
 
 
 
  Could it be that the boost libraries you are using were not built in
 
  64bit mode? I've managed to force a 64bit build in the past with the
 
  following command line:
 
  ./bjam address-model=64 cflags=-fPIC cxxflags=-fPIC install
 
 
 
  Best Regards,
 
  -greg
 

--
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
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net

Re: [Rdkit-discuss] Building RDKit on CentOS 5

2010-11-16 Thread Robert DeLisle 
I apologize for that doulbe post before - itchy send finger.

Here's the specific error I'm getting after the build process has otherwise
succeded.

 from rdkit import Chem
Traceback (most recent call last):
  File stdin, line 1, in module
  File /opt/RDKit_svn_20101115/rdkit/Chem/__init__.py, line 18, in
module
from rdkit import rdBase
ImportError: /usr/lib64/libboost_python.so.2: undefined symbol:
Py_InitModule4







On Tue, Nov 16, 2010 at 3:04 PM, Robert DeLisle rkdeli...@gmail.com wrote:



 -- Forwarded message --
 From: Robert DeLisle rkdeli...@gmail.com
 Date: Tue, Nov 16, 2010 at 3:03 PM
 Subject: Re: Re: [Rdkit-discuss] Building RDKit on CentOS 5
 To: Greg Landrum greg.land...@gmail.com, Robert DeLisle 
 rkdeli...@gmail.com


 'm sorry for the slow response.  Busy day.

 For this install, I started on a CentOS 5.5 system that was up to date with
 all package upgrades.  Following is what I've done so far:

 installed blas, blas-devel, lapack, lapack-devel through yum

 I had problems in the past with the standard GCC package on CentOS which is
 version 4.1.2, so I rebuilt the GCC 4.4.5 package and included mpfr 2.4.1

 Installed cmake 2.8.2
 Installed flex 2.5.35

 CentOS's Python installation is v2.4.1, so I built and installed 2.7.  Due
 to errors found later in the process, I built this with the -fPIC switch and
 also enabled Unicode UCS4 support

 ./configure CFLAGS=-fPIC --enable-unicode=ucs4

 Built and installed NumPy 1.5.0

 Boost on CentOS 5.5 is v1.33, so I built and installed boost 1.44 with the
 following commands:

 ./bootstrap.sh --with-libraries=python,regex
 ./bjam address-model=64 install


 Finally, with RDKit I have $LD_LIBRARY_PATH set with /usr/local/lib first
 to avoid conflicts with the system packages.  GCC and Python are both in
 /usr/local and these are the instances referred to by my user and root.  For
 RDKit, the following commands were done:

 cmake -DBoost_USE_STATIC_LIBS=OFF -DBOOST_ROOT=/usr/local ..
 make
 make install



 I have also installed FreeType2 and PIL - both seem fine with Python 2.7.
 I attempted aggdraw, but the self-test seem to always give me a Segmentation
 Fault.  I found that I can build aggdraw using the code as-is as long as I
 include CFLAGS=-fpermissive, or there is a one line code change that makes
 the compiler happy on 64-bit.  Either way I still get the seg fault upon
 testing.


 Regarding RDKit, the first group of errors I received consisted of that
 requiring Python be built with -fPIC and what seems to be the typical
 USE_STATIC_LIBS error.

 Initially, an -fPIC error would occur around 87% which was not cured by the
 Python rebuild or any other modification.  I found that by switching to the
 SVN code, the problem was solved.  Upon inspecting the errors logs, it
 appeared that the build process was always referring to the system Boost
 install and not my new install despite having set -DBOOST_ROOT correctly.

 Currently, the build goes to completion but upon issuing 'from rdkit import
 Chem' wihtin Python 2.7, I get an error related to Py_InitModule4 not being
 defined.  From a little Google searching for Py_InitModule4 the only thing
 I've seen thus far is a conflict in various packages on code built on 32-bit
 or 64-bit systems.  It seems that this name has been renamed to
 Py_InitModule4_64 on 64-bit systems but that change may not be reflected in
 all code necessary.  It seemed a widespread problem and not specific to any
 one application or library, which makes me think it is something in a Python
 include file.

 I appreciate any help that anyone can provide.  Please let me know if I
 need to clarify or add any details.

 -Kirk






 On Mon, Nov 15, 2010 at 10:11 PM, rkdeli...@gmail.com wrote:

 No, I made sure to include the address-model=64 switch to bjam.

 Tomorrow when I get in I'll update the thread with all the steps I've
 followed.

 -Kirk




 On Nov 15, 2010 9:52pm, Greg Landrum greg.land...@gmail.com wrote:
  Kirk,
 
 
 
  On Tue, Nov 16, 2010 at 12:38 AM, Robert DeLisle rkdeli...@gmail.com
 wrote:
 
   Yes, that is also true.
 
  
 
   The error in my most recent messages stems from the default build of
 Python
 
   supporst Unicode UCS2, but apparently boost expects UCS4.  A rebuild
 of
 
   Python with UCS4 enabled fixed that problem.
 
  
 
   Now I get a similar error related to Py_InitModule4 not being
 defined.  From
 
   what I can find, this is a 32-bit - 64-bit problem in which this was
 defined
 
   as Py_InitModule4_64 in the 64-bit Python libraries but that change
 may not
 
   have cascaded to all necessary parts of the build process.  Most of
 the
 
   changes involve some substantial changes to the accessing code, but
 I'm
 
   still looking for a better option.
 
 
 
  Could it be that the boost libraries you are using were not built in
 
  64bit mode? I've managed to force a 64bit build in the past with the
 
  following command line:
 
  ./bjam address-model=64 cflags=-fPIC

Re: [Rdkit-discuss] Building RDKit on CentOS 5

2010-11-16 Thread rkdelisle 

Hi, Greg.

Yes, I've double (and triple) checked LD_LIBRARY_PATH and it has  
/usr/local/lib:/usr/local/lib64, and in fact it doesn't have /usr/lib or  
/usr/lib64 at all. I also went through a number of attempts to pass the  
appropriate directories to cmake as you have on the install instruction  
page. Specifically, cmake -DBOOST_ROOT=/opt/local. Even with all of this,  
cmake is still grabbing the system boost .so. I then removed all traces of  
the system installed Boost libraries - they didn't appear to have any  
dependencies - and it seems to get the right one, but I still get the same  
error. The difference is that it is now pointing to  
/usr/local/lib/libboost_python.so as the source of the error. It also seems  
odd to me that the Boost install put these in /usr/local/lib and not  
/usr/local/lilb64.


I'll check the output of ldd tomorrow, and just verify LD_LIBRARY_PATH is  
set correctly. I'm also planning to do a clean virtual install of CentOS  
5.5 to try it from scratch on an environment I can hack a bit more.


-Kirk

PS - I hope you're getting a nice new LINUX machine. 8^)




On Nov 16, 2010 9:38pm, Greg Landrum greg.land...@gmail.com wrote:

Hi Kirk,




On Tue, Nov 16, 2010 at 11:48 PM, Robert DeLisle rkdeli...@gmail.com  
wrote:



 I apologize for that doulbe post before - itchy send finger.






 Here's the specific error I'm getting after the build process has  
otherwise



 succeded.







 from rdkit import Chem



 Traceback (most recent call last):



 File , line 1, in



 File /opt/RDKit_svn_20101115/rdkit/Chem/__init__.py, line 18, in







 from rdkit import rdBase



 ImportError: /usr/lib64/libboost_python.so.2: undefined symbol:



 Py_InitModule4





I'm not sure about the rest of the problems (it's clear I need to get



a VM set up that's running CentOS so that I can get a better feeling



for this; I will do this when my new linux box arrives), but this



particular error indicates (normally) that your LD_LIBRARY_PATH is set



incorrectly. Notice that the system boost_python is being used. Are



you sure that LD_LIBRARY_PATH has /usr/local/lib first? If so, could



you please run ldd /opt/RDKit_svn_20101115/rdkit/rdBase.so and see



what that returns?





Thanks,



-greg


--
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
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss

[Rdkit-discuss] Building RDKit on CentOS 5

2010-11-15 Thread Robert DeLisle 
I've been working to build RDKit on Centos 5, and I'm hitting a very common
error.  Unfortunately, none of the standard fixes have helped.

Details:

The error that I'm seeing is this:

[ 82%] Building CXX object
Code/GraphMol/SLNParse/CMakeFiles/SLNParse.dir/SLNParse.cpp.o
[ 83%] Building CXX object
Code/GraphMol/SLNParse/CMakeFiles/SLNParse.dir/SLNAttribs.cpp.o
[ 83%] Building CXX object
Code/GraphMol/SLNParse/CMakeFiles/SLNParse.dir/sln.tab.cpp.o
[ 84%] Building CXX object
Code/GraphMol/SLNParse/CMakeFiles/SLNParse.dir/lex.yysln.cpp.o
Linking CXX shared library libSLNParse.so
/usr/bin/ld: /usr/lib/../lib64/libboost_regex.a(instances.o): relocation
R_X86_64_32 against
`boost::object_cacheboost::re_detail::cpp_regex_traits_basechar,
boost::re_detail::cpp_regex_traits_implementationchar
::do_get(boost::re_detail::cpp_regex_traits_basechar const, unsigned
long)::s_data' can not be used when making a shared object; recompile with
-fPIC
/usr/lib/../lib64/libboost_regex.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[2]: *** [Code/GraphMol/SLNParse/libSLNParse.so] Error 1
make[1]: *** [Code/GraphMol/SLNParse/CMakeFiles/SLNParse.dir/all] Error 2
make: *** [all] Error 2


I've taken the standard steps of building Python (v2.7) with the -fPIC
flag.  Specficially, I attached CFLAGS=-fPIC to configure in the Python
build.  This solved the first instance of this type of error occuring at
about 3%.

I've also tried the two fixes for Boost with the following command line to
build RDKit:

cmake -DBOOST_ROOT=/usr/local -DBoost_USE_STATIC_LIBS=OFF ..


I still get this error, and I notice that the Boost libraries that are being
referred to are actually the system installation in usr/lib64 and not those
that I've build in /usr/local/lib.  It would seem that I can't seem to force
make to look in the right location.

Any tips are greatly apprciated.

-Kirk
--
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev___
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss

Re: [Rdkit-discuss] Building RDKit on CentOS 5

2010-11-15 Thread Eddie Cao 
Have you tried to remove the CMake cache file before rerun cmake?

rm -f CMakeCache.txt

After rerun cmake, take a look at that file again and make sure things like 
Boost_INCLUDE_DIR and Boost_LIBRARY_DIRS all point to  /usr/local/include and 
/usr/local/lib, etc.

Eddie


On Nov 15, 2010, at 12:45 PM, Robert DeLisle wrote:

 I've been working to build RDKit on Centos 5, and I'm hitting a very common 
 error.  Unfortunately, none of the standard fixes have helped.
 
 Details:
 
 The error that I'm seeing is this:
 
 [ 82%] Building CXX object 
 Code/GraphMol/SLNParse/CMakeFiles/SLNParse.dir/SLNParse.cpp.o
 [ 83%] Building CXX object 
 Code/GraphMol/SLNParse/CMakeFiles/SLNParse.dir/SLNAttribs.cpp.o
 [ 83%] Building CXX object 
 Code/GraphMol/SLNParse/CMakeFiles/SLNParse.dir/sln.tab.cpp.o
 [ 84%] Building CXX object 
 Code/GraphMol/SLNParse/CMakeFiles/SLNParse.dir/lex.yysln.cpp.o
 Linking CXX shared library libSLNParse.so
 /usr/bin/ld: /usr/lib/../lib64/libboost_regex.a(instances.o): relocation 
 R_X86_64_32 against 
 `boost::object_cacheboost::re_detail::cpp_regex_traits_basechar, 
 boost::re_detail::cpp_regex_traits_implementationchar 
 ::do_get(boost::re_detail::cpp_regex_traits_basechar const, unsigned 
 long)::s_data' can not be used when making a shared object; recompile with 
 -fPIC
 /usr/lib/../lib64/libboost_regex.a: could not read symbols: Bad value
 collect2: ld returned 1 exit status
 make[2]: *** [Code/GraphMol/SLNParse/libSLNParse.so] Error 1
 make[1]: *** [Code/GraphMol/SLNParse/CMakeFiles/SLNParse.dir/all] Error 2
 make: *** [all] Error 2
 
 
 I've taken the standard steps of building Python (v2.7) with the -fPIC flag.  
 Specficially, I attached CFLAGS=-fPIC to configure in the Python build.  This 
 solved the first instance of this type of error occuring at about 3%.
 
 I've also tried the two fixes for Boost with the following command line to 
 build RDKit:
 
 cmake -DBOOST_ROOT=/usr/local -DBoost_USE_STATIC_LIBS=OFF ..  
   
 
 I still get this error, and I notice that the Boost libraries that are being 
 referred to are actually the system installation in usr/lib64 and not those 
 that I've build in /usr/local/lib.  It would seem that I can't seem to force 
 make to look in the right location.
 
 Any tips are greatly apprciated.
 
 -Kirk
 
 
 
 --
 Centralized Desktop Delivery: Dell and VMware Reference Architecture
 Simplifying enterprise desktop deployment and management using
 Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
 client virtualization framework. Read more!
 http://p.sf.net/sfu/dell-eql-dev2dev___
 Rdkit-discuss mailing list
 Rdkit-discuss@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/rdkit-discuss


--
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
___
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss

Re: [Rdkit-discuss] Building RDKit on CentOS 5

2010-11-15 Thread Robert DeLisle 
Yep, I've defintely done that.  I've even gone so far as to wipe out the
directory entirely and start with a fresh RDKit directory.  I also looked
into the cache file and seen that the library directories appear to be set
as /usr/local/lib and /user/local/lib64, but one the error occurs, it refers
to /usr/lib64.  I can't seem to find any reason for this.

-Kirk




On Mon, Nov 15, 2010 at 3:26 PM, Eddie Cao cao.yi...@gmail.com wrote:

 Have you tried to remove the CMake cache file before rerun cmake?

 rm -f CMakeCache.txt

 After rerun cmake, take a look at that file again and make sure things like
 Boost_INCLUDE_DIR and Boost_LIBRARY_DIRS all point to  /usr/local/include
 and /usr/local/lib, etc.

 Eddie


 On Nov 15, 2010, at 12:45 PM, Robert DeLisle wrote:

  I've been working to build RDKit on Centos 5, and I'm hitting a very
 common error.  Unfortunately, none of the standard fixes have helped.
 
  Details:
 
  The error that I'm seeing is this:
 
  [ 82%] Building CXX object
 Code/GraphMol/SLNParse/CMakeFiles/SLNParse.dir/SLNParse.cpp.o
  [ 83%] Building CXX object
 Code/GraphMol/SLNParse/CMakeFiles/SLNParse.dir/SLNAttribs.cpp.o
  [ 83%] Building CXX object
 Code/GraphMol/SLNParse/CMakeFiles/SLNParse.dir/sln.tab.cpp.o
  [ 84%] Building CXX object
 Code/GraphMol/SLNParse/CMakeFiles/SLNParse.dir/lex.yysln.cpp.o
  Linking CXX shared library libSLNParse.so
  /usr/bin/ld: /usr/lib/../lib64/libboost_regex.a(instances.o): relocation
 R_X86_64_32 against
 `boost::object_cacheboost::re_detail::cpp_regex_traits_basechar,
 boost::re_detail::cpp_regex_traits_implementationchar
 ::do_get(boost::re_detail::cpp_regex_traits_basechar const, unsigned
 long)::s_data' can not be used when making a shared object; recompile with
 -fPIC
  /usr/lib/../lib64/libboost_regex.a: could not read symbols: Bad value
  collect2: ld returned 1 exit status
  make[2]: *** [Code/GraphMol/SLNParse/libSLNParse.so] Error 1
  make[1]: *** [Code/GraphMol/SLNParse/CMakeFiles/SLNParse.dir/all] Error 2
  make: *** [all] Error 2
 
 
  I've taken the standard steps of building Python (v2.7) with the -fPIC
 flag.  Specficially, I attached CFLAGS=-fPIC to configure in the Python
 build.  This solved the first instance of this type of error occuring at
 about 3%.
 
  I've also tried the two fixes for Boost with the following command line
 to build RDKit:
 
  cmake -DBOOST_ROOT=/usr/local -DBoost_USE_STATIC_LIBS=OFF ..
 
 
  I still get this error, and I notice that the Boost libraries that are
 being referred to are actually the system installation in usr/lib64 and not
 those that I've build in /usr/local/lib.  It would seem that I can't seem to
 force make to look in the right location.
 
  Any tips are greatly apprciated.
 
  -Kirk
 
 
 
 
 --
  Centralized Desktop Delivery: Dell and VMware Reference Architecture
  Simplifying enterprise desktop deployment and management using
  Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
  client virtualization framework. Read more!
 
 http://p.sf.net/sfu/dell-eql-dev2dev___
  Rdkit-discuss mailing list
  Rdkit-discuss@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/rdkit-discuss


--
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev___
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss

Re: [Rdkit-discuss] Building RDKit on CentOS 5

2010-11-15 Thread Robert DeLisle 
It must be something in the release version of RDKit.  I just grabbed the
SVN version, put it in the same location, followed the same procedures, and
it has just compiled fine without any other changes on my part.

Greg - any ideas what the difference is here?  Not that it matters given
that the SVN is working, but just for curiosity's sake.

Sadly, now I get this from with Python:


 from rdkit import Chem
Traceback (most recent call last):
  File stdin, line 1, in module
  File /opt/RDKit_svn_20101115/rdkit/Chem/__init__.py, line 18, in
module
from rdkit import rdBase
ImportError: /usr/lib64/libboost_python.so.2: undefined symbol:
PyUnicodeUCS4_FromEncodedObject



-Kirk





On Mon, Nov 15, 2010 at 3:28 PM, Robert DeLisle rkdeli...@gmail.com wrote:

 Yep, I've defintely done that.  I've even gone so far as to wipe out the
 directory entirely and start with a fresh RDKit directory.  I also looked
 into the cache file and seen that the library directories appear to be set
 as /usr/local/lib and /user/local/lib64, but one the error occurs, it refers
 to /usr/lib64.  I can't seem to find any reason for this.

 -Kirk





 On Mon, Nov 15, 2010 at 3:26 PM, Eddie Cao cao.yi...@gmail.com wrote:

 Have you tried to remove the CMake cache file before rerun cmake?

 rm -f CMakeCache.txt

 After rerun cmake, take a look at that file again and make sure things
 like Boost_INCLUDE_DIR and Boost_LIBRARY_DIRS all point to
  /usr/local/include and /usr/local/lib, etc.

 Eddie


 On Nov 15, 2010, at 12:45 PM, Robert DeLisle wrote:

  I've been working to build RDKit on Centos 5, and I'm hitting a very
 common error.  Unfortunately, none of the standard fixes have helped.
 
  Details:
 
  The error that I'm seeing is this:
 
  [ 82%] Building CXX object
 Code/GraphMol/SLNParse/CMakeFiles/SLNParse.dir/SLNParse.cpp.o
  [ 83%] Building CXX object
 Code/GraphMol/SLNParse/CMakeFiles/SLNParse.dir/SLNAttribs.cpp.o
  [ 83%] Building CXX object
 Code/GraphMol/SLNParse/CMakeFiles/SLNParse.dir/sln.tab.cpp.o
  [ 84%] Building CXX object
 Code/GraphMol/SLNParse/CMakeFiles/SLNParse.dir/lex.yysln.cpp.o
  Linking CXX shared library libSLNParse.so
  /usr/bin/ld: /usr/lib/../lib64/libboost_regex.a(instances.o): relocation
 R_X86_64_32 against
 `boost::object_cacheboost::re_detail::cpp_regex_traits_basechar,
 boost::re_detail::cpp_regex_traits_implementationchar
 ::do_get(boost::re_detail::cpp_regex_traits_basechar const, unsigned
 long)::s_data' can not be used when making a shared object; recompile with
 -fPIC
  /usr/lib/../lib64/libboost_regex.a: could not read symbols: Bad value
  collect2: ld returned 1 exit status
  make[2]: *** [Code/GraphMol/SLNParse/libSLNParse.so] Error 1
  make[1]: *** [Code/GraphMol/SLNParse/CMakeFiles/SLNParse.dir/all] Error
 2
  make: *** [all] Error 2
 
 
  I've taken the standard steps of building Python (v2.7) with the -fPIC
 flag.  Specficially, I attached CFLAGS=-fPIC to configure in the Python
 build.  This solved the first instance of this type of error occuring at
 about 3%.
 
  I've also tried the two fixes for Boost with the following command line
 to build RDKit:
 
  cmake -DBOOST_ROOT=/usr/local -DBoost_USE_STATIC_LIBS=OFF ..
 
 
  I still get this error, and I notice that the Boost libraries that are
 being referred to are actually the system installation in usr/lib64 and not
 those that I've build in /usr/local/lib.  It would seem that I can't seem to
 force make to look in the right location.
 
  Any tips are greatly apprciated.
 
  -Kirk
 
 
 
 
 --
  Centralized Desktop Delivery: Dell and VMware Reference Architecture
  Simplifying enterprise desktop deployment and management using
  Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
  client virtualization framework. Read more!
 
 http://p.sf.net/sfu/dell-eql-dev2dev___
  Rdkit-discuss mailing list
  Rdkit-discuss@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/rdkit-discuss



--
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev___
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss

Re: [Rdkit-discuss] Building RDKit on CentOS 5

2010-11-15 Thread Eddie Cao 
Make sure /usr/local/lib appears before /usr/lib64 in your LD_LIBRARY_PATH. It 
seems python import loads the system boost rather than your custom boost.

-Eddie
On Nov 15, 2010, at 2:44 PM, Robert DeLisle wrote:

 It must be something in the release version of RDKit.  I just grabbed the SVN 
 version, put it in the same location, followed the same procedures, and it 
 has just compiled fine without any other changes on my part.
 
 Greg - any ideas what the difference is here?  Not that it matters given that 
 the SVN is working, but just for curiosity's sake.
 
 Sadly, now I get this from with Python:
 
 
  from rdkit import Chem
 Traceback (most recent call last):
   File stdin, line 1, in module
   File /opt/RDKit_svn_20101115/rdkit/Chem/__init__.py, line 18, in module
 from rdkit import rdBase
 ImportError: /usr/lib64/libboost_python.so.2: undefined symbol: 
 PyUnicodeUCS4_FromEncodedObject
 
 
 
 -Kirk
 
 
 
 
 
 On Mon, Nov 15, 2010 at 3:28 PM, Robert DeLisle rkdeli...@gmail.com wrote:
 Yep, I've defintely done that.  I've even gone so far as to wipe out the 
 directory entirely and start with a fresh RDKit directory.  I also looked 
 into the cache file and seen that the library directories appear to be set as 
 /usr/local/lib and /user/local/lib64, but one the error occurs, it refers to 
 /usr/lib64.  I can't seem to find any reason for this.
 
 -Kirk
 
 
 
 
 
 On Mon, Nov 15, 2010 at 3:26 PM, Eddie Cao cao.yi...@gmail.com wrote:
 Have you tried to remove the CMake cache file before rerun cmake?
 
 rm -f CMakeCache.txt
 
 After rerun cmake, take a look at that file again and make sure things like 
 Boost_INCLUDE_DIR and Boost_LIBRARY_DIRS all point to  /usr/local/include and 
 /usr/local/lib, etc.
 
 Eddie
 
 
 On Nov 15, 2010, at 12:45 PM, Robert DeLisle wrote:
 
  I've been working to build RDKit on Centos 5, and I'm hitting a very common 
  error.  Unfortunately, none of the standard fixes have helped.
 
  Details:
 
  The error that I'm seeing is this:
 
  [ 82%] Building CXX object 
  Code/GraphMol/SLNParse/CMakeFiles/SLNParse.dir/SLNParse.cpp.o
  [ 83%] Building CXX object 
  Code/GraphMol/SLNParse/CMakeFiles/SLNParse.dir/SLNAttribs.cpp.o
  [ 83%] Building CXX object 
  Code/GraphMol/SLNParse/CMakeFiles/SLNParse.dir/sln.tab.cpp.o
  [ 84%] Building CXX object 
  Code/GraphMol/SLNParse/CMakeFiles/SLNParse.dir/lex.yysln.cpp.o
  Linking CXX shared library libSLNParse.so
  /usr/bin/ld: /usr/lib/../lib64/libboost_regex.a(instances.o): relocation 
  R_X86_64_32 against 
  `boost::object_cacheboost::re_detail::cpp_regex_traits_basechar, 
  boost::re_detail::cpp_regex_traits_implementationchar 
  ::do_get(boost::re_detail::cpp_regex_traits_basechar const, unsigned 
  long)::s_data' can not be used when making a shared object; recompile with 
  -fPIC
  /usr/lib/../lib64/libboost_regex.a: could not read symbols: Bad value
  collect2: ld returned 1 exit status
  make[2]: *** [Code/GraphMol/SLNParse/libSLNParse.so] Error 1
  make[1]: *** [Code/GraphMol/SLNParse/CMakeFiles/SLNParse.dir/all] Error 2
  make: *** [all] Error 2
 
 
  I've taken the standard steps of building Python (v2.7) with the -fPIC 
  flag.  Specficially, I attached CFLAGS=-fPIC to configure in the Python 
  build.  This solved the first instance of this type of error occuring at 
  about 3%.
 
  I've also tried the two fixes for Boost with the following command line to 
  build RDKit:
 
  cmake -DBOOST_ROOT=/usr/local -DBoost_USE_STATIC_LIBS=OFF ..
 
 
  I still get this error, and I notice that the Boost libraries that are 
  being referred to are actually the system installation in usr/lib64 and not 
  those that I've build in /usr/local/lib.  It would seem that I can't seem 
  to force make to look in the right location.
 
  Any tips are greatly apprciated.
 
  -Kirk
 
 
 
  --
  Centralized Desktop Delivery: Dell and VMware Reference Architecture
  Simplifying enterprise desktop deployment and management using
  Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
  client virtualization framework. Read more!
  http://p.sf.net/sfu/dell-eql-dev2dev___
  Rdkit-discuss mailing list
  Rdkit-discuss@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
 
 
 

--
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
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss

Re: [Rdkit-discuss] Building RDKit on CentOS 5

2010-11-15 Thread Robert DeLisle 
Yes, that is also true.

The error in my most recent messages stems from the default build of Python
supporst Unicode UCS2, but apparently boost expects UCS4.  A rebuild of
Python with UCS4 enabled fixed that problem.

Now I get a similar error related to Py_InitModule4 not being defined.  From
what I can find, this is a 32-bit - 64-bit problem in which this was defined
as Py_InitModule4_64 in the 64-bit Python libraries but that change may not
have cascaded to all necessary parts of the build process.  Most of the
changes involve some substantial changes to the accessing code, but I'm
still looking for a better option.







On Mon, Nov 15, 2010 at 4:14 PM, Eddie Cao cao.yi...@gmail.com wrote:

 Make sure /usr/local/lib appears before /usr/lib64 in your LD_LIBRARY_PATH.
 It seems python import loads the system boost rather than your custom boost.

 -Eddie

 On Nov 15, 2010, at 2:44 PM, Robert DeLisle wrote:

 It must be something in the release version of RDKit.  I just grabbed the
 SVN version, put it in the same location, followed the same procedures, and
 it has just compiled fine without any other changes on my part.

 Greg - any ideas what the difference is here?  Not that it matters given
 that the SVN is working, but just for curiosity's sake.

 Sadly, now I get this from with Python:


  from rdkit import Chem
 Traceback (most recent call last):
   File stdin, line 1, in module
   File /opt/RDKit_svn_20101115/rdkit/Chem/__init__.py, line 18, in
 module
 from rdkit import rdBase
 ImportError: /usr/lib64/libboost_python.so.2: undefined symbol:
 PyUnicodeUCS4_FromEncodedObject



 -Kirk





 On Mon, Nov 15, 2010 at 3:28 PM, Robert DeLisle rkdeli...@gmail.comwrote:

 Yep, I've defintely done that.  I've even gone so far as to wipe out the
 directory entirely and start with a fresh RDKit directory.  I also looked
 into the cache file and seen that the library directories appear to be set
 as /usr/local/lib and /user/local/lib64, but one the error occurs, it refers
 to /usr/lib64.  I can't seem to find any reason for this.

 -Kirk





 On Mon, Nov 15, 2010 at 3:26 PM, Eddie Cao cao.yi...@gmail.com wrote:

 Have you tried to remove the CMake cache file before rerun cmake?

 rm -f CMakeCache.txt

 After rerun cmake, take a look at that file again and make sure things
 like Boost_INCLUDE_DIR and Boost_LIBRARY_DIRS all point to
  /usr/local/include and /usr/local/lib, etc.

 Eddie


 On Nov 15, 2010, at 12:45 PM, Robert DeLisle wrote:

  I've been working to build RDKit on Centos 5, and I'm hitting a very
 common error.  Unfortunately, none of the standard fixes have helped.
 
  Details:
 
  The error that I'm seeing is this:
 
  [ 82%] Building CXX object
 Code/GraphMol/SLNParse/CMakeFiles/SLNParse.dir/SLNParse.cpp.o
  [ 83%] Building CXX object
 Code/GraphMol/SLNParse/CMakeFiles/SLNParse.dir/SLNAttribs.cpp.o
  [ 83%] Building CXX object
 Code/GraphMol/SLNParse/CMakeFiles/SLNParse.dir/sln.tab.cpp.o
  [ 84%] Building CXX object
 Code/GraphMol/SLNParse/CMakeFiles/SLNParse.dir/lex.yysln.cpp.o
  Linking CXX shared library libSLNParse.so
  /usr/bin/ld: /usr/lib/../lib64/libboost_regex.a(instances.o):
 relocation R_X86_64_32 against
 `boost::object_cacheboost::re_detail::cpp_regex_traits_basechar,
 boost::re_detail::cpp_regex_traits_implementationchar
 ::do_get(boost::re_detail::cpp_regex_traits_basechar const, unsigned
 long)::s_data' can not be used when making a shared object; recompile with
 -fPIC
  /usr/lib/../lib64/libboost_regex.a: could not read symbols: Bad value
  collect2: ld returned 1 exit status
  make[2]: *** [Code/GraphMol/SLNParse/libSLNParse.so] Error 1
  make[1]: *** [Code/GraphMol/SLNParse/CMakeFiles/SLNParse.dir/all] Error
 2
  make: *** [all] Error 2
 
 
  I've taken the standard steps of building Python (v2.7) with the -fPIC
 flag.  Specficially, I attached CFLAGS=-fPIC to configure in the Python
 build.  This solved the first instance of this type of error occuring at
 about 3%.
 
  I've also tried the two fixes for Boost with the following command line
 to build RDKit:
 
  cmake -DBOOST_ROOT=/usr/local -DBoost_USE_STATIC_LIBS=OFF ..
 
 
  I still get this error, and I notice that the Boost libraries that are
 being referred to are actually the system installation in usr/lib64 and not
 those that I've build in /usr/local/lib.  It would seem that I can't seem to
 force make to look in the right location.
 
  Any tips are greatly apprciated.
 
  -Kirk
 
 
 
 
 --
  Centralized Desktop Delivery: Dell and VMware Reference Architecture
  Simplifying enterprise desktop deployment and management using
  Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
  client virtualization framework. Read more!
 
 http://p.sf.net/sfu/dell-eql-dev2dev___
  Rdkit-discuss mailing list
  Rdkit-discuss@lists.sourceforge.net

Re: [Rdkit-discuss] Building RDKit on CentOS 5

2010-11-15 Thread Greg Landrum 
Hi Kirk,

On Mon, Nov 15, 2010 at 11:44 PM, Robert DeLisle rkdeli...@gmail.com wrote:
 It must be something in the release version of RDKit.  I just grabbed the
 SVN version, put it in the same location, followed the same procedures, and
 it has just compiled fine without any other changes on my part.

 Greg - any ideas what the difference is here?  Not that it matters given
 that the SVN is working, but just for curiosity's sake.

I'm afraid I don't really know why there would be a difference. I
can't think of anything that has changed between the release and now
that would cause this behavior.

-greg

--
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
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss

Re: [Rdkit-discuss] Building RDKit on CentOS 5

2010-11-15 Thread Greg Landrum 
Kirk,

On Tue, Nov 16, 2010 at 12:38 AM, Robert DeLisle rkdeli...@gmail.com wrote:
 Yes, that is also true.

 The error in my most recent messages stems from the default build of Python
 supporst Unicode UCS2, but apparently boost expects UCS4.  A rebuild of
 Python with UCS4 enabled fixed that problem.

 Now I get a similar error related to Py_InitModule4 not being defined.  From
 what I can find, this is a 32-bit - 64-bit problem in which this was defined
 as Py_InitModule4_64 in the 64-bit Python libraries but that change may not
 have cascaded to all necessary parts of the build process.  Most of the
 changes involve some substantial changes to the accessing code, but I'm
 still looking for a better option.

Could it be that the boost libraries you are using were not built in
64bit mode? I've managed to force a 64bit build in the past with the
following command line:
./bjam address-model=64 cflags=-fPIC cxxflags=-fPIC install

Best Regards,
-greg

--
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
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss

Re: [Rdkit-discuss] Building RDKit on CentOS 5

2010-11-15 Thread rkdelisle 

No, I made sure to include the address-model=64 switch to bjam.

Tomorrow when I get in I'll update the thread with all the steps I've  
followed.


-Kirk



On Nov 15, 2010 9:52pm, Greg Landrum greg.land...@gmail.com wrote:

Kirk,




On Tue, Nov 16, 2010 at 12:38 AM, Robert DeLisle rkdeli...@gmail.com  
wrote:



 Yes, that is also true.






 The error in my most recent messages stems from the default build of  
Python



 supporst Unicode UCS2, but apparently boost expects UCS4. A rebuild of



 Python with UCS4 enabled fixed that problem.






 Now I get a similar error related to Py_InitModule4 not being defined.  
From


 what I can find, this is a 32-bit - 64-bit problem in which this was  
defined


 as Py_InitModule4_64 in the 64-bit Python libraries but that change may  
not



 have cascaded to all necessary parts of the build process. Most of the



 changes involve some substantial changes to the accessing code, but I'm



 still looking for a better option.





Could it be that the boost libraries you are using were not built in



64bit mode? I've managed to force a 64bit build in the past with the



following command line:



./bjam address-model=64 cflags=-fPIC cxxflags=-fPIC install





Best Regards,



-greg


--
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
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss