Could not find minieigen (missing: PY_minieigen)

Asked by JIPEIQI

Even if the minieigen installlation succeed. the installation of yade still reports like :

Could NOT find minieigen (missing: PY_minieigen)
Call Stack (most recent call first):
  /usr/local/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:315 (_FPHSA_FAILURE_MESSAGE)
  cMake/FindPythonModule.cmake:22 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:519 (find_python_module)

Question information

Language:
English Edit question
Status:
Answered
For:
Yade Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:

This question was reopened

Revision history for this message
JIPEIQI (jpq-learning) said :
#1

Has any encountered similar problems... please give me some instructions...

Revision history for this message
Luc OGER (luc-oger) said :
#2

as I am compiling very often yade on several opensuse systems, I had to install minieigen_0.5.3 at each beginning, I suggested to make a clean basic installation on minieigen WITHOUT any change in the library or include path.

Indeed all the process of Yade or extra library linking are based on some default paths. Changing one location can change a lot the full hierarchy...

in my case python setup.py install for minieigen is working without any problem and after the position of the package inside python egg is well recognize.

Revision history for this message
Bruno Chareyre (bruno-chareyre) said :
#3

Hi Jipeiqi, the question is meaningless currently. Which version of yade, which operating system, etc.
I know it was described previously but each question is independent.
My impression is that you only need a small change in the compilation process (of minieigen, or of yade, or both) but it is hard to give an accurate answer without access to your particular system.
Bruno

Revision history for this message
JIPEIQI (jpq-learning) said :
#4

Hi Bruno! the operating system is Centos 6.6 and yade version is 2017.01a and the version of minieigen is 0.5.3.
I installed minieigen by typing python setup.py install or by pip install minieigen.

Revision history for this message
JIPEIQI (jpq-learning) said :
#5

Hi Luc!
I installed minieigen by typing python setup.py install.
After the installion, in position /usr/lib64/python26/sitepackeges/, there apperas minieigen.so and minieigen-0.5.3-py2.6.egg-info , but the minieigen seems to be empty as the size of it is 0 bytes

Revision history for this message
Luc OGER (luc-oger) said :
#6

hi Jipeiqi

in my case :
in /usr/lib64/python2.7/site-packages or /usr/lib64/python/site-packages (same as virtual link for python)
I have
> ll | grep mini
-rw-r--r-- 1 root root 1265 12 févr. 09:31 minieigen-0.5.3-py2.7.egg-info
-rwxr-xr-x 1 root root 89733144 12 févr. 09:31 minieigen.so

which means that your installation of minieigen is corrupt and can explain the rest of the compilation problem.

so erase the minieigen files and start from scratch

PS : check which python is the main one : version 2.x or 3.x generally the new OS can start to install part of btoh!

Revision history for this message
JIPEIQI (jpq-learning) said :
#7

HI luc!
I delete all my minieigen files and redownload the sourece files and I have to download it from [1] or problems like [2] will happen. So using source from [1], the installion of minieigen seems not well again, it reports like :

g++ -pthread -shared build/temp.linux-x86_64-2.6/src/minieigen.o build/temp.linux-x86_64-2.6/src/expose-boxes.o build/temp.linux-x86_64-2.6/src/expose-complex.o build/temp.linux-x86_64-2.6/src/expose-converters.o build/temp.linux-x86_64-2.6/src/expose-matrices.o build/temp.linux-x86_64-2.6/src/expose-quaternion.o build/temp.linux-x86_64-2.6/src/expose-vectors.o build/temp.linux-x86_64-2.6/src/double-conversion/bignum.o build/temp.linux-x86_64-2.6/src/double-conversion/bignum-dtoa.o build/temp.linux-x86_64-2.6/src/double-conversion/cached-powers.o build/temp.linux-x86_64-2.6/src/double-conversion/diy-fp.o build/temp.linux-x86_64-2.6/src/double-conversion/double-conversion.o build/temp.linux-x86_64-2.6/src/double-conversion/fast-dtoa.o build/temp.linux-x86_64-2.6/src/double-conversion/fixed-dtoa.o build/temp.linux-x86_64-2.6/src/double-conversion/strtod.o -L/usr/lib64 -lboost_python-py26 -lpython2.6 -o build/lib.linux-x86_64-2.6/minieigen.so
/usr/bin/ld: cannot find -lboost_python-py26
collect2: ld returned 1 exit status
error: command 'g++' failed with exit status 1

I will reinstall boost and update python to 2.7.14 and I will give my result again....
[1] https://github.com/eudoxos/minieigen
[2]https://answers.launchpad.net/yade/+question/665049

Revision history for this message
JIPEIQI (jpq-learning) said :
#8

The source from [1] may not be approite for centos 6.6. The source from [2] is suitble and in the setup.py: the
"libraries=['boost_python-py%d%d'%(sys.version_info[0],sys.version_info[1])]" should be changed to ''libraries=['boost_python']"

then the installion passed....

I will mark my question as solved for now and I will keep trying to install yade on my centos....

Revision history for this message
JIPEIQI (jpq-learning) said :
#9
Revision history for this message
Luc OGER (luc-oger) said :
#10

hi Jipeiqi

just to completed the link [1] was the correct one for my opensuse case.
launching directly the "setup.py" command is doing the job!

Revision history for this message
JIPEIQI (jpq-learning) said :
#11

Hi luc and hi Bruno
I installed minieigen successfully and the error :"Could NOT find minieigen (missing: PY_minieigen)"
It really confused me......

My operating system is Centos 6.6 and yade version is 2017.01a and the version of minieigen is 0.5.3. The version of boost is 1.66.0....

Revision history for this message
Luc OGER (luc-oger) said :
#12

Hi Jipeiqi,

in my recollection, some prebuild package can be installed in a different place as some manually installed one : I had the problem with libQGLviewer... and I was unable to link it correctly
so i suggest
- you to try the intallation of the link[1] package
- you try to install the git-trunk latest distribution version "yade-2018-03....." it is always better for a compiling version to have the up-to-date solution.

otherwise you can add the "-DCMAKE_VERBOSE_MAKEFILE=ON" in the cmake command to get more detail in the log file.

Can you help with this problem?

Provide an answer of your own, or ask JIPEIQI for more information if necessary.

To post a message you must log in.