Support MuJoCo 2.1.1 (including arm64 mac support) #662
Comments
|
Last update: 2022/05/24 (for Mujoco 2.2.x release), see this comment Workaround: mujoco-py installation for Mujoco 2.1.1Until First, make sure your python is running as arm64 (NOT x86_64 under Rosetta 2). For instance, you can use miniforge3. Now run the following: mkdir -p $HOME/.mujoco/mujoco210 # Remove existing installation if any
ln -sf /Applications/MuJoCo.app/Contents/Frameworks/MuJoCo.framework/Versions/Current/Headers/ $HOME/.mujoco/mujoco210/include
mkdir -p $HOME/.mujoco/mujoco210/bin
ln -sf /Applications/MuJoCo.app/Contents/Frameworks/MuJoCo.framework/Versions/Current/libmujoco.2.*.dylib $HOME/.mujoco/mujoco210/bin/libmujoco210.dylib
ln -sf /Applications/MuJoCo.app/Contents/Frameworks/MuJoCo.framework/Versions/Current/libmujoco.2.*.dylib /usr/local/lib/
# For M1 (arm64) mac users:
# The released binary doesn't ship glfw3, so need to install on your own
brew install glfw
ln -sf /opt/homebrew/lib/libglfw.3.dylib $HOME/.mujoco/mujoco210/bin
# Please make sure /opt/homebrew/bin/gcc-11 exists: install gcc if you haven't already
# brew install gcc
export CC=/opt/homebrew/bin/gcc-11 # see https://github.com/openai/mujoco-py/issues/605
pip install mujoco-py && python -c 'import mujoco_py'Note / Troubleshoothing:
Done!After this step, you should be able to run MuJoCo on a Apple Silicon Mac!
|
|
Thanks for the tutorial! My brew packages installed to different paths than the ones above, so I had to make the following adjustments: # glfw
ln -sf /usr/local/Cellar/glfw/3.3.6/lib/libglfw.3.3.dylib $HOME/.mujoco/mujoco210/bin
# gcc
export CC=/usr/local/Cellar/gcc/11.2.0_3/bin/gcc-11 |
|
I got this error, even though everything compiled smoothly. I suspect this is because I am using the x86_64 emulation mode on m1. I'll try again in arm64 mode. |
|
If you are using an Intel mac, glfw installation path would be different. Please feel free to change the path accordingly. BTW, it is very recommended to have the The x86_64 binary requires AVX instruction, which is not supported on M1 machines. The only way is to use arm64 python: UPDATE: miniconda3 has arm64 support since 2021-11-08. |
|
Thanks for the tip! I got it running. There were some things I had to undo to get it working.
After doing these changes, my paths exactly matched the original post's paths. Then everything works. |
|
`RuntimeError: Could not find supported GCC executable. HINT: On OS X, install GCC 9.x with brew install gcc@9. or port install gcc9` I'm getting this error when I try to run |
|
Did you make sure the CC variable was set, i.e. |
|
Yeah my bad made a spelling mistake. But now I have a different error when I try to import MuJoCo_py
I'm using x86 anaconda on rosseta, that might be the issue I'll try uninstalling that and try installing conda-forge native version. |
|
anaconda is not native for m1 and its trying to compile mujoco_py for x86. Uninstalling anaconda and installing miniforge3 which is native for m1 solved the error. |
|
Thanks for the tutorial!! |
Even after following these steps, I am getting the following error: What might be the issue here? |
Got it to work in intel mac by changing the version in the symbolic link to .3 rather than 3.3, ie.:
|
|
I get the following error on trying to run mujoco_py on mac_osx |
|
@wookayin Thank you so much for putting in a workaround for now. In my case, |
|
killed python -c 'import mujoco_py' Does anyone have idea? Thanks. |
|
I followed the steps indicated by @wookayin and it worked perfectly in my Macbook m1 max machine running Monterey 12.2.1. After a couple of weeks when I updated my mac to the Monterey beta 12.3 version, I begin to get |
What if I need to mujoco 1.5 (aka mjpro150) for gym, does the same workaround work? |
|
I got |
@zdhNarsil I suggest you need to first go to confirm if you have installed the |
|
I've done all the setups suggested by @wookayin but still getting this error: But none of them works... Do you have nny ideas? The full error message is: |
|
I was also getting the error I was using Mujoco-2.1.3. Then I deleted it and downloaded mujoco-2.1.1-macos-universal2.dmg. I copied the MuJoCo.app to /Applications and double-clicked it to open the app. I ran the installation script again and it worked. (I'm using miniforge3, python=3.9.1, macOS Monterey 12.1.) |
|
@liusf15 It really works!!!!! Thank a lot!! |
|
I updated my instruction above to catch up with the recent Mujoco v2.2.0 release. Summary of changes are:
UPDATE: It looks like the ABI of Mujoco 2.2.0 is NOT compatible with mujoco-py, resulting in Segmentation fault: Until somebody figure out a workaround, please stick to mujoco 2.1.1 to use the obsolete mujoco-py bindings. The installation instruction will work for both versions. |
|
In 2022, gym has migrated to use the official mujoco python bindings from mujoco-py: openai/gym#2762 (which was just merged today). From README:
If you plan to use MuJoCo 2.2.0, please use gym v0.24.0 (which will be released soon). This workaround is only valid for MuJoCo 2.1.x. |
|
I was having trouble installing |
|
I was having trouble installing process when test with the following code, |
I guess only 2.1.1 works. Failed to install for 2.2.0 due to gcc compiler error. |
|
I try it again, and find the issue which may be resulting in the above errors. |
|
This comment seems to be working. Can we at least include it in the README file so people can find it easily? |
|
Import error. Trying to rebuild mujoco_py. you know why i get this erorr, i have a mac M1 pro |
|
you should pip uninstall mujoco first |
|
I have followed all the install instructions and still I am getting the error, below is the error message Previously I was getting the error related to gcc, 
Chip: Mac M1 pro |
|
I met an error: |
i use miniforge3 but seems that the problem is still there. how do you fix it? |
% python -c 'import mujoco_py'
Compiling /Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/cymj.pyx because it changed.
[1/1] Cythonizing /Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/cymj.pyx
performance hint: /Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/cymj.pyx:67:5: Exception check on 'c_warning_callback' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'c_warning_callback' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'c_warning_callback' to allow an error code to be returned.
performance hint: /Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/cymj.pyx:104:5: Exception check on 'c_error_callback' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'c_error_callback' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'c_error_callback' to allow an error code to be returned.
Error compiling Cython file:
------------------------------------------------------------
...
See c_warning_callback, which is the C wrapper to the user defined function
'''
global py_warning_callback
global mju_user_warning
py_warning_callback = warn
mju_user_warning = c_warning_callback
^
------------------------------------------------------------
/Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/cymj.pyx:92:23: Cannot assign type 'void (const char *) except * nogil' to 'void (*)(const char *) noexcept nogil'. Exception values are incompatible. Suggest adding 'noexcept' to type 'void (const char *) except * nogil'.
Error compiling Cython file:
------------------------------------------------------------
...
See c_warning_callback, which is the C wrapper to the user defined function
'''
global py_error_callback
global mju_user_error
py_error_callback = err_callback
mju_user_error = c_error_callback
^
------------------------------------------------------------
/Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/cymj.pyx:127:21: Cannot assign type 'void (const char *) except * nogil' to 'void (*)(const char *) noexcept nogil'. Exception values are incompatible. Suggest adding 'noexcept' to type 'void (const char *) except * nogil'.
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/__init__.py", line 2, in <module>
from mujoco_py.builder import cymj, ignore_mujoco_warnings, functions, MujocoException
File "/Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/builder.py", line 504, in <module>
cymj = load_cython_ext(mujoco_path)
File "/Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/builder.py", line 110, in load_cython_ext
cext_so_path = builder.build()
File "/Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/builder.py", line 226, in build
built_so_file_path = self._build_impl()
File "/Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/builder.py", line 343, in _build_impl
so_file_path = super()._build_impl()
File "/Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/builder.py", line 239, in _build_impl
dist.ext_modules = cythonize([self.extension])
File "/Users/tridu33/.local/lib/python3.10/site-packages/Cython/Build/Dependencies.py", line 1154, in cythonize
cythonize_one(*args)
File "/Users/tridu33/.local/lib/python3.10/site-packages/Cython/Build/Dependencies.py", line 1321, in cythonize_one
raise CompileError(None, pyx_file)
Cython.Compiler.Errors.CompileError: /Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/cymj.pyx
tridu33@tridu33deMacBook-Pro Downloads % where gcc-111
gcc-111 not found
tridu33@tridu33deMacBook-Pro Downloads % where gcc-11
/opt/homebrew/bin/gcc-11
tridu33@tridu33deMacBook-Pro Downloads % export CC=/opt/homebrew/bin/gcc-11
tridu33@tridu33deMacBook-Pro Downloads % python -c 'import mujoco_py'
Compiling /Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/cymj.pyx because it changed.
[1/1] Cythonizing /Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/cymj.pyx
performance hint: /Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/cymj.pyx:67:5: Exception check on 'c_warning_callback' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'c_warning_callback' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'c_warning_callback' to allow an error code to be returned.
performance hint: /Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/cymj.pyx:104:5: Exception check on 'c_error_callback' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'c_error_callback' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'c_error_callback' to allow an error code to be returned.
Error compiling Cython file:
------------------------------------------------------------
...
See c_warning_callback, which is the C wrapper to the user defined function
'''
global py_warning_callback
global mju_user_warning
py_warning_callback = warn
mju_user_warning = c_warning_callback
^
------------------------------------------------------------
/Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/cymj.pyx:92:23: Cannot assign type 'void (const char *) except * nogil' to 'void (*)(const char *) noexcept nogil'. Exception values are incompatible. Suggest adding 'noexcept' to type 'void (const char *) except * nogil'.
Error compiling Cython file:
------------------------------------------------------------
...
See c_warning_callback, which is the C wrapper to the user defined function
'''
global py_error_callback
global mju_user_error
py_error_callback = err_callback
mju_user_error = c_error_callback
^
------------------------------------------------------------
/Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/cymj.pyx:127:21: Cannot assign type 'void (const char *) except * nogil' to 'void (*)(const char *) noexcept nogil'. Exception values are incompatible. Suggest adding 'noexcept' to type 'void (const char *) except * nogil'.
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/__init__.py", line 2, in <module>
from mujoco_py.builder import cymj, ignore_mujoco_warnings, functions, MujocoException
File "/Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/builder.py", line 504, in <module>
cymj = load_cython_ext(mujoco_path)
File "/Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/builder.py", line 110, in load_cython_ext
cext_so_path = builder.build()
File "/Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/builder.py", line 226, in build
built_so_file_path = self._build_impl()
File "/Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/builder.py", line 343, in _build_impl
so_file_path = super()._build_impl()
File "/Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/builder.py", line 239, in _build_impl
dist.ext_modules = cythonize([self.extension])
File "/Users/tridu33/.local/lib/python3.10/site-packages/Cython/Build/Dependencies.py", line 1154, in cythonize
cythonize_one(*args)
File "/Users/tridu33/.local/lib/python3.10/site-packages/Cython/Build/Dependencies.py", line 1321, in cythonize_one
raise CompileError(None, pyx_file)
Cython.Compiler.Errors.CompileError: /Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/cymj.pyx
tridu33@tridu33deMacBook-Pro Downloads % rm -rf $HOME/.miniforge3/lib/python3.9/site-packages/mujoco_py/generated/*extensionbuilder*
tridu33@tridu33deMacBook-Pro Downloads % ln -sf /usr/local/Cellar/glfw/3.3.6/lib/libglfw.3.3.dylib $HOME/.mujoco/mujoco210/bin
tridu33@tridu33deMacBook-Pro Downloads % python -c 'import mujoco_py'
Compiling /Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/cymj.pyx because it changed.
[1/1] Cythonizing /Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/cymj.pyx
performance hint: /Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/cymj.pyx:67:5: Exception check on 'c_warning_callback' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'c_warning_callback' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'c_warning_callback' to allow an error code to be returned.
performance hint: /Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/cymj.pyx:104:5: Exception check on 'c_error_callback' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'c_error_callback' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'c_error_callback' to allow an error code to be returned.
Error compiling Cython file:
------------------------------------------------------------
...
See c_warning_callback, which is the C wrapper to the user defined function
'''
global py_warning_callback
global mju_user_warning
py_warning_callback = warn
mju_user_warning = c_warning_callback
^
------------------------------------------------------------
/Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/cymj.pyx:92:23: Cannot assign type 'void (const char *) except * nogil' to 'void (*)(const char *) noexcept nogil'. Exception values are incompatible. Suggest adding 'noexcept' to type 'void (const char *) except * nogil'.
Error compiling Cython file:
------------------------------------------------------------
...
See c_warning_callback, which is the C wrapper to the user defined function
'''
global py_error_callback
global mju_user_error
py_error_callback = err_callback
mju_user_error = c_error_callback
^
------------------------------------------------------------
/Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/cymj.pyx:127:21: Cannot assign type 'void (const char *) except * nogil' to 'void (*)(const char *) noexcept nogil'. Exception values are incompatible. Suggest adding 'noexcept' to type 'void (const char *) except * nogil'.
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/__init__.py", line 2, in <module>
from mujoco_py.builder import cymj, ignore_mujoco_warnings, functions, MujocoException
File "/Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/builder.py", line 504, in <module>
cymj = load_cython_ext(mujoco_path)
File "/Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/builder.py", line 110, in load_cython_ext
cext_so_path = builder.build()
File "/Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/builder.py", line 226, in build
built_so_file_path = self._build_impl()
File "/Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/builder.py", line 343, in _build_impl
so_file_path = super()._build_impl()
File "/Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/builder.py", line 239, in _build_impl
dist.ext_modules = cythonize([self.extension])
File "/Users/tridu33/.local/lib/python3.10/site-packages/Cython/Build/Dependencies.py", line 1154, in cythonize
cythonize_one(*args)
File "/Users/tridu33/.local/lib/python3.10/site-packages/Cython/Build/Dependencies.py", line 1321, in cythonize_one
raise CompileError(None, pyx_file)
Cython.Compiler.Errors.CompileError: /Users/tridu33/.local/lib/python3.10/site-packages/mujoco_py/cymj.pyx |
|
@Tridu33 Were you able to resolve this issue? What was the fix? |
and others
I hope this can be a tracking issue for supporting MuJoCo 2.1.1, which was just released few hours ago. There are some incompatible changes, so the python binding
mujoco-pyalso needs to catch up those changes.Required changes include:
lib/libmujoco.so(previouslybin/libmujoco210.so)$HOME/.mujoco/mujoco211per the convention. However, this naming convention is because of the directory name in the archive, which ismujoco210; the new release 2.1.1 no longer uses this convention. Therefore mujoco installation path might also need to be changed (discussion/opinion needed).$HOME/.mujoco. The standard MuJoCo installation path on MacOS systems seems undetermined yet, so we might need to wait a bit more to hear from DeepMind.In addition, the builder script also needs to be updated because currently GCC only up to v9 is supported: #605.
I already managed to make mujoco-py work locally on my M1 machines, so creating and submitting a patch will be quite straightforward but we'll have to make a few decisions.
The text was updated successfully, but these errors were encountered: