This is what it says in the console
[13:53:46] [main/INFO] (FabricLoader/GameProvider) Loading Minecraft 1.19 with Fabric Loader 0.14.9
[13:53:46] [main/WARN] (FabricLoader/Resolution) Mod resolution failed
[13:53:46] [main/INFO] (FabricLoader/Resolution) Immediate reason: [HARD_DEP_NO_CANDIDATE example 1.0.0 {depends fabric-api # [*]}, ROOT_FORCELOAD_SINGLE example 1.0.0]
[13:53:46] [main/INFO] (FabricLoader/Resolution) Reason: [HARD_DEP example 1.0.0 {depends fabric-api # [*]}]
[13:53:46] [main/INFO] (FabricLoader/Resolution) Fix: add [add:fabric-api 1 ([(-∞,∞)])], remove [], replace []
[13:53:46] [main/ERROR] (FabricLoader) Incompatible mod set!
net.fabricmc.loader.impl.FormattedException: Mod resolution encountered an incompatible mod set!
A potential solution has been determined:
- Install fabric-api, any version.
Unmet dependency listing:
- Mod 'Example Mod' (example) 1.0.0 requires any version of fabric-api, which is missing!
at net.fabricmc.loader.impl.FabricLoaderImpl.load(FabricLoaderImpl.java:190) ~[fabric-loader-0.14.9.jar:?]
at net.fabricmc.loader.impl.launch.knot.Knot.init(Knot.java:148) ~[fabric-loader-0.14.9.jar:?]
at net.fabricmc.loader.impl.launch.knot.Knot.launch(Knot.java:68) [fabric-loader-0.14.9.jar:?]
at net.fabricmc.loader.impl.launch.knot.KnotClient.main(KnotClient.java:23) [fabric-loader-0.14.9.jar:?]
at net.fabricmc.devlaunchinjector.Main.main(Main.java:86) [dev-launch-injector-0.2.1+build.8.jar:?]
Process finished with exit code 1
when I try to run it as a minecraft client, a fabric-api window opens with this error message
Incompatible mod set!
net.fabricmc.loader.impl.FormattedException: Mod resolution encountered an incompatible mod set!
A potential solution has been determined:
- Install fabric-api, any version.
Unmet dependency listing:
- Mod 'Example Mod' (example) 1.0.0 requires any version of fabric-api, which is missing!
at net.fabricmc.loader.impl.FabricLoaderImpl.load(FabricLoaderImpl.java:190)
at net.fabricmc.loader.impl.launch.knot.Knot.init(Knot.java:148)
at net.fabricmc.loader.impl.launch.knot.Knot.launch(Knot.java:68)
at net.fabricmc.loader.impl.launch.knot.KnotClient.main(KnotClient.java:23)
at net.fabricmc.devlaunchinjector.Main.main(Main.java:86)
I have installed the right version of fabric-api after I got that error, and I re-opened the project and tried it again but it didnt work.
As logs said, you need the Fabric API in any version.
This requirement is made by your plugin, in your fabric.mod.json file.
Related
I'm attempting to set up this Rust template project to get started doing Rust development for ESP32: https://github.com/esp-rs/esp-idf-template
I've installed the Rustup esp toolchain, as described here: https://github.com/esp-rs/rust-build
At the Generate the Project step, I chose these parameters:
Configure project to use Dev Containers = false
ESP-IDF native build version = v4.4
Rust toolchain = esp
STD Support = true
MCU = esp32
At the Build step, I get this output (second run displayed, first run compiles a long list of dependencies before this point):
C:\Users\Me\boop\doop>cargo build
Compiling esp-idf-sys v0.31.6
error: failed to run custom build command for `esp-idf-sys v0.31.6`
Caused by:
process didn't exit successfully: `C:\Users\Me\boop\doop\target\debug\build\esp-idf-sys-cafd80a349bfdbb2\build-script-build` (exit code: 1)
--- stdout
cargo:rerun-if-env-changed=IDF_PATH
cargo:rerun-if-env-changed=ESP_IDF_TOOLS_INSTALL_DIR
cargo:rerun-if-env-changed=ESP_IDF_VERSION
cargo:rerun-if-env-changed=ESP_IDF_REPOSITORY
cargo:rerun-if-env-changed=ESP_IDF_SDKCONFIG_DEFAULTS
cargo:rerun-if-env-changed=ESP_IDF_SDKCONFIG
cargo:rerun-if-env-changed=MCU
IDF_PYTHON_ENV_PATH=C:\Users\Me\boop\doop\.embuild\espressif\python_env\idf4.4_py3.10_env
PATH=C:\Users\Me\boop\doop\.embuild\espressif\tools\esp32ulp-elf\2.28.51-esp-20191205\esp32ulp-elf-binutils\bin;C:\Users\Me\boop\doop\.embuild\espressif\tools\cmake\3.23.1\bin;C:\Users\Me\boop\doop\.embuild\espressif\tools\ninja\1.10.2\;C:\Users\Me\boop\doop\.embuild\espressif\python_env\idf4.4_py3.10_env\Scripts;C:\Users\Me\boop\doop\.embuild\espressif\esp-idf\release-v4.4\tools;%PATH%
Current system platform: win64
Skipping xtensa-esp32-elf#esp-2021r2-patch3-8.4.0 (already installed)
Skipping cmake#3.23.1 (already installed)
Skipping ninja#1.10.2 (already installed)
Skipping esp32ulp-elf#2.28.51-esp-20191205 (already installed)
IDF_PYTHON_ENV_PATH=C:\Users\Me\boop\doop\.embuild\espressif\python_env\idf4.4_py3.10_env
PATH=C:\Users\Me\boop\doop\.embuild\espressif\tools\esp32ulp-elf\2.28.51-esp-20191205\esp32ulp-elf-binutils\bin;C:\Users\Me\boop\doop\.embuild\espressif\tools\cmake\3.23.1\bin;C:\Users\Me\boop\doop\.embuild\espressif\tools\ninja\1.10.2\;C:\Users\Me\boop\doop\.embuild\espressif\python_env\idf4.4_py3.10_env\Scripts;C:\Users\Me\boop\doop\.embuild\espressif\esp-idf\release-v4.4\tools;%PATH%
--- stderr
Using managed esp-idf repository: EspIdfRemote { repo_url: None, git_ref: Branch("release/v4.4") }
fatal: No names found, cannot describe anything.
Using esp-idf v4.4.1 at 'C:\Users\Me\boop\doop\.embuild\espressif\esp-idf\release-v4.4'
fatal: No names found, cannot describe anything.
Error: Access is denied. (os error 5)
I get the same error when I choose ESP-IDF native build version = v4.3.2, although without the fatal: No names found, cannot describe anything. messages.
I get an identical error when attempting to build this Rust ESP32 demo project: https://github.com/ivmarkov/rust-esp32-std-demo
This was run as Administrator.
In my search for a solution, I found this: Why os.rename sometimes returns error access is denied python Per the top answer, I disabled "Show frequently used folders in Quick access" in File explorer, but unfortunately the build error has not changed.
What access is being denied, and what could be causing the denial, even when run as Administrator?
Secondarily, what is the cause and meaning of the fatal: No names found, cannot describe anything. messages?
I've been working through the same issue today.
It is caused by a change in the embuild dependency: https://github.com/esp-rs/embuild/commit/d8f8da228f1e1e6c105074d96617a8601092f633
Trying to write permission data to an open file causes the 'os error 5
I've submitted a PR to the project: https://github.com/esp-rs/embuild/pull/56
Now merged, cargo update and you should be good!
I am trying to install ghc-mod so that I can use ide-haskell in Atom.
The instructions say to use stack build ghc-mod. It seems that GHC 8.2+ is not supported by ghc-mod, so I set my resolver to lts-9.21.
When running stack build ghc-mod, I keep getting this error (emphasis mine; not using code formatting because line wrap helps readability):
aeson > : can't load .so/.DLL for: /Users/timoffex/.stack/snapshots/x86_64-osx/db354248ca37308313a93487c93190e1d5b819629b60b38b68871c9a691e52b9/8.0.2/lib/x86_64-osx-ghc-8.0.2/libHStime-locale-compat-0.1.1.3-KZ1jqNx8uhlHjmuPPj6V1Y-ghc8.0.2.dylib (dlopen(/Users/timoffex/.stack/snapshots/x86_64-osx/db354248ca37308313a93487c93190e1d5b819629b60b38b68871c9a691e52b9/8.0.2/lib/x86_64-osx-ghc-8.0.2/libHStime-locale-compat-0.1.1.3-KZ1jqNx8uhlHjmuPPj6V1Y-ghc8.0.2.dylib, 5): REBASE_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB has segment 2 which is not a writable segment (__LINKEDIT) in /Users/timoffex/.stack/snapshots/x86_64-osx/db354248ca37308313a93487c93190e1d5b819629b60b38b68871c9a691e52b9/8.0.2/lib/x86_64-osx-ghc-8.0.2/libHStime-locale-compat-0.1.1.3-KZ1jqNx8uhlHjmuPPj6V1Y-ghc8.0.2.dylib)
... (later)
-- While building package aeson-1.1.2.0 using:
/Users/timoffex/.stack/setup-exe-cache/x86_64-osx/Cabal-simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack-work/dist/x86_64-osx/Cabal-1.24.2.0 build --ghc-options ""
Process exited with code: ExitFailure 1
Progress 1/4
Here's a snippet from the above that looks weird to me:
REBASE_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB has segment 2 which is not a writable segment
I am running macOS Catalina 10.15.3.
I can't find any mention of this online except for this open GitHub issue: https://github.com/facebook/duckling/issues/446
I also tried lts-7.24. I get the exact same error, except it happens while building profunctors.
What could be the problem? Where can I file a bug?
I had the same error in a project using resolver: lts-9.17.
What fixed it for me is to update stack.yaml and use this line:
resolver: lts-10.9
I installed Julia v0.6.2 on Windows 10.
Every other package was installed without a problem, but Mongo.jl give me this error while building it.
Pkg.build("Mongo")
INFO: Building LibBSON
===============================[ ERROR: LibBSON ]===============================
LoadError: None of the selected providers can install dependency libbson.
Use BinDeps.debug(package_name) to see available providers
while loading C:\Users\"user"\.julia\v0.6\LibBSON\deps\build.jl, in expression starting on line 27
================================================================================
INFO: Building Mongo
================================[ ERROR: Mongo ]================================
LoadError: None of the selected providers can install dependency libmongoc.
Use BinDeps.debug(package_name) to see available providers
while loading C:\Users\"user"\.julia\v0.6\Mongo\deps\build.jl, in expression starting on line 26
================================================================================
================================[ BUILD ERRORS ]================================
WARNING: LibBSON and Mongo had build errors.
- packages with build errors remain installed in C:\Users\ciko9\.julia\v0.6
- build the package(s) and all dependencies with Pkg.build("LibBSON", "Mongo")
- build a single package by running its deps/build.jl script
================================================================================
I already opened an issue on github, but I'd like to fix it asap. Any idea on how to solve this problem?
The solution is first to install manually the mongo c drivers.
Second, to copy the mongo-c-drivers folder to the mongo e libbson folder inside julia, then make a new file deps.jl for each package and write this:
# Macro to load a library
macro checked_lib(libname, path)
((VERSION >= v"0.4.0-dev+3844" ? Base.Libdl.dlopen_e : Base.dlopen_e)(path) == C_NULL) && error("Unable to load \n\n$libname ($path)\n\nPlease re-run Pkg.build(package), and restart Julia.")
quote const $(esc(libname)) = $path end
end
# Load dependencies
#checked_lib libbson "C:\\Users\\"userName"\\.julia\\v0.6\\LibBSON\\mongo-c-driver\\bin\\libbson-1.0.dll"
# Load-hooks
I have a Homebrew-installed Haskell platform version 2013.2.0.0 with GHC 7.6.3 and an up-to-date cabal install. I try to install yesod-core - it grabs version 1.2.6.4, and I get this compilation error:
[11 of 20] Compiling Yesod.Core.Class.Yesod ( Yesod/Core/Class/Yesod.hs, dist/dist-sandbox-74f8d9fc/build/Yesod/Core/Class/Yesod.o )
Yesod/Core/Class/Yesod.hs:519:81:
Could not deduce (aeson-0.7.0.0:Data.Aeson.Types.Class.ToJSON
Network.HTTP.Types.Method.Method)
arising from a use of `.='
from the context (Yesod site)
bound by the type signature for
defaultErrorHandler :: Yesod site =>
ErrorResponse -> HandlerT site IO TypedContent
at Yesod/Core/Class/Yesod.hs:439:24-83
Possible fix:
add an instance declaration for
(aeson-0.7.0.0:Data.Aeson.Types.Class.ToJSON
Network.HTTP.Types.Method.Method)
In the expression: "method" .= m
In the first argument of `object', namely
`["message" .= ("Bad method" :: Text), "method" .= m]'
In the second argument of `($)', namely
`object ["message" .= ("Bad method" :: Text), "method" .= m]'
... which looks like an actual bug in the Yesod code. Any suggestions on how to proceed?
Looks like this is a build dependency issue in yesod-core, The developers on the irc channel are aware of the issue. To work around this trying installing yesod-core with this command
cabal install aeson-0.6.2.1 yesod-core
This will force the use of the previous version of aeson which works on my system in a fresh cabal sandbox.
When I tried to generate with yo jhipster on Windows 7 32 bits machine, I got the below error:
bower json3#~3.2.5 progress received 3.7MB of 4.9MB
downloaded, 75% libjpeg-62.dll: downloading [===================]
100% 0.0s
? pre-build test failed, compiling from source...
d:\Self_jhipster\node_modules\grunt-contrib-imagemin\node_modules\jpegtran-bin\
lib\check.js:19
throw new Error('building is not supported on ' + process.platform);
^ Error: building is not supported on win32
at d:\Self_jhipster\node_modules\grunt-contrib-imagemin\node_modules\jpegtran-bin\lib\check.js:19:10
How to solve this error?
I'm the author of http://jhipster.github.io/ which is the generator your are referring to.
I have found your problem, it is indeed a bug in jpegtran-bin. I have updated all the dependencies in Grunt.js, and it should now work fine on Windows.
This will be commited in the next release (0.2.1), which should be out in a few hours.
You can also submit a bug at https://github.com/jhipster/generator-jhipster/issues
After google with more correct keywords, the solution from https://github.com/gruntjs/grunt-contrib-imagemin/issues/109 works for me.
In application's package.json, add "jpegtran-bin": "0.2.0" before
the reference for imagemin,
Remove node_module folder locally.
Run npm install again.