Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tests fail on OSX #17

Closed
mikh3x4 opened this issue Nov 29, 2015 · 7 comments
Closed

Tests fail on OSX #17

mikh3x4 opened this issue Nov 29, 2015 · 7 comments

Comments

@mikh3x4
Copy link

mikh3x4 commented Nov 29, 2015

I'm quite new to C programming in general so I might be doing something wrong:

I downloaded the zip, and unzipped it and cded into the resulting dictionary.

Run the following commands:
cmake .
make -j 4
make test

The first two completed what appears to be successfully (no mention of errors). But make test says 12 out of 12 test failed and gives the following error:
Errors while running CTest
make: *** [test] Error 8

I'm running OS X 10.11.1 and $c++ --version gives:
Apple LLVM version 7.0.0 (clang-700.1.76)
Target: x86_64-apple-darwin15.0.0
Thread model: posix

Additionally trying the example from the docs gives a massive error:

$c++ -O3 -shared -std=c++11 -I ~/Desktop/pybind11-master/include `python-config --cflags --libs` example.cpp -o example.so
In file included from example.cpp:1:
In file included from /Users/mik/Desktop/pybind11-master/include/pybind11/pybind11.h:26:
In file included from /Users/mik/Desktop/pybind11-master/include/pybind11/cast.h:13:
/Users/mik/Desktop/pybind11-master/include/pybind11/pytypes.h:294:14: error: call to constructor of 'pybind11::int_' is ambiguous
        int_ start(start_), stop(stop_), step(step_);
             ^     ~~~~~~
/Users/mik/Desktop/pybind11-master/include/pybind11/pytypes.h:273:5: note: candidate constructor
    int_(int value) : object(PyLong_FromLong((long) value), false) { }
    ^
/Users/mik/Desktop/pybind11-master/include/pybind11/pytypes.h:274:5: note: candidate constructor
    int_(size_t value) : object(PyLong_FromSize_t(value), false) { }
    ^
/Users/mik/Desktop/pybind11-master/include/pybind11/pytypes.h:270:7: note: candidate is the implicit move constructor
class int_ : public object {
      ^
/Users/mik/Desktop/pybind11-master/include/pybind11/pytypes.h:270:7: note: candidate is the implicit copy constructor
/Users/mik/Desktop/pybind11-master/include/pybind11/pytypes.h:294:29: error: call to constructor of 'pybind11::int_' is ambiguous
        int_ start(start_), stop(stop_), step(step_);
                            ^    ~~~~~
/Users/mik/Desktop/pybind11-master/include/pybind11/pytypes.h:273:5: note: candidate constructor
    int_(int value) : object(PyLong_FromLong((long) value), false) { }
    ^
/Users/mik/Desktop/pybind11-master/include/pybind11/pytypes.h:274:5: note: candidate constructor
    int_(size_t value) : object(PyLong_FromSize_t(value), false) { }
    ^
/Users/mik/Desktop/pybind11-master/include/pybind11/pytypes.h:270:7: note: candidate is the implicit move constructor
class int_ : public object {
      ^
/Users/mik/Desktop/pybind11-master/include/pybind11/pytypes.h:270:7: note: candidate is the implicit copy constructor
/Users/mik/Desktop/pybind11-master/include/pybind11/pytypes.h:294:42: error: call to constructor of 'pybind11::int_' is ambiguous
        int_ start(start_), stop(stop_), step(step_);
                                         ^    ~~~~~
/Users/mik/Desktop/pybind11-master/include/pybind11/pytypes.h:273:5: note: candidate constructor
    int_(int value) : object(PyLong_FromLong((long) value), false) { }
    ^
/Users/mik/Desktop/pybind11-master/include/pybind11/pytypes.h:274:5: note: candidate constructor
    int_(size_t value) : object(PyLong_FromSize_t(value), false) { }
    ^
/Users/mik/Desktop/pybind11-master/include/pybind11/pytypes.h:270:7: note: candidate is the implicit move constructor
class int_ : public object {
      ^
/Users/mik/Desktop/pybind11-master/include/pybind11/pytypes.h:270:7: note: candidate is the implicit copy constructor
3 errors generated.```



@wjakob
Copy link
Member

wjakob commented Nov 29, 2015

Hi,

can you please check if it works with the latest version?

Thanks,
Wenzel

@mikh3x4
Copy link
Author

mikh3x4 commented Nov 29, 2015

With the newest version (commit 7f8d1c2) make test still fails in the same way. The example compiles fine, and works as expected in python 2. Upon trying to import it to python 3 however it gives this error:

>>> import example
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: dynamic module does not define module export function (PyInit_example)```


Thank you for your help

@wjakob
Copy link
Member

wjakob commented Nov 29, 2015

You need to make sure that Python picks up the right revisions of the Python binary and library (these are separate concepts in cmake, and unfortunately it sometimes get confused). It sounds like compilation was done with Python 2, while "make test" erroneously runs Python 3. A plugin can only be compiled for one specific Python version at a time.

@mikh3x4
Copy link
Author

mikh3x4 commented Nov 29, 2015

I looked in CMakeLists.txt but can't find an option to change the python version. I also tried compiling it with a python3 virtenv active, but it didn't work. Where would I be able to find the option to select the python version?

@wjakob
Copy link
Member

wjakob commented Nov 29, 2015

You can use cmake-gui to change the PYTHON* variables and then rebuild. Alternative you can directly edit CmakeCache.txt

On Nov 29, 2015, at 3:40 PM, mikh3x4 notifications@github.com wrote:

I looked in CMakeLists.txt but can't find an option to change the python version. I also tried compiling it with a python3 virtenv active, but it didn't work. Where would I be able to find the option to select the python version?


Reply to this email directly or view it on GitHub https://github.com/wjakob/pybind11/issues/17#issuecomment-160419798.

@mikh3x4
Copy link
Author

mikh3x4 commented Nov 29, 2015

I changed the following lines (187-ish and 343-ish) in CmakeCache.txt:

//Path to a program.
PYTHON_EXECUTABLE:FILEPATH=/usr/local/bin/python3.5

//Path to a file.
PYTHON_INCLUDE_DIR:PATH=/usr/local/Cellar/python3/3.5.0/Frameworks/Python.framework/Versions/3.5/include/python3.5m

//Path to a library.
PYTHON_LIBRARY:FILEPATH=/usr/local/Cellar/python3/3.5.0/Frameworks/Python.framework/Versions/3.5/Python

and

FIND_PACKAGE_MESSAGE_DETAILS_PythonInterp:INTERNAL=[/usr/local/bin/python3.5][v3.5()]
//Details about finding PythonLibs
FIND_PACKAGE_MESSAGE_DETAILS_PythonLibs:INTERNAL=[/usr/local/Cellar/python3/3.5.0/Frameworks/Python.framework/Versions/3.5/Python][/usr/local/Cellar/python3/3.5.0/Frameworks/Python.framework/Versions/3.5/include/python3.5m][v3.5.0()]
//ADVANCED property for variable: PYTHON_EXECUTABLE

Then I rerun the 3 building/testing commands. All 12 test now pass successfully. The import to python 3 still fails. I'm using a brewed python3 if that makes a difference

@wjakob
Copy link
Member

wjakob commented Nov 29, 2015

Hi -- that's good.

However, all the tests do is to import the example library from the configured Python binary and run some tests. If these steps fails when you execute them manually, then something else is fishy -- maybe you're calling the wrong Python binary etc. Please double-check everything. I'm closing this ticket since the remainder does not seem to be a pybind11 issue.

Wenzel

@wjakob wjakob closed this as completed Nov 29, 2015
EricCousineau-TRI referenced this issue in EricCousineau-TRI/pybind11 May 23, 2018
…bject_ref

eigen: Disable dtype=object arrays from being referenced
yantor3d added a commit to yantor3d/cmdc that referenced this issue Jun 7, 2021
If you Google "pybind11 subclass" you will find a couple of threads
on how to solve the problem, none of which worked in this scenario.

The issue on the pybind github about subclasses (below) cites a way
to subclass an existing binding that feels as robust as creating
a class on the fly using type("MyClass", bases, attrs)
 -> pybind/pybind11#1193

Another issue recommends using py:base, which has been deprecated.
 -> pybind/pybind11#17

...also it didn't work.

It seems to me that because we are defining each class as an .inl rather
than a .hpp or .cpp file, they are not aware of each other. To remedy
this, I've included the MDGModifier binding in the MDagModifier file,
with an pre-processor to prevent duplicate entries. Otherwise, the base
class would be omitted in the main.cpp.

I think this solution will work well when we get to other classes with
many subclasses, like the whole MFn* tree.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants