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 <[email protected]> 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 <[email protected]>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 <[email protected]> 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_cache<boost::re_detail::cpp_regex_traits_base<char>,
>>> boost::re_detail::cpp_regex_traits_implementation<char>
>>> >::do_get(boost::re_detail::cpp_regex_traits_base<char> 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
>>> > [email protected]
>>> > 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
