Exception in thread "main" java.lang.UnsatisfiedLinkError: Could not find native library in the classpath: macosx_universal/libsfml-system.dylib
at org.jsfml.window.ContextSettings.<clinit>(Unknown Source)
at org.jsfml.examples.scene.Standalone.main(Unknown Source)
$ java -jar jsfml-examples.jar
objc[49496]: Class SFApplication is implemented in both /Users/marcoantognini/.jsfml/macosx_universal/libsfml-window.dylib and /usr/local/lib/libsfml-window.2.dylib. One of the two will be used. Which one is undefined.
objc[49496]: Class SFOpenGLView is implemented in both /Users/marcoantognini/.jsfml/macosx_universal/libsfml-window.dylib and /usr/local/lib/libsfml-window.2.dylib. One of the two will be used. Which one is undefined.
objc[49496]: Class SFWindow is implemented in both /Users/marcoantognini/.jsfml/macosx_universal/libsfml-window.dylib and /usr/local/lib/libsfml-window.2.dylib. One of the two will be used. Which one is undefined.
objc[49496]: Class SFWindowController is implemented in both /Users/marcoantognini/.jsfml/macosx_universal/libsfml-window.dylib and /usr/local/lib/libsfml-window.2.dylib. One of the two will be used. Which one is undefined.
objc[49496]: Class SFViewController is implemented in both /Users/marcoantognini/.jsfml/macosx_universal/libsfml-window.dylib and /usr/local/lib/libsfml-window.2.dylib. One of the two will be used. Which one is undefined.
Exception in thread "main" java.lang.UnsatisfiedLinkError: org.jsfml.SFMLNative.nativeInit()V
at org.jsfml.SFMLNative.nativeInit(Native Method)
at org.jsfml.SFMLNative.loadNativeLibraries(Unknown Source)
at org.jsfml.SFMLNativeObject.<clinit>(Unknown Source)
at ShortExample.main(Unknown Source)
if (nativeLibs.size() == 0) {
throw new JSFMLException("Unsupported operating system: " + osName + " " + osArch);
}
Am I supposed to do something specific with PROPERTY_JSFML_BIN ?
for windows and linux you add "linux_x64/libjsfml.so" to nativeLibs. What is this library ? I can't find it.
Exception in thread "main" java.lang.UnsatisfiedLinkError: org.jsfml.SFMLNative.nativeInit()V
at org.jsfml.SFMLNative.nativeInit(Native Method)
at org.jsfml.SFMLNative.loadNativeLibraries(Unknown Source)
at org.jsfml.SFMLNativeObject.<clinit>(Unknown Source)
at ShortExample.main(Unknown Source)
Just to be sure, nativeInit is defined as Java_org_jsfml_SFMLNative_nativeInit in C++, right ?
"One of the two will be used. Which one is undefined." warning happens because libsfml-window.dylib was loaded twice.
That property I believe can safely be ignored.Ok.
Note that load order is very important here, but this doesn't seem to be your problem.No, it's not an issue on Mac from my experience.
You will need to compile those sources into a dylib as well.I did but then I 'ant clean'd it -.- . (Apple recommends to call them jnilib but this is the same as dylib.)
Why does that happen? I'm not sure how Mac OS X's Java ticks concerning librariesIn fact this has nothing to do with Java. It's how Objective-C works when two classes with the same name are loaded from two libraries.
Try removing the "libsfml-window.dylib" from the nativeLibs list and see what happens.It indeed does remove the warnings.
$ java -jar jsfml-examples.jar
Cannot create a window from a worker thread. (OS X limitation)
$ java -jar jsfml-examples.jar
Cannot create a window from a worker thread. (OS X limitation)
Segmentation fault: 11
I guess you used some kind of "make install" when building SFML? It's not good if it suddenly uses a dylib from elsewhere, this might cause bad incompatibilities. Not sure what we can do about this.I tried to use JSFML after removing all SFML binaries from my system except from .jsfml. Unfortunately this doesn't work :
$ java -jar jsfml-examples.jar
Exception in thread "main" java.lang.UnsatisfiedLinkError: /Users/marcoantognini/.jsfml/macosx_universal/libjsfml.jnilib: Library not loaded: @executable_path/../Frameworks/libsfml-system.2.dylib Referenced from: /Users/marcoantognini/.jsfml/macosx_universal/libjsfml.jnilib Reason: image not found
at org.jsfml.window.ContextSettings.<clinit>(Unknown Source)
at org.jsfml.examples.scene.Standalone.main(Unknown Source)
It appears that the jnilib will try to load libsfml-system.dylib even if it was loaded by Java manually. This means that the users must install SFML in the default location.
-Djava.library.path=/Users/marcoantognini/.jsfml/
Normal Java Swing GUIs do work, right? They (the Java developers) must have found a way to create windows, so I believe it must be possible somehow.I'll try to look how things work. Maybe I missed something in Apple doc about JNI.
I suppose that on Mac OS X, the RenderWindow(HANDLE) constructor works even in a worker thread?
Can you try running Java with the following command line argument?Code: [Select]-Djava.library.path=/Users/marcoantognini/.jsfml/
-Djava.library.path=/Users/marcoantognini/.jsfml/macosx_universal/
-XstartOnFirstThread
In short, try adding this command line argument:IT WORKS ! :DCode: [Select]-XstartOnFirstThread
-Djava.library.path=~/.jsfml/macosx -XstartOnFirstThread
Well yeah, sort it out and file a pull request or something.I'll go for a pull request so you have one nice commit and not a bunch of try and mistake commits. :wink:
Things are probably way easier if I just give you access to the repo.
One little request: I noticed you called it "macosx_universal", I believe because Mac OS X always runs on one and the same architecture and not on 32bit or 64bit. I'd say just leave the "_universal" part.The OS is running either in 32bits or 64bits (with Snow Leopard you can choose which one you want at boot time) but these binaries have both architectures (they are two files in one) in order to work on both architectures. So keeping the _universal postfix would prevent any confusion. However, if you think is too ugly I can remove it, of course.
BTW, did you try auto-extraction again? It would be cool if that worked. I can explain how to test it properly if you haven't worked it out yet.Not yet, will test it tomorrow. I let you know if I need help with this. thanks.
There is one problem left to solve really. On Mac OS X, any JSFML will have to be started usingCode: [Select]-Djava.library.path=~/.jsfml/macosx -XstartOnFirstThread
However, this cannot be done from within Java because they are JVM flags.
Do you know how to add a post action in the ant script so I can run a shell command on the produced object (in this case, libjsfml.jnilib) ?
<exec executable="command">
<arg value="argument1"/>
<arg value="argument2"/>
<arg value="argument3"/>
</exec>
${cpp.out}/${arch}/lib${jsfml.bin}.jnilib
The second thing is about <signjar /> stuff. I couldn't make it work (if I give no password the compilation fails with "[signjar] jarsigner: you must enter key password"; and if I give a password it complains with "[signjar] jarsigner error: java.lang.RuntimeException: keystore load: /Users/marcoantognini/.keystore (No such file or directory)") so I commented it out.
How can I disable it only if no password was given by the user ?
Exception in thread "main" java.lang.UnsatisfiedLinkError: Could not find native library in the classpath: windows_x64/libsndfile-1.dll
at org.jsfml.SFMLNativeObject.<clinit>(Unknown Source)
at ShortExample.main(ShortExample.java:15)
ant win64
ant jar
cd examples
ant jar
D:\Program Files\Java\JSFML\build.xml:220: The directory D:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64 does not exist
@echo off
echo "C:\Program Files (x86) Microsoft Visual Studio 9.0\"
HKEY_CURRENT_USER\Software\Microsoft\VCExpress\
Windows
To build on Windows (targets win32 and win64), you will require the Windows SDK (latest possible) as well as the Microsoft Visual C++ compiler. Note that the compiler can be installed along with the Windows SDK, so you don't necessarily need the Microsoft Visual Studio.
The path of the Windows SDK and the MS Visual C++ compiler is retrieved automatically using the provided batch scripts. Do not hesitate to report any problems with these scripts, but if you do let me know which Windows and WinSDK / MSVC++ you have installed.
Using MingW "objdump -x sfml-system-2.dll", this dll imports 3 dlls:This happens because I compiled and linked the SFML binaries using the MS Visual C++ compiler included in WinSDK 7 (Express 2010), you say that you have WinSDK 6 installed (which includes Express 2008).
KERNEL32.dll
MSVCR100.dll
MSVCP100.dll
In my registry there's no "HKLM\SOFTWARE\Microsoft\VisualStudio\10.0\Setup\VS" "ProductDir".Thanks, I will update the batch later so that gets detected.
Instead, there's "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\10.0\Setup\VC" "ProductDir"=C:\Program Files\Microsoft Visual Studio 10.0\VC\.
Does the end user need to install VC++ 2010 runtime?Yep, they will have to install it. A lot of Windows games need it these days, so it should not be much of a problem.
No idea about Mac OS XTo use JSFML on Mac you only need jsfml.jar. That should be all. :)
The symbolic link is only used at compile time and the resulting binary remembers exactly what version it was compiled with.To be more precise, the resulting binary remembers the SO version it was compiled with, which is supposed to be the same for binary compatible versions of the library. The SO version can be the major version number, or major and minor version numbers, depending on the versioning conventions of the library.
Maybe I should go for a different approach after all and make the Linux version depend on the SFML 2 package and treat it as an external dependency. That's probably how it should be done anyway.Absolutely!
In that case, can I consider the current SFML2 library file names final so it will work once SFML2 appears in public repositories?Yep.
What can be done for the "transition phase" - I don't really think SFML2 will be in any repos until a few months after the release...Add a link to the SFML download page? :P
For Mac, since the linking process seems to require a bunch of tricks, I believe the same can be said, Hiura will know for sure though.Yeah, I also think it's the easiest way to go.
Add a link to the SFML download page? :PIf you download a game from somewhere, you expect to hit its executable and it runs. You don't expect that you have to download sources and compile another package first and set several environment variables. Maybe everyday Linux users do expect that, I don't know, but IMO it just plain sucks.