Closed GoogleCodeExporter closed 9 years ago
Looks like it did not find the correct include file. Can you attach the
generated build.properties file?
Original comment by a...@1stleg.com
on 27 Aug 2012 at 3:35
First off, do i really need to build it myself to have it work with JDK7?
I manually set JAVA_HOME to point to my JDK7 VM.
#auto-generated by ant configure
#Mon, 27 Aug 2012 16:46:37 +0200
java.cc=modern
java.target=1.5
native.cc=gcc
native.cc.args=-c -m64 -arch x86_64 -mtune\=generic -O2 -fomit-frame-pointer
-pipe -fPIC -Wall -Wextra -Werror -std\=c99 -pedantic -pthread
-DCOREFOUNDATION -DIOKIT -I/Users/pepijndevos/svn/jnativehook/src/native/common
-I/Users/pepijndevos/svn/jnativehook/src/native/jni -I/usr/lib
-I/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/include
native.cc.args2=-o
native.ld=gcc
native.ld.args=-dynamiclib -m64 -arch x86_64
-Wl,-dead_strip,-dead_strip_dylibs,-install_name,libJNativeHook.jnilib.1.1,-comp
atibility_version,1.1,-current_version,1.1.0,-s
native.ld.args2=-framework ApplicationServices -framework IOKit -framework
Carbon -o
Original comment by pepijndevos
on 27 Aug 2012 at 3:44
You should not need to build it your self. It looks like Apple has botched
something with their new JDK bundle. I don't own a Mac that is new enough to
run 10.7 so I am looking into other ways of testing this.
Original comment by a...@1stleg.com
on 27 Aug 2012 at 6:50
Alright, compiling requires one more include path at the end of native.cc.args:
-I/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/include/darwin
It still doesn't run after it compiles. That problem seems to be caused by the
Class objects getResourceAsStream method returning null on OS X. See:
http://docs.oracle.com/javase/7/docs/api/java/lang/Class.html#getResourceAsStrea
m(java.lang.String)
That method appears to function correctly on Windows, Linux and Solaris using
the binaries provided by Oracle. I am about 5 minutes away from calling this a
JRE bug on OS X probably due to a botched custom class loader for the platform.
I will dig around a bit more and see if I can find a solution but I believe
that a bug report to oracle will be required. You should be able to work
around the problem by specifying the java.library.path manually (Ex: java
-Djava.library.path=/path/to/dylib/ -jar JNativeHook.jar)
Original comment by a...@1stleg.com
on 27 Aug 2012 at 11:03
[deleted comment]
Scratch the bug, I found the issue. It is looking for the wrong filename. For
some reason Java 7 returns .dylib for System.mapLibraryName() instead of jnilib.
Original comment by a...@1stleg.com
on 27 Aug 2012 at 11:49
Fixed in revision 598.
Original comment by a...@1stleg.com
on 28 Aug 2012 at 6:07
Thanks for the super quick fix.
Now, unless there will be a new RC soon, I will need to build it from source
anyway.
What does the process look like to generate a jar with Mac, Linux and Windows
natives?
p.s. this is what we're building: https://github.com/davidleibovic/keymusix
Original comment by pepijndevos
on 28 Aug 2012 at 11:40
Np. Generating cross compiled binaries is a pain. There is a binary attached
to bug #19 that covers up the the current trunk. There maybe some problems
with that binary but I will update it as that bug progresses. I am trying to
resolve bug #18 before the final 1.1 but if that takes to much longer it may
need to wait. If you need a custom build just let me know. It only takes a
few seconds to run it though the cross compiler.
Original comment by a...@1stleg.com
on 28 Aug 2012 at 3:32
Original issue reported on code.google.com by
pepijndevos
on 27 Aug 2012 at 2:54