opss.. is not static library, but dynamic library:

"-DPYTHON_LIBRARY=/usr/bin/python/lib/python2.7/config/libpython2.7.dylib"
(OSX)

or

"-DPYTHON_LIBRARY=/usr/bin/python/lib/python2.7/config/libpython2.7.so"
(LINUX)


On 8 April 2014 00:09, David Ragazzi <[email protected]> wrote:

> Hi David,
>
> "-DPYTHON_LIBRARY=/usr/bin/python" is not a valid library.
>
> A valid library would be, for example:
>
> "-DPYTHON_LIBRARY=/usr/bin/python/lib/python2.7/config/libpython2.7.a" (a
> full path to a static python library)
>
> Try find the full library location and pass it through "-DPYTHON_LIBRARY="
> option. I believe that this segmentation fault is due to fact that 
> libcpp_region
> is linked against to static library pointed to PYTHON_LIBRARY. When
> compiler tries linked it, it presents "unreferenced symbols" errors among
> others..
>
> Best regards, David
>
>
>
> On 7 April 2014 21:25, David Ragazzi <[email protected]> wrote:
>
>> Hi David,
>>
>> First of all, beautiful name... :-)
>>
>> Well I'll try if I can pass a default path to find_libraries() function.
>> The idea is finding the libraries in the same path pointed by
>> PYTHON_LIBRARY_DIR variable in CMake file.
>>
>> Let me check this..
>>
>> Cheers, David
>>
>>
>> On 7 April 2014 21:06, Nielsen, David L. (ARC-TI)[Stinger Ghaffarian
>> Technologies Inc. (SGT Inc.)] <[email protected]> wrote:
>>
>>>  Hello NuPIC,
>>>
>>> We are having trouble getting the cmake to run correctly. We're building
>>> as root and unable to follow the directions in the README.md up till that
>>> point but we get the following error when trying  to run 'cmake ../..'
>>>
>>> CMake Error at
>>> /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:70 (MESSAGE):
>>>   Could NOT find PythonLibs (missing: PYTHON_LIBRARIES)
>>> Call Stack (most recent call first):
>>>   /usr/share/cmake/Modules/FindPythonLibs.cmake:102
>>> (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
>>>   CMakeLists.txt:378 (find_package)
>>>
>>> Any idea why we're unable to find PYTHON_LIBRARIES?
>>>
>>> We can get around this with :
>>>
>>> cmake -DPYTHON_LIBRARY=/usr/bin/python ../..
>>>
>>> This allows cmake and make to complete but then we get a segmentation
>>> fault when running the c++ tests. After a bit of digging we were able to
>>> find this happens when attempting to load the following shared object,
>>> which exists and the path is correct:
>>>
>>> /root/nta/eng/lib/libcpp_region.so
>>>
>>> What might be causing this segfault?
>>>
>>> Thanks,
>>> David & Ritchie
>>>
>>> _______________________________________________
>>> nupic mailing list
>>> [email protected]
>>> http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
>>>
>>>
>>
>>
>> --
>> David Ragazzi
>> OS Community Commiter
>> Numenta.org
>> --
>> "I think James Connonly, the Irish revolutionary, is right when he says that
>> the only prophets are those who make their future. So we're not
>> anticipating, we're working for it."
>>
>
>
>
> --
> David Ragazzi
> OS Community Commiter
> Numenta.org
> --
> "I think James Connonly, the Irish revolutionary, is right when he says that
> the only prophets are those who make their future. So we're not
> anticipating, we're working for it."
>



-- 
David Ragazzi
OS Community Commiter
Numenta.org
--
"I think James Connonly, the Irish revolutionary, is right when he says that
the only prophets are those who make their future. So we're not anticipating
, we're working for it."
_______________________________________________
nupic mailing list
[email protected]
http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
  • ... Nielsen, David L. (ARC-TI)[Stinger Ghaffarian Technologies Inc. (SGT Inc.)]
    • ... David Ragazzi
      • ... David Ragazzi
        • ... David Ragazzi
          • ... Marek Otahal
    • ... David L Nielsen
      • ... Matthew Taylor
        • ... cogmission1 .

Reply via email to