Does it work on apple silicon ? #150
Comments
|
cppyy requires a compiler, so in the case of MacOS, you need to install Xcode. Alternatively, use the conda port, https://anaconda.org/conda-forge/cppyy, although that's 2.4.0, not 3.0.0. |
|
Oky but as I said I also tried with Xcode instead of just using the command lines tools but that doesn't solve the problems I still miss some libraries. And also an intel mac I managed to still get it to work with just the command lines tools the python that came with that computer, but also on that computer doing it with python3.11 didn't work. And I do not really know why |
|
Ah, I didn't read beyond the stack trace... What does this command give: it should point to the standard C++ header files. For me, Apple M1, it gives: As for Python versions, if you change it, the package needs to be reinstalled since one component, CPyCppyy, depends on the specific Python version it's build for. |
|
Oky I get your same output, and I realized that the last time I installed Xcode I think I didn't reinstall all the dependencies for cppyy, but know when I try to do it I get this: Thus I guess I'm doing something wrong at this point but I do not know what |
|
Interesting, as it's still doing nothing more than including standard headers, and finding fault with them. Can you roll back the C++ version used for building clingwrapper? Like so: Which will build using C++17 rather than C++20. |
|
Yeah I still get this error: ``` STDCXX=17 python3 -m pip install cppyy × pip subprocess to install backend dependencies did not run successfully. note: This error originates from a subprocess, and is likely not a problem with pip. × pip subprocess to install backend dependencies did not run successfully. |
|
what version of python are you using ? |
|
Maybe I should also try to delete the command line tools and re install them, this is the version I'm using btw |
I use different versions on different platforms. On my M1 laptop, it defaults to 3.8. However, that has nothing to do with this error: this is purely a C++ build. Is it possible to compile something simple: save the above in a file, test.cxx say, and then: and if that works, try: I'm wondering whether there's a mismatch between the version of clang available through |
|
Yes, indeed compiling it like in the first example work and doing it like in the second one gives me this error: |
|
Btw If I run And then I can compile it with: which indeed works |
|
Also by doing: If I do this I can compile the code and also compile cppyy but when I import it I get: |
|
If anyone can help me or give me suggestions of things to try It would be really appreciated |
|
I encounter a similar situation. The first path above presents in |
|
How did you compile it from source I try running this: |
|
Inside this directory: |
To reinstall I have no idea about your situation. :( limjcst@BendeMacBook-Air ~ % xcrun --show-sdk-path
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
limjcst@BendeMacBook-Air ~ % xcode-select -p
/Library/Developer/CommandLineTools
limjcst@BendeMacBook-Air ~ % clang --version
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: arm64-apple-darwin22.3.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
limjcst@BendeMacBook-Air ~ % c++ --version
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: arm64-apple-darwin22.3.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
limjcst@BendeMacBook-Air ~ % /Library/Developer/CommandLineTools/usr/bin/c++ --version
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: arm64-apple-darwin22.3.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin |
|
Oky no problem I get the same output but corresponding to the Xcode innstallation directory: |
|
This is the error I'm getting btw if anyone knows how to solve it please let me know: ``` DEPRECATION: --no-binary currently disables reading from the cache of locally built wheels. In the future --no-binary will not influence the wheel cache. pip 23.1 will enforce this behaviour change. A possible replacement is to use the --no-cache-dir option. You can use the flag --use-feature=no-binary-enable-wheel-cache to test the upcoming behaviour. Discussion can be found at pypa/pip#11453 × pip subprocess to install backend dependencies did not run successfully. |
|
Sorry, a lot to catch up; I've been out of it for a bit. I'm not sure whether compiling from scratch is a good idea, since although yes, the build paths are also saved, it's the system compiler that's still queried for the system paths to set The missing The problem with Rather than building from scratch, can you add the necessary paths to the Or add any necessary paths with |
|
Ah no worry. I tried exporting what you said but it still didn't work and also doing this: Python 3.11.2 (main, Feb 16 2023, 02:55:59) [Clang 14.0.0 (clang-1400.0.29.202)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import cppyy
(Re-)building pre-compiled headers (options:-O2 -isysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1); this may take a minute ...
In file included from input_line_10:9:
In file included from ./etc/dictpch/allHeaders.h:373:
./include/TClassEdit.h:29:10: fatal error: 'cxxabi.h' file not found
#include <cxxabi.h>
^~~~~~~~~~I keep on getting this error even though the file is litteraly in that directory: file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/cxxabi.h
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/cxxabi.h: C++ source text, ASCII text |
|
If pointing to the exact directory, use |
|
Ah sorry my fault indeed if I: It finds the file but I get a different error: python3
Python 3.11.2 (main, Feb 16 2023, 02:55:59) [Clang 14.0.0 (clang-1400.0.29.202)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import cppyy
(Re-)building pre-compiled headers (options:-O2 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1); this may take a minute ...
In file included from input_line_1:1:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/new:93:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/cstdlib:86:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/stdlib.h:148:34: error: unknown type name 'ldiv_t'
inline _LIBCPP_INLINE_VISIBILITY ldiv_t div(long __x, long __y) _NOEXCEPT {
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/stdlib.h:149:12: error: no member named 'ldiv' in the global namespace
return ::ldiv(__x, __y);
~~^ |
|
hey 👋 running up against the same problems, anyone have a solution? |
|
btw nprocs=32 ate the cpu (on my pretty beefy m1 mac), so everyone be careful w/ the copy pasta ;) 
|
|
Yes, As for a solution, no: without a reproducer, I can't think of any. I use my Mac M1 as a development platform and I haven't encountered this problem yet ... There must be something fundamentally different, maybe multiple SDKs installed or some version differences or other, but I have no clue on how to start debugging that. |
|
Fails on m2 for me with this then |
|
Fails for me too, om Apple Silicon M2. Any idea how to fix it, or any workaround? |
|
A possible workaround is to set the For an actual fix, I'd need to be able to reproduce it first, which so far, I've been unable to. :( |
|
I think that it's related (or at least worth looking at in the context of the other comments), especially since the title of the issue explicitly asks if it works on ARM. |
|
It does work on ARM: I'm developing on an M1. :) Works fine, except for exception thrown from JITed code. Both issues reported here are something with the build environment, and the two build environments are different. The Ubuntu case fails to compile the code; the X-code one fails to find the location of the headers at run-time (but builds fine). I can't reproduce the problem on M1; haven't tried yet on Ubuntu. |
|
Tried many different things, and finally this works on my M1:
|
|
got the error If I just do
|
|
in my case, I tried to install cppyy then realized it needs xcode. I also tried setting EXTRA_CLING_ARGS to different things, and xcode-select --switch to different path, then ran into different errors. Current config is: $ xcrun --show-sdk-path and I am using venv |
|
Thank you, that's an interesting one: is a completely different location than what I have: The point being that this portion That still doesn't explain why setting |
Try $sudo xcode-select --switch /Library/Developer/CommandLineTools then pip install using the said command again, that's more likely to help |
|
No good. On either x86_64 or Silicon. |
Did you try pip install using the said command: |
|
|
On an Apple M1 laptop (Ventura 13.4) on which cppyy previously worked, I started getting the same error as the OP (it was a few months since it last worked, so not sure what changed). The suggestion to install cppyy-cling from source and with After upgrading Xcode from 14.3.1 to 15.0 (and starting Xcode to allow it to install components; also Ventura was upgraded to 13.6), however, I get a much shorter error containing only the first part (in fresh venv and after I note that this lacks the I get the exact same error regardless of whether Further examining the error upon LC_ALL=C /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -xc++ -E -v /dev/null 2>&1 | sed -n -e '/^.*include/,${' -e '/^ \/.*++/p' -e '}'is indeed empty. Removing the LC_ALL=C /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -xc++ -E -v /dev/nullis the following: I note the absence of an include directory ending in Importantly, if I run the equivalent command through This is despite the fact that With this output, adding back the Finally, for reference, the same command produces the following when (EDIT: Previously I mistakenly repeated the output for the Xcode.app case here.) And the So I'm wondering if the header directory detection could be fixed so that it goes through (And if that is a viable fix, it might allow cppyy to work with just CommandLineTools in the absence of Xcode, which would be a very nice thing.) |
|
According to
It should be noted that setting |
|
Thanks @marktsuchida! Using |
|
@wlav What is the symptom when the C headers are not found? (In my case, BTW I corrected a copy-paste error in my long post above (noted inline). |
|
Yes, it's a problem still will SDKROOT. Incidentally, it's now fixed (for me anyway) in repo. I'm still having trouble with the wheels from the CI, though: even as it's build for Mac ARM, the binaries are the wrong architecture. I kind of like the idea of having the CI build the wheels as the environment doesn't risk being polluted by any development setup I may have, but none of the wheels thus produced yet work on any platform (I still have to test the Windows' ones, maybe I get lucky). I'm wondering whether I should simply give up on that. :/ |
|
Ah, so the PyPI wheels are manually built? I feel your pain.... |
|
I always did so far, but then a CI recipe was contributed, so I thought that would be great. However, I'm finding the CI to be far more unwieldy than building manually. :( The problem with Cling is that it will bake in the local build paths as an additional way to find things like include headers etc. I.e., when building and running on my own machines, the result is guaranteed to work more often when I test it locally than on any other, different setup. I.e. a clean, alternate, build environment that doesn't favor my own would be preferable to guarantee portability. But the github CI build runners are all over the place. |
|
All that said, I really do hope that this particular issue itself is solved now that I patched cling to use |
Awesome, thanks so much! Let me know if there is a good way for me to test now, or I'll look forward to the next release. Hopefully the run-time discovery ( |
|
is that fix live? if not, please let us know when it is, can't wait to try it! we switched to pybind11 for one project, b/c of this issue, and ugh it was painful. would really love to stick with cppyy |
|
@Alex-EEE: it's in the repo. I'm fighting the CI ... one other thing that would be great if that were functional, is that I could just point you to the artifacts to download. I'm currently re-writing the workflow using the scikit-learn one as an example. |
|
The CI path isn't going to work out: the ARM target is a cross-compilation, but the build process creates small helper executables. Presumably, it's possible to compile the latter for the host, while compiling the rest for ARM, but I'm giving up for now. The build process will be simplified once the move to Clang-REPL is complete. For now, here's a wheel that should work, however. Appreciate feedback: If confirmed, I can finally cut a new release... (Edit just to say not to worry about pip complaining about version numbers when installing the above wheel. It's ABI compatible.) |
|
Looks like this works for me! With the latest cppyy installed normally from PyPI (showing failure case first, then the workaround, then the new cppyy-cling), $ pip list
Package Version
------------- -------
cppyy 3.0.0
cppyy-backend 1.14.11
cppyy-cling 6.28.0
CPyCppyy 1.12.13
pip 23.3
setuptools 68.2.2
$ python
Python 3.11.5 (main, Aug 24 2023, 15:09:45) [Clang 14.0.3 (clang-1403.0.22.14.1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import cppyy
ERROR in cling::CIFactory::createCI(): cannot extract standard library include paths!
Invoking:
LC_ALL=C /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -xc++ -E -v /dev/null 2>&1 | sed -n -e '/^.*include/,${' -e '/^ \/.*++/p' -e '}'
Results was:
With exit code 0
>>> ^D
$ SDKROOT=$(xcrun --show-sdk-path) python
Python 3.11.5 (main, Aug 24 2023, 15:09:45) [Clang 14.0.3 (clang-1403.0.22.14.1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import cppyy
>>> ^D
$ pip install https://cern.ch/wlav/cppyy_cling-6.28.6-py2.py3-none-macosx_11_0_arm64.whl
Collecting cppyy-cling==6.28.6
Using cached https://cern.ch/wlav/cppyy_cling-6.28.6-py2.py3-none-macosx_11_0_arm64.whl (27.9 MB)
Installing collected packages: cppyy-cling
Attempting uninstall: cppyy-cling
Found existing installation: cppyy-cling 6.28.0
Uninstalling cppyy-cling-6.28.0:
Successfully uninstalled cppyy-cling-6.28.0
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
cppyy-backend 1.14.11 requires cppyy-cling==6.28.0, but you have cppyy-cling 6.28.6 which is incompatible.
cpycppyy 1.12.13 requires cppyy-cling==6.28.0, but you have cppyy-cling 6.28.6 which is incompatible.
cppyy 3.0.0 requires cppyy-cling==6.28.0, but you have cppyy-cling 6.28.6 which is incompatible.
Successfully installed cppyy-cling-6.28.6
$ python
Python 3.11.5 (main, Aug 24 2023, 15:09:45) [Clang 14.0.3 (clang-1403.0.22.14.1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import cppyy
(Re-)building pre-compiled headers (options: -O2); this may take a minute ...
>>> I got the same result with |
|
Should all be good now with release 3.1.0. Feel free to reopen if you find otherwise. |
As the ns-3 maintainer for build/python/platform-specific stuff:
|
|
About 2, I built from master and still had the issue running first.py |
You can report these issues in https://groups.google.com/u/0/g/ns-3-users, or https://gitlab.com/nsnam/ns-3-dev/-/issues, not to pollute the cppyy tracker. The intended way for people that are not really sure what they are doing to consume the ns-3 bindings is via pip. :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm on an M1 macbook and I was wondering if it works on apple silicon too. Because for some reason when I import cppyy I get this error:
I tried also installing Xcode but I still get an error. I also tried on another mac that wans't running apple silicon and it worked until I changed to a newer version of python that I installed with brew. Therefore I tried to run it on my mac on a virtual enviroment with the python that comes inlcuded which is Python 3.9.6 but it still didn't work. Maybe I'm missing something. If anyone needs other info I'll provide it. Thanks in advance
The text was updated successfully, but these errors were encountered: