I'm trying to set up a Scala project which builds on the libGDX game engine using sbt. After adding the necessary dependencies and trying to instantiate LwjglApplication, it fails to load the shared library libgdx64.dylib, which contains some native code for my platform (macOS 10.13.6).
These are the dependencies I've declared:
libraryDependencies += "com.badlogicgames.gdx" % "gdx" % "1.9.14"
libraryDependencies += "com.badlogicgames.gdx" % "gdx-backend-lwjgl" % "1.9.14"
libraryDependencies += "com.badlogicgames.gdx" % "gdx-platform" % "1.9.14" % "natives-desktop"
This is the exception I get:
sbt:test_libgdx> run
[info] Compiling 1 Scala source to /Users/michi/Documents/Projects/Slick2D/test_libgdx/target/scala-2.13/classes ...
[info] running Main
[error] (run-main-3) com.badlogic.gdx.utils.GdxRuntimeException: Couldn't load shared library 'libgdx64.dylib' for target: Mac OS X, 64-bit
[error] com.badlogic.gdx.utils.GdxRuntimeException: Couldn't load shared library 'libgdx64.dylib' for target: Mac OS X, 64-bit
[error] at com.badlogic.gdx.utils.SharedLibraryLoader.load(SharedLibraryLoader.java:120)
[...]
With my limited knowledge of sbt, ivy and Maven artifacts I've investigated a bit and noticed that the JAR file containing libgdx64.dylib (gdx-platform-1.9.14-natives-desktop.jar) is not added to the classpath of the running application. I've narrowed it down to a minimal project setup which shows this problem:
$ ls
build.sbt project target
$ cat build.sbt
libraryDependencies += "com.badlogicgames.gdx" % "gdx-platform" % "1.9.14" % "natives-desktop"
$ sbt
[info] welcome to sbt 1.4.9 (AdoptOpenJDK Java 1.8.0_282)
[info] loading global plugins from [...]/.sbt/1.0/plugins
[info] loading project definition from [...]/test/project
[info] loading settings for project test from build.sbt ...
[info] set current project to test (in build file:[...]/test/)
[info] sbt server started at local://[...]/.sbt/1.0/server/dd1267d773c22c32c889/sock
[info] started sbt server
sbt:test> show compile:dependencyClasspath
[info] * Attributed([...]/.sbt/boot/scala-2.12.12/lib/scala-library.jar)
[success] Total time: 0 s, completed Mar 31, 2021 10:47:54 AM
sbt:test>
If I look in the maven repository at https://repo.maven.apache.org/... manually, I can see that JAR file.
What do I need to do to get that JAR file on the classpath so that the shared library can be loaded from it? Where's my mistake?
I have encountered the same issue - for sbt to comprehend an artifact with multiple builds (in this case, native binaries), instead of % you have to use a classifier:
libraryDependencies += "com.badlogicgames.gdx" % "gdx-platform" % "1.11.0" classifier "natives-desktop"
Related
I am trying to install the python package "imblearn" to balanace datasets,
with the command pip install imblearn.
but it keeps failing.
trying from cmdand from PowerShell with admin privileges,
with regular pip command, and with git clone to the repo and then pip install.
everything is failing.
the error is:
C:\Users\ronke>pip install imblearn
Collecting imblearn
Using cached imblearn-0.0-py2.py3-none-any.whl (1.9 kB)
Collecting imbalanced-learn
Using cached imbalanced_learn-0.10.1-py3-none-any.whl (226 kB)
Requirement already satisfied: scipy>=1.3.2 in c:\networks\python3.8\lib\site-packages (from imbalanced-learn->imblearn) (1.6.3)
Collecting scikit-learn>=1.0.2
Using cached scikit-learn-1.2.0.tar.gz (7.2 MB)
Installing build dependencies ... error
error: subprocess-exited-with-error
× pip subprocess to install build dependencies did not run successfully.
│ exit code: 1
╰─> [73 lines of output]
Ignoring numpy: markers 'python_version == "3.10" and platform_system == "Windows" and platform_python_implementation != "PyPy"' don't match your environment
Collecting setuptools<60.0
Using cached setuptools-59.8.0-py3-none-any.whl (952 kB)
Collecting wheel
Using cached wheel-0.38.4-py3-none-any.whl (36 kB)
Collecting Cython>=0.29.24
Using cached Cython-0.29.32-py2.py3-none-any.whl (986 kB)
Collecting oldest-supported-numpy
Using cached oldest_supported_numpy-2022.11.19-py3-none-any.whl (4.9 kB)
Collecting scipy>=1.3.2
Using cached scipy-1.9.3.tar.gz (42.1 MB)
Installing build dependencies: started
Installing build dependencies: finished with status 'done'
Getting requirements to build wheel: started
Getting requirements to build wheel: finished with status 'done'
Installing backend dependencies: started
Installing backend dependencies: finished with status 'done'
Preparing metadata (pyproject.toml): started
Preparing metadata (pyproject.toml): finished with status 'error'
error: subprocess-exited-with-error
Preparing metadata (pyproject.toml) did not run successfully.
exit code: 1
[37 lines of output]
+ meson setup --prefix=c:\networks\python3.8 C:\Users\ronke\AppData\Local\Temp\pip-install-n9p_hxtm\scipy_cef72cd617894d719469ea6e03d892cb C:\Users\ronke\AppData\Local\Temp\pip-install-n9p_hxtm\scipy_cef72cd617894d719469ea6e03d892cb\.mesonpy-jv80z8m8\build --native-file=C:\Users\ronke\AppData\Local\Temp\pip-install-n9p_hxtm\scipy_cef72cd617894d719469ea6e03d892cb\.mesonpy-native-file.ini -Ddebug=false -Doptimization=2
The Meson build system
Version: 1.0.0
Source dir: C:\Users\ronke\AppData\Local\Temp\pip-install-n9p_hxtm\scipy_cef72cd617894d719469ea6e03d892cb
Build dir: C:\Users\ronke\AppData\Local\Temp\pip-install-n9p_hxtm\scipy_cef72cd617894d719469ea6e03d892cb\.mesonpy-jv80z8m8\build
Build type: native build
Project name: SciPy
Project version: 1.9.3
Activating VS 17.1.3
C compiler for the host machine: cl (msvc 19.31.31105 "Microsoft (R) C/C++ Optimizing Compiler Version 19.31.31105 for x64")
C linker for the host machine: link link 14.31.31105.0
C++ compiler for the host machine: cl (msvc 19.31.31105 "Microsoft (R) C/C++ Optimizing Compiler Version 19.31.31105 for x64")
C++ linker for the host machine: link link 14.31.31105.0
Host machine cpu family: x86_64
Host machine cpu: x86_64
Compiler for C supports arguments -Wno-unused-but-set-variable: NO
Compiler for C supports arguments -Wno-unused-but-set-variable: NO (cached)
Compiler for C supports arguments -Wno-unused-function: NO
Compiler for C supports arguments -Wno-conversion: NO
Compiler for C supports arguments -Wno-misleading-indentation: NO
Compiler for C supports arguments -Wno-incompatible-pointer-types: NO
Library m found: NO
..\..\meson.build:57:0: ERROR: Unknown compiler(s): [['ifort'], ['gfortran'], ['flang'], ['pgfortran'], ['g95']]
The following exception(s) were encountered:
Running `ifort --version` gave "[WinError 2] The system cannot find the file specified"
Running `ifort -V` gave "[WinError 2] The system cannot find the file specified"
Running `gfortran --version` gave "[WinError 2] The system cannot find the file specified"
Running `gfortran -V` gave "[WinError 2] The system cannot find the file specified"
Running `flang --version` gave "[WinError 2] The system cannot find the file specified"
Running `flang -V` gave "[WinError 2] The system cannot find the file specified"
Running `pgfortran --version` gave "[WinError 2] The system cannot find the file specified"
Running `pgfortran -V` gave "[WinError 2] The system cannot find the file specified"
Running `g95 --version` gave "[WinError 2] The system cannot find the file specified"
Running `g95 -V` gave "[WinError 2] The system cannot find the file specified"
A full log can be found at C:\Users\ronke\AppData\Local\Temp\pip-install-n9p_hxtm\scipy_cef72cd617894d719469ea6e03d892cb\.mesonpy-jv80z8m8\build\meson-logs\meson-log.txt
[end of output]
note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed
Encountered error while generating package metadata.
See above for output.
note: This is an issue with the package mentioned above, not pip.
hint: See above for details.
[end of output]
note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error
× pip subprocess to install build dependencies did not run successfully.
│ exit code: 1
╰─> See above for output.
note: This error originates from a subprocess, and is likely not a problem with pip.
Does someone know how to fix it?
thanks
Ron
I've condensed this to show the key part of the error:
Collecting scipy>=1.3.2
Using cached scipy-1.9.3.tar.gz (42.1 MB)
...
..\..\meson.build:57:0: ERROR: Unknown compiler(s): [['ifort'], ['gfortran'], ['flang'], ['pgfortran'], ['g95']]
Which is saying that scipy==1.9.3 failed to compile because a Fortran compiler was not availalbe.
This is probably caused by a 32-bit version of Python / Windows, since pre-compiled scipy and scikit-learn wheels are being phased out for 32-bit systems, and we're no longer testing 32-bit Windows in imblearn (see PR#936).
One possible fix is to install a copy of Python with Anaconda or Miniconda, then:
conda install -c conda-forge imbalanced-learn
I've made a simple mysql connection app using only one scala file and scala-2.11.8 and sbt-1.2.6 on Windows 7 box with JDK-1.8.0_131. The build.sbt is:
name := "MySQL w. Scala"
scalaVersion := "2.11.8"
libraryDependencies += "mysql" % "mysql-connector-java" % "8.0.11"
When I do sbt compile, I keep getting:
[error] sbt.librarymanagement.ResolveException: unresolved dependency: org.scala-lang#scala-library;2.12.4: not found
[error] unresolved dependency: mysql#mysql-connector-java;8.0.11: not found
[error] unresolved dependency: org.scala-lang#scala-compiler;2.12.4: not found
I've tried with the same scala file and the build.sbt on my OS X 10.7.4 box, and it got compiled. I can't do it on Windows 7. Thank you.
Situation:
I want to execute JUnit test cases for my Play! 2.0 application on a Jenkins Server.
To build and test my app on the server I want to use SBT (with command sequence: clean compile test).
Problem:
Regardless of Jenkins, the command play test uses a different classpath than the command java -jar "sbt-launch.jar" test (both commands executed in the root directory of my play project, both commands use the same sbt version 0.12.2). My test cases can be compiled with play test but with java -jar "sbt-launch.jar" test the compiler complains that some JUnit classes (e.g., org.junit.rules.TestWatcher) are missing.
Analysis:
The command show test:full-classpath reveals that the classpathes indeed differ:
play test classpath contains: Attributed(<playhome>\repository\local\junit\junit-dep\4.10\jars\junit-dep.jar)
java -jar "sbt-launch.jar test classpath contains: Attributed(<userhome>\.ivy2\cache\junit\junit-dep\jars\junit-dep-4.8.2.jar)
Question:
Any ideas how to ensure that java -jar "sbt-launch.jar test uses the same classpath as play test?
Build.scala:
import sbt._
import Keys._
import play.Project._
object ApplicationBuild extends Build {
val appName = "my app"
val appVersion = "1.0-SNAPSHOT"
val appDependencies = Seq(
// Play framework dependencies
javaCore, javaJdbc, javaEbean,
// Add your project dependencies here
"com.typesafe" %% "play-plugins-mailer" % "2.1.0",
"com.feth" %% "play-authenticate" % "0.2.5-SNAPSHOT",
"org.mongodb" % "mongo-java-driver" % "2.10.1",
"com.embedly" % "embedly-api" % "0.1.5",
"org.mockito" % "mockito-all" % "1.9.5",
"org.mongojack" % "mongojack" % "2.0.0-RC5",
"commons-io" % "commons-io" % "2.3"
)
val main = play.Project(appName, appVersion, appDependencies).settings(
resolvers += Resolver.url("play-easymail (release)", url("http://joscha.github.com/play-easymail/repo/releases/"))(Resolver.ivyStylePatterns),
resolvers += Resolver.url("play-easymail (snapshot)", url("http://joscha.github.com/play-easymail/repo/snapshots/"))(Resolver.ivyStylePatterns),
resolvers += Resolver.url("play-authenticate (release)", url("http://joscha.github.com/play-authenticate/repo/releases/"))(Resolver.ivyStylePatterns),
resolvers += Resolver.url("play-authenticate (snapshot)", url("http://joscha.github.com/play-authenticate/repo/snapshots/"))(Resolver.ivyStylePatterns)
)
}
The play script rewires sbt to use a local JUnit file repository in addition to any remote you've used. This is why the download is so large. Ivy, by default, will not copy local files into its local cache, as it assumes they are stable.
SO, what you're seeing is the sbt script which downloaded the file vs. the Play script which has its own local repo that takes priority over the downloaded file.
Now the fun part is around versioning. Ivy has interesting version conflict resolution.
If you paste you look in your target/resolution-cache/reports directory, you may get some insight into the difference between the two commands and why the one junit is chosen over another. My guess is there's a dynamic version range which is looking in the local repository for the play script and not finding the newer version of junit-dep.
I tried and completed these steps,
Downloaded Lift2.5 Version
and changed scala_210/lift_json/build.sbt file with my scala version
After that I ran build.sbt file.
After some downloads and some updating all showing Successfully Done.
After I got these lines on terminal
[info] Updating {file:/home/srujan/Downloads/lift-lift_25_sbt-b67dc62/scala_210/lift_json/}default-3b2806...
[info] Resolving org.specs2#scalaz-core_2.10;7.0.0 ...
[info] Done updating.
[info] Successfully created Eclipse project files for project(s):
[info] Lift 2.5 starter template
> eclipse
[info] About to create Eclipse project files for your project(s).
[info] Successfully created Eclipse project files for project(s):
[info] Lift 2.5 starter template
>
What should I do after this step?
Please help me
I know that the scala swing libraries are present in scala 2.8:
[info] Building project chart 1.0 against Scala 2.8.1
[info] using sbt.DefaultProject with sbt 0.7.4 and Scala 2.7.7
So how come I'm getting this error:
[error] /src/main/scala/Chart.scala:2: value swing is not a member of package scala
[error] import scala.swing.Panel
Is it because SBT is using the wrong version of scala (i.e. 2.7.7)? If so, how do I configure it to use the correct version?
EDIT: Answer
Following Dylan Lacey's answer, I made the following file sbt/project/build/chart.scala:
import sbt._
class SamplesProject(info: ProjectInfo) extends DefaultProject(info)
{
val scalaSwing = "org.scala-lang" % "scala-swing" % "2.8.1"
}
Then I ran: sbt reload update from the shell.
Now things compile!
For sbt 0.11 (and presumably 0.10) then adding the following to build.sbt will do it:
libraryDependencies <+= scalaVersion { "org.scala-lang" % "scala-swing" % _ }
No. The version information reported on line 2 is just the version sbt was built with, it won't effect your build.
Because Swing is a package (Not part of the base classes) I suspect the problem is one of two things. Either:
Your build file doesn't specify that you want to use scala-swing and is getting confused. You can correct this by adding:
val scalaSwing = "org.scala-lang" % "scala-swing" % "packageVersion"
in your /project/build/projectName.scala (Thanks Janx!)
You've added the dependancy but have not yet downloaded the required package. To do this, you need sbt to reload your project definition and then get all required packages:
sbt reload update
If you need option 1, you'll likely need to also do option 2.
If neither of these work, you may have confused your local respository horribly. That can be fixed with a sbt clear-lib, but you will then re-download all your packages.