-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problems linking against native libraries #836
Comments
thanks, I will take a look at it |
I have the same problem with leiningen on the command line, no need to reach for ccw to get the UnstatisfiedLinkError exception. |
And as you suggested, moving my |
There's a word about lwjgl in the leiningen samples project.clj, by the way:
|
Please, talk about this issue with the Leiningen folks first. There's a lot on my plate these days, it would be good if you could confirm that you also get the same problem with leiningen, and then maybe find a solution, or some workaround. |
Alright! I will do experiments with Leiningen first and see if it is possible to get a fix from some manipulations with it. Eh, I am sorry that I have loaded you with this one, since it apparently is a core Leiningen issue... on the other hand, I think a user expects his IDE to handle such things automatically... the case seems vague, I'll explore more and report when I have some results on this. |
You did the right thing, don't worry. Thanks for exploring the case. 2015-08-17 12:37 GMT+02:00 noncom [email protected]:
Laurent Petit |
Small update: specifying I am still contemplating on this... |
So to summarize :
2015-08-20 15:23 GMT+02:00 noncom [email protected]:
Laurent Petit |
Yes, it works in Windows command line Leiningen, as well as from CCW if "launch projects with Leiningen" is enabled - same. However, if I uncheck "launch projects with Leiningen", it looks like that CCW goes with what Eclipse is saying in the deps and does not find the libs, failing as before. Idk if there is even a solution for that. Probably this is a quirk of dealing with the lwjgl library in particular.. As hyPiRion said on #leiningen, not many people work with native deps and this area is highly underdocumented and it is unknown if some uniformity (i.e. a generalized solution) can be applied to the area at all. If it will become clear that it is impossible to formalize a universal approach for this situation, then maybe a plugin for CCW+LWJGL could be considered. Because the problem is there and other people can stumble upon it and there is not much info on this.. |
@noncom which version of leiningen are you using on the command line? |
@noncom also, can you please update the github project |
I still cannot make it work on the command line.
Then I check the
So I may be missing the obvious, which is ... ? |
I will try to work this out, once I get the right configuration for making 2015-08-20 15:29 GMT+02:00 noncom [email protected]:
Laurent Petit |
Whoa... everything is more complicated than I originally thought. After I saw your last comments I went and tried to repeat the scenario again, doing this in the command line:
So I went to see what's up in the target dir and saw weird things. The dlls were lying in this actual location:
So, there is a mystery going on. Somehow specifying Alright, so I decided to go check what's really going on! Here was my experiment:
Obviously this is a bug in Leiningen. It treats the My current Leiningen version is Also, I have updated the repository. |
Ah, sorry, the fact that the solution did not work made me embarrassed and I went checking it out right away. Now I re-read what you're saying and I see you mention that the UPDATE: I tried what your described on a Mac on my job, the target directory was not empty (without even adding |
Yes, this seems like a bug in leiningen, and I'd be more than happy if you 2015-08-21 17:08 GMT+02:00 noncom [email protected]:
Laurent Petit |
Yes, the available workaround allows me to continue the work, it is not a blocking problem. And also, it is pointless to do any adjustments to CCW until Leiningen is fixed. Maybe CCW will not even need any fixes in the end. Okay, then I will work with the Leiningen part of this issue and come back to this one here when we have some info or a fix from Leiningen! |
Leiningen people still did not pick up the issue. Probably it is my bad and it was lousely formulated (although I don't think so, considering the amount of information that needs to be presented for complete description). I have reformulated it. I hope it will receive attention. |
Ok, thanks for the update. I also hope it will receive the attention it 2015-10-13 14:29 GMT+02:00 Alex Fowler [email protected]:
Laurent Petit |
Yeah, well, you know, some long time ago, even before having this exact issue, I've been talking to hyPiRion about Leiningen and native libraries. He said that as there are really not many people who work with this kind of programs at all, including themselves (the Leiningen team), nobody even know or check how it all works because they have no immediate need to do this while these cases really require some dedication. |
Good news on this one! The issue has been resolved: technomancy/leiningen@adb7b99 I did not have a chance yet to test it myself though.. I'll get to it as soon as possible. |
Great ! If possible I'll include it in version 0.35.0 ! |
With my current project I've stepped into a problem with native libraries. The issue is that lwjgl cannot find its natives although the jar with the natives is properly linked to the project and appears in Leiningen Dependencies.
I have made a little research and found out that this problem is known for lwjgl:
http://wiki.lwjgl.org/wiki/Downloading_and_Setting_Up_LWJGL look at the "I keep getting an java.lang.UnsatisfiedLinkError: no lwjgl in java.library.path" paragraph
this is how it is solved normally in eclipse: http://stackoverflow.com/questions/19344914/getting-java-lang-unsatisfiedlinkerror-no-lwjgl-in-java-library-path
and the official guide: http://wiki.lwjgl.org/index.php?title=Setting_Up_LWJGL_with_Eclipse (mostly same as point 2), but with neat pictures ).
So, in my project there is the lwjgl natives jar, however, the java lwjgl jar native library path points to "project/target/native/windows/x86_64" and in the project build path setup it says "not modifiable".
The interesting part is that the natives are actually do get extracted and are there ready to be picked up, but they are located at "project/target/native/windows".
Resume: if I manually copy the dlls from "project/target/native/windows" to "project/target/native/windows/x86_64", all starts working okay. I know leiningen and java in general have their quirks in working with native libraries, but what is different in this case, is that the path "project/target/native/windows/x86_64" is incorrect and cannot be changed. Is there something in CCW that is getting in touch with this?
A small GitHub project illustrating the issue: https://github.com/noncom/test-natives
Upon loading the
core
ns into the repl, you'll get:and if you move the natives as I've described above, it will compile fine. even calling
(go)
will work ok and returnnil
. It does not matter that you have no actual opengl context activeThe text was updated successfully, but these errors were encountered: