UnsatisfiedLinkError on Windows #41
Comments
|
@lafoletc OK, I've traced the issue. The code you introduced here is incorrect - Removing that interface and routing all native calls through Do you want to fix this one or shall I? Are there any other places where you've added in an empty sub-interface like this? Thanks, Neil |
|
From my reading GstNative.load only works for exactly one library: gstreamer, but in this case gobject is needed. This: GstNative.load(GObjectAPI.class)translates to something like this: GNative.loadLibrary("gstreamer", GObjectAPI.class, new HashMap<String, Object>() {{
put(Library.OPTION_TYPE_MAPPER, new GTypeMapper());
put(Library.OPTION_FUNCTION_MAPPER, new GFunctionMapper());
}})And that in turn calls Native.loadLibrary("gstreamer", GObjectAPI.class, new HashMap<String, Object>() {{
put(Library.OPTION_TYPE_MAPPER, new GTypeMapper());
put(Library.OPTION_FUNCTION_MAPPER, new GFunctionMapper());
}})So in the end the gobject API is mapped onto the library gstreamer. I suspect there are different rules about symbols resolve in place, that cause this to succeed on linux, but fail on windows. |
|
@matthiasblaesing Thanks for your comment. That's not quite what is happening here though. It'll actually pass |
|
Before I answer the last question here are the two changes necessary for the unittests to work on windows (two fail on false assumptions, not on code errors) - sorry this is kind of improvised, as my main development happens on linux and starting gstreamer from a network share blocked it in native code): ElementFactory.java (line 149 uses a wrong mapping, there different libraries are mapped onto the same interface, this is a no-no and fails on windows) glist = GlibAPI.GLIB_API.g_list_append(glist, fact.handle());GType.java (line 40, you already found that) private static final GObjectAPI gst = GObjectAPI.GOBJECT_API;With these I get on windows 64bit and newest gstreamer: 1 Testfailure in GC tests (could be timing) Ok - in general you can do what was done in Gstreamer, you can extend an interface to add more mapped methods. See here: The ntservice contrib project enhances the Advapi32 that is supplied with jna-platform. On another side is the question is this mass-mapping done in gstreamer really a good idea. You already chimed in on a bugreport in JNA about deadlocks and when I saw today how many times the same library is mapped I'm not surprised. The jna-platform bindings in general map one dll onto one java interface and delegate to that. So while the interfaces get fairly big (>> 1000 lines), the absolute count of loads is minimal. I suggest to do the same in the gstreamer bindings. Even if you'd group by header file you'd go done with the amount of mapped interfaces you are using. For example: ApplicationQuery each load their own API, instead of delegating to GstQueryAPI where most functions are already mapped or could be trivially added. |
|
Thanks @matthiasblaesing Yes, it's a pattern we inherited from the old GStreamer 0.10 bindings which I've always disliked (it's not the only JNA project I work with). Up until this week I thought it was inefficient and a stumbling block on moving forwards with things like direct mapping - I didn't realise it was a critical bug! So, yes agreed, time to trim the fat 😄 My own development platform is Linux also. I don't have GStreamer in my path on Windows (deliberately so I can test Praxis LIVE which uses JNA Platform to set up paths), which means I need to find a way to easily run the tests. I guess from now on we need most pull requests to pass the tests on all 3 platforms! |
|
I have made a PR for GType following your propositions |
|
Just so that the work is not doubled - I'm just looking into removing the overflous API classes. I'll stay away from GType as @lafoletc is working on that already. |
|
@matthiasblaesing Thanks for letting us know. I was going to have a look, but can't until the end of this week, so if you can look sooner that's great! A few thoughts on this -
Thanks, Neil |
|
@neilcsmith-net still not able to compile it on Windows. is there a specific version of gst to compile with the new changes Failed tests: |
|
This build succeeded, only one unittest failed. Either look into the reason why that fails or just ignore it: http://maven.apache.org/surefire/maven-surefire-plugin/examples/skipping-test.html I saw the test error and for me it was flaky. |
|
Also note that if you just require a pre-built binary - https://github.com/gstreamer-java/gst1-java-core/releases New feature 😄 |
|
thanks for the support |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@lafoletc Since (I think) updates in the pull request for MiniObject fixes #25 I am getting an UnsatisfiedLlinkError for g_type_name on Windows. Not sure whether the native function is mapped incorrectly, or whether there's a problem linking to GObject?! Any thoughts on this?
The text was updated successfully, but these errors were encountered: