MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0014143CMakeModulespublic2013-05-15 16:182013-10-07 10:10
Reportervitaut 
Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionno change required 
Platformx64OSWindowsOS VersionXP Pro x64 SP2
Product VersionCMake 2.8.10.2 
Target VersionFixed in Version 
Summary0014143: FindJNI cannot find JDK installed
DescriptionFindJNI cannot find JDK installed in C:\Program Files\Java\jdk1.7.0_21 on Windows XP Professional x64 Edition with SP2.

It seems that the problem is find_library not resolving registry references in PATHS which is illustrated by the following CMakeLists.txt:

cmake_minimum_required(VERSION 2.8)
project(TEST)

get_filename_component(java_install_version
  "[HKEY_LOCAL_MACHINE\\SOFTWARE\\JavaSoft\\Java Development Kit;CurrentVersion]" NAME)
message("java_install_version: ${java_install_version}")

find_library(JAVA_AWT_LIBRARY jawt
  PATHS "[HKEY_LOCAL_MACHINE\\SOFTWARE\\JavaSoft\\Java Development Kit\\${java_install_version};JavaHome]/lib")
message("JAVA_AWT_LIBRARY: ${JAVA_AWT_LIBRARY}")

get_filename_component(java_library_path
  "[HKEY_LOCAL_MACHINE\\SOFTWARE\\JavaSoft\\Java Development Kit\\${java_install_version};JavaHome]/lib" ABSOLUTE)
message("java_library_path: ${java_library_path}")
find_library(JAVA_AWT_LIBRARY2 jawt
  PATHS "${java_library_path}")
message("JAVA_AWT_LIBRARY2: ${JAVA_AWT_LIBRARY2}")

CMake gives the following output on it:

java_install_version: 1.7
JAVA_AWT_LIBRARY: JAVA_AWT_LIBRARY-NOTFOUND
java_library_path: C:/Program Files/Java/jdk1.7.0_21/lib
JAVA_AWT_LIBRARY2: C:/Program Files/Java/jdk1.7.0_21/lib/jawt.lib
-- Configuring done
-- Generating done
-- Build files have been written to: C:/temp/test

Note that JAVA_AWT_LIBRARY is not found, while the JAVA_AWT_LIBRARY2 where PATHS don't contain registry references is found. The find_library code for JAVA_AWT_LIBRARY is similar to what FindJNI.cmake uses.
Steps To Reproduce1. Install JDK.
2. Run CMake using the following CMakeLists.txt:

cmake_minimum_required(VERSION 2.8)
project(TEST)
find_package(JNI)

3. Observe that CMake reports
-- Could NOT find JNI (missing: JAVA_AWT_LIBRARY JAVA_JVM_LIBRARY JAVA_INCLUDE_PATH JAVA_INCLUDE_PATH2 JAVA_AWT_INCLUDE_PATH)
Additional Information
TagsNo tags attached.
Relationships
related to 0011303closed  CMake fails to detect Python X64 on Win64 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2013-05-15 16:18vitautNew Issue
2013-05-15 16:24Brad KingNote Added: 0033046
2013-05-15 17:14vitautNote Added: 0033047
2013-05-16 11:51Brad KingNote Added: 0033060
2013-05-17 00:22vitautNote Added: 0033081
2013-05-17 08:09Brad KingNote Added: 0033082
2013-05-17 10:01vitautNote Added: 0033088
2013-05-17 10:25vitautNote Added: 0033089
2013-05-17 10:36Brad KingNote Added: 0033090
2013-05-17 10:36Brad KingStatusnew => resolved
2013-05-17 10:36Brad KingResolutionopen => no change required
2013-05-17 10:38Brad KingNote Added: 0033091
2013-05-31 12:44Brad KingRelationship addedrelated to 0011303
2013-10-07 10:10Robert MaynardNote Added: 0034070
2013-10-07 10:10Robert MaynardStatusresolved => closed

Notes
(0033046)
Brad King   
2013-05-15 16:24   
When you configure the CMake project do you build with a toolchain of the same architecture as the installed JDK?

The get_filename_component command tries both 32-bit and 64-bit views of the registry:

 http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmGetFilenameComponentCommand.cxx;hb=v2.8.10.2#l38 [^]

The find_library command tries only the view matching the target architecture of the build:

 http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmFindCommon.cxx;hb=v2.8.10.2#l381 [^]
(0033047)
vitaut   
2013-05-15 17:14   
I run CMake in Visual Studio x64 Win64 Command Prompt with cl reporting "Microsoft (R) C/C++ Optimizing Compiler Version 16.00.30319.01 for x64" and I have 64-bit JDK installed so I think the answer is yes.
(0033060)
Brad King   
2013-05-16 11:51   
What generator are you using? The VS IDE generators do not care about the environment from which you run CMake, only the Makefile and Ninja generators do.
(0033081)
vitaut   
2013-05-17 00:22   
I am using the default generator which is "Visual Studio 10". Tried "Visual Studio 10 Win64", but with the same result (JNI not found).
(0033082)
Brad King   
2013-05-17 08:09   
On Win7 64-bit with CMake 2.8.11 I ran the example from the description with the "Visual Studio 10 Win64" generator and got:

java_install_version: 1.7
JAVA_AWT_LIBRARY: C:/Program Files/Java/jdk1.7.0_21/lib/jawt.lib
java_library_path: C:/Program Files/Java/jdk1.7.0_21/lib
JAVA_AWT_LIBRARY2: C:/Program Files/Java/jdk1.7.0_21/lib/jawt.lib

Then I switched to the "Steps to Reproduce" example and got:

-- Found JNI: C:/Program Files/Java/jdk1.7.0_21/lib/jawt.lib
(0033088)
vitaut   
2013-05-17 10:01   
Strange. Here's what I get:

C:\temp\test>cmake -G "Visual Studio 10 Win64"
java_install_version: 1.7
JAVA_AWT_LIBRARY: JAVA_AWT_LIBRARY-NOTFOUND
java_library_path: C:/Program Files/Java/jdk1.7.0_21/lib
JAVA_AWT_LIBRARY2: C:/Program Files/Java/jdk1.7.0_21/lib/jawt.lib
-- Configuring done
-- Generating done
-- Build files have been written to: C:/temp/test
(0033089)
vitaut   
2013-05-17 10:25   
I've tried deleting all the generated files and not only CMakeCache.txt, and then re-running cmake -G "Visual Studio 10 Win64" and JNI is found now.

Here's what I did before
1. cmake .
JNI not found.
2. del CMakeCache.txt
3. cmake -G "Visual Studio 10 Win64"
JNI not found.

So it seems CMake re-uses some information other than CMakeCache.txt between configurations which prevents finding JNI. I'm not sure if it is something expected or not.

Thanks
(0033090)
Brad King   
2013-05-17 10:36   
This is expected. You need to use a fresh build tree to change generators.
(0033091)
Brad King   
2013-05-17 10:38   
Actually you may have hit issue 0013756 with CMake 2.8.10.2 when trying to change generators, and that was fixed here:

 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1df09e57 [^]
(0034070)
Robert Maynard   
2013-10-07 10:10   
Closing resolved issues that have not been updated in more than 4 months.