"No error" crashes when running AWT functions on MacOS #56
Comments
|
hi! this doesn't depend on Kotlin, I believe it's because construo is not aware right now of other jar tasks other than tasks.register<Jar>("dist") {
// configuration here
}with tasks.jar {
// configuration here
}I don't have plans currently to support non-standard jar tasks, this might change in the future, but definitely not soon Another thing I do suggest to take a look at is shadow, which produces a "fat jar", as in a jar with all the dependencies inlined inside |
|
That works, the jar used is now correct, the wrapper now fails with no real info 🤔 |
|
Try to run it with Does the jar work if launched with |
|
The jar works No difference :/ But now I notice it never even created the dist folder, I'm running directly from construo/macM1/Unciv.app/Contents/MacOS |
|
This looks like a jdk minification issue, does it work if you replace the Things I would look at are: Are you loading classes from the stdlib via reflection? In that case add construo {
jlink {
// add arbitrary modules to be included when running jlink
modules.addAll("module.name.here")
}
}Where If you're doing HTTPS requests, that might be because of crypto modules missing, then you should be able to fix it by adding this: construo {
jlink {
// add arbitrary modules to be included when running jlink
modules.addAll("jdk.crypto.ec")
}
}I haven't found yet a less trial and error way of solving this issue, if you push a branch with the commits somewhere I can take a look when I have some time (I'll try tomorrow or Friday) |
|
Even copying the entire JDK doesn't solve this :( Here's the branch, run The gradle file is desktop/build.gradle.kts Take your time, I know how these things are, I'm in no rush :) |
yairm210
changed the title
|
I tried packaging a Linux x64 version (I don't have a Mac) and it runs, so at least we know it isn't a minification issue. I think this might be an issue in roast (which is the runtime construo uses to startup the jdk) specific for MacOS. One way of getting a better error output could be running roast from source, it's a few steps but it shouldn't be complex:
Note that you might need to install rust, I had for vscode. I can also try but it might take a while until I get access to a Mac |
|
I'll try it! |
|
Hello! Did you have a chance to test this? |
|
Hi, sorry |
|
Congrats! And no hurry 😁 |
|
Got the same thing with running roast locally Managed to set up a vscode debugger with lldb and got this far: So it recognized the return type was The macro expands to |
|
Hmm, that's my ignorance in Rust apparently 😆 log doesn't log anything unless you specify a logger. I created a branch which adds a logger, you can get all logs by running your application with I think you might be able to try directly with the built binaries here by running |
So we managed to get to an even inner-er macro in jni, macro_rules! jni_method {
( $jnienv:expr, $name:tt ) => {{
log::trace!("looking up jni method {}", stringify!($name));
let env = $jnienv;
match deref!(deref!(env, "JNIEnv"), "*JNIEnv").$name {
Some(method) => {
log::trace!("found jni method");
method
}
None => {
log::trace!("jnienv method not defined, returning error");
return Err($crate::errors::Error::JNIEnvMethodNotFound(stringify!(
$name
)));
}
}
}};
}So I tried a different approach. When I replaced my main function with just "hello world" everything worked, so it's something within the function that's causing this I gradually managed to isolate the problem to a specific Java function - Rechecked that it wasn't a JDK issue SO APPARENTLY it's a MacOS + AWT issue Perhaps related to oracle/graal#4124 - it looks like AWT libraries have some magic going on |
|
Aha! Great work on digging deeper on this :) Maybe you could try packing with Liberica https://bell-sw.com/pages/downloads/#jdk-17-lts ? In the linked issue comments they say that the issue doesn't happen with it (even tho they're using the native image, so this might not work) |
yairm210
changed the title
|
Unfortunately that does not solve the problem :( Well, it was worth a shot 🤷🏿 |
|
You could try to sorround the call in try/catch and see if you manage to get a stack trace: try {
GraphicsEnvironment.getLocalGraphicsEnvironment()
} catch (t: Throwable) {
// print t's stacktrace
} |
|
Another test you could do is to remove this dependency: https://github.com/yairm210/Unciv/blob/efb21182dba44da4351ba2d93c2341f6e4fb1ff1/desktop/build.gradle.kts#L30, I had problems in the past with things that would try to fix macos not running java on the first thread |
|
The try/catch yielded nothing but removing the dependency did change things The AWT no longer fails, but we just get a blank screen with default background color. I think I'll stop here though - I'm nearing the end of my hopefulness with this 😓 It's not you, I personally don't even blame the JVM ecosystem which I feel is not converging towards helpfulness rather than away. Unrelatedly (probably) I encountered a different issue with This is probably not a JDK-specific issue since it replicates with Corretto as well |
|
The warning you get is nothing to worry about, it's because roast adds this flag to log JNI warnings |
|
Thanks for testing so much with this! I'll see if I ever get around this issue |
Hi, looks like a great possible replacement for packr!
Unfortunately, when I tried adding this to my Kotlin project, it bundled fine but then I got the following:
So it looks like it's missing some basic files.
When I try to run the jar directly I get
In order to build my .jar file that works, I use the following gradle config, which has a lot of little changes picked up over the years
:
Config:
plugins { id("kotlin") id("io.github.fourlastor.construo") version "1.2.0" } construo { // Construo fields should have docs // name of the executable name.set(BuildConfig.appName.lowercase()) // human-readable name, used for example in the `.app` name for macOS humanName.set(BuildConfig.appName) // Optional, defaults to project version version.set(appVersion) // Optional, defaults to application.mainClass or jar task main class mainClass.set(mainClassName) // Optional, defaults to $buildDir/construo/dist // where to put the packaged zips // outputDir.set(deployFolder) targets{ create<Target.MacOs>("macM1") { architecture.set(Target.Architecture.AARCH64) jdkUrl.set("https://github.com/adoptium/temurin17-binaries/releases/download/jdk-17.0.11%2B9/OpenJDK17U-jdk_aarch64_mac_hotspot_17.0.11_9.tar.gz") identifier.set(BuildConfig.identifier) } } }Attached is the M1 zip created
In fact what would be great for me is if I could tell it "here's the jar file, don't worry about it, just pack"
The way I can with packr :)
The text was updated successfully, but these errors were encountered: