You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Ask] Update to latest MuJoCo (or at least >=3.2.5) to enable new model editing capabilities #119
With version >=3.2.5 of MuJoCo the mjSpec and model editing API are stable and it would be nice to make these features available in Julia.
Would that be a breaking change or is it easy to do?
I saw that MuJoCo_jll is managed by Yggdrasil, but there exist also a list of prebuilt libraries. I am not sure where best to start ...
I am also happy to assist but I thought @JamieMair you might be more familiar with the build pipeline and its pitfalls :)
Essentially just update the git commit, version etc. and run the scripts to make sure the build succeeds. This may need some manual fixes to the mujoco codebase to get it to compile. This can be quite involved.
Once the binaries are done and released, the main wrapper package can be updated by updating the version of the jll and then rerunning the generate.jl script and running the tests.
I will do this eventually if you can wait, but it might be a month or so until I get the time to work on this.
I will give it a try on my local machine first, see how things go and report back.
Then I guess the way to go, is to open a new branch and eventually create the pull request at Yggdrasil to have a better way to discuss changes etc.
I was able to build for all linux platforms via the build_tarballs.jl configuration and without the patches.
I tried the aarch64 macOS and could build it to a certain degree without the patch files.
The current error I get is the following: ld: could not parse object file CMakeFiles/mujoco.dir/src/engine/engine_callback.c.o: 'Invalid value (Producer: 'LLVM16.0.6' Reader: 'LLVM 8.0.0svn')', using libLTO version 'LLVM version 8.0.0svn' file 'CMakeFiles/mujoco.dir/src/engine/engine_callback.c.o' for architecture arm64
I was trying to build it without the patches because on my local MacOS machine I was able to build without any problems.
Unfortunately I did not yet had the time to figure out what has to be changed in the BinaryBuilder toolchain configuration to get a similar build result compared to a plain MacOS build based on the MuJoCo instructions.
Windows does not build with or without patches. However, I haven't had a very close look.
I think It needs a specific version of the Windows SDK passed as an Option: -DCMAKE_SYSTEM_VERSION="10.0.26100.0"
And there are some Warnings treated as errors which are fixed in the patch file. The problem is, that the patch can not be applied anymore with the latest version.
Sadly, I did not had the capacity to dive deeper and fix the issues...
Hi, thanks for all your effort on this - as you have seen, building the binaries can be a real hassle. I tried this around a week ago on my end and found similar things - except that the macOS builds always fail for me under cross compilation (host on x86 linux).
When I get some more time, I'll look into trying to get the JLLs built for all platforms, as I don't want to do a release before all major platforms are supported. Luckily, this is the most time-intensive part and updating the package once the JLLs are built is reasonably simple.
As a work around could it be an option to extract the prebuilt libraries for MacOS and Windows from the official mujoco releases and wrap them into the JLL?
They are well tested and I can confirm that the Mac version works.
It is not the purpose of Yggdrasil/BinaryBuilder, but maybe this can be a valid exception, until the issues are fixed in the build.
We could probably do this for the Windows build, but the macOS installs use .dmg, not a .tar.gz - which is what we need to package the JLL - so I don't think this would be possible. Unfortunately, I think this will have to be done the hard way to get the original libraries built using the BinaryBuilder pipeline.
I just wanted to update this thread - I have been trying this on and off in my spare time, but there are significant issues with the build environment. At the moment only Linux builds in the environment that the build script will run - cross compilation fails. I think significant changes and patches to the mujoco source are required to get cross compilation to function correctly in the BinaryBuilder.jl environment. If someone has more time to attempt this, they can try to submit a PR to update the build_tarballs.jl file. If this gets updated, I'll dedicate some time to updating the generate script to update the bindings and the main package.
I did not give up on the approach to extract the official prebuilt binaries and package it into the JLL as a workaround. In theory this is possible with 7z or dmg2img, but I did not had time to do it yet. Not sure when I will manage to try it but I will report if my experiment succeeds.
Activity
JamieMair commentedon Jul 8, 2025
Hi @fkroll,
Yes this sounds like a good idea. The main bulk of the work is to compile the binaries. The script to do this uses BinaryBuilder.jl and is found here - https://github.com/JuliaPackaging/Yggdrasil/blob/master/M/MuJoCo/build_tarballs.jl
Essentially just update the git commit, version etc. and run the scripts to make sure the build succeeds. This may need some manual fixes to the mujoco codebase to get it to compile. This can be quite involved.
Once the binaries are done and released, the main wrapper package can be updated by updating the version of the jll and then rerunning the generate.jl script and running the tests.
I will do this eventually if you can wait, but it might be a month or so until I get the time to work on this.
Let me know if you decide to have a go at this.
Best,
Jamie
fkroll commentedon Jul 8, 2025
Hi Jamie,
thank you for the fast feedback!
I will give it a try on my local machine first, see how things go and report back.
Then I guess the way to go, is to open a new branch and eventually create the pull request at Yggdrasil to have a better way to discuss changes etc.
Best,
Felix
JamieMair commentedon Jul 10, 2025
Sounds good.
Get it touch if you have any questions - I am happy to help!
BW,
Jamie
fkroll commentedon Jul 16, 2025
Here are my findings so far:
I was able to build for all linux platforms via the
build_tarballs.jlconfiguration and without the patches.I tried the aarch64 macOS and could build it to a certain degree without the patch files.
The current error I get is the following:
ld: could not parse object file CMakeFiles/mujoco.dir/src/engine/engine_callback.c.o: 'Invalid value (Producer: 'LLVM16.0.6' Reader: 'LLVM 8.0.0svn')', using libLTO version 'LLVM version 8.0.0svn' file 'CMakeFiles/mujoco.dir/src/engine/engine_callback.c.o' for architecture arm64I was trying to build it without the patches because on my local MacOS machine I was able to build without any problems.
Unfortunately I did not yet had the time to figure out what has to be changed in the
BinaryBuildertoolchain configuration to get a similar build result compared to a plain MacOS build based on the MuJoCo instructions.Windows does not build with or without patches. However, I haven't had a very close look.
I think It needs a specific version of the Windows SDK passed as an Option:
-DCMAKE_SYSTEM_VERSION="10.0.26100.0"And there are some Warnings treated as errors which are fixed in the patch file. The problem is, that the patch can not be applied anymore with the latest version.
Sadly, I did not had the capacity to dive deeper and fix the issues...
This is the current version of the
build_tarballs.jlJamieMair commentedon Jul 29, 2025
Hi, thanks for all your effort on this - as you have seen, building the binaries can be a real hassle. I tried this around a week ago on my end and found similar things - except that the macOS builds always fail for me under cross compilation (host on x86 linux).
When I get some more time, I'll look into trying to get the JLLs built for all platforms, as I don't want to do a release before all major platforms are supported. Luckily, this is the most time-intensive part and updating the package once the JLLs are built is reasonably simple.
fkroll commentedon Jul 31, 2025
As a work around could it be an option to extract the prebuilt libraries for MacOS and Windows from the official mujoco releases and wrap them into the JLL?
They are well tested and I can confirm that the Mac version works.
It is not the purpose of Yggdrasil/BinaryBuilder, but maybe this can be a valid exception, until the issues are fixed in the build.
JamieMair commentedon Aug 1, 2025
We could probably do this for the Windows build, but the macOS installs use .dmg, not a .tar.gz - which is what we need to package the JLL - so I don't think this would be possible. Unfortunately, I think this will have to be done the hard way to get the original libraries built using the BinaryBuilder pipeline.
JamieMair commentedon Nov 5, 2025
I just wanted to update this thread - I have been trying this on and off in my spare time, but there are significant issues with the build environment. At the moment only Linux builds in the environment that the build script will run - cross compilation fails. I think significant changes and patches to the mujoco source are required to get cross compilation to function correctly in the BinaryBuilder.jl environment. If someone has more time to attempt this, they can try to submit a PR to update the build_tarballs.jl file. If this gets updated, I'll dedicate some time to updating the generate script to update the bindings and the main package.
fkroll commentedon Nov 5, 2025
Thank you for your effort!
I did not give up on the approach to extract the official prebuilt binaries and package it into the JLL as a workaround. In theory this is possible with 7z or dmg2img, but I did not had time to do it yet. Not sure when I will manage to try it but I will report if my experiment succeeds.