Hide Forgot
Description of problem: This problem was discovered while working on the Dogtag Certificate System product. JAVA_LIB_INSTALL_DIR used to ALWAYS be equal to "/usr/lib/java", but as of Fedora 16, JAVA_LIB_INSTALL_DIR is now equal to "/usr/lib64/java" when building 64-bit on 64-bit platforms. For 32-bit on 32-bit platforms, or 32-bit on 64-bit platforms, the value for JAVA_LIB_INSTALL_DIR should remain equal to "/usr/lib/java". (refer to "Bugzilla Bug #665576 - "build-classpath swt" fails on 64bit", and "Bugzilla Bug #734590 - Refactor JNI libraries for Fedora 16+ . . .". Although the following "work-around" for Dogtag Certificate System has been proposed: Work around is to use -DJAVA_LIB_INSTALL_DIR=/usr/lib64/java when building by hand, but the compose scripts don't know to do that yet. Matthew Harmsen wrote: This should already be fixed. Actually, this logic is contained in the individual spec files, not the compose scripts. That being said, the compose scripts invoke the spec files, but the spec files have already been changed to override this behavior based upon the value of the "%{_jnidir}" variable in the 'jpackage-utils' package per 'Bugzilla Bug #665576 - "build-classpath swt" fails on 64bit' and in the corresponding PKI bug 'Bugzilla Bug #734590 - Refactor JNI libraries for Fedora 16+ . . .'). For example, the following 'cmake' invocation can be found in the "pki-core.spec" file: %cmake -DVAR_INSTALL_DIR:PATH=/var -DBUILD_PKI_CORE:BOOL=ON -DJAVA_LIB_INSTALL_DIR=%{_jnidir} .. This allows the trunk to continue building on Fedora 14 and Fedora 15 (whose 'jpackage-utils' package contains the old definition of the "%{_jnidir}" macro) as well as Fedora 16 and later. HOWEVER, Adam Young wrote the following: As I am the only one building by hand,and this trips me up every time, I think it is safe to say it is going to mess up outside developers when they try to build, too. We need to embed that %{_jnidir} logic inside the CMake system
NOTE: This would also introduce the need for CMake to contain a dependency on "jpackage" (where the "%{_jnidir}" macro is defined.
The only reference to JAVA_LIB_INSTALL_DIR I can find in the cmake code is in the comment in UseJava.cmake: # If the target is a JNI library, utilize the following commands to # create a JNI symbolic link: # # set(CMAKE_JNI_TARGET TRUE) # set(CMAKE_JAVA_TARGET_VERSION 1.2.0) # add_jar(shibboleet shibbotleet.java) # install_jar(shibboleet ${LIB_INSTALL_DIR}/shibboleet) # install_jni_symlink(shibboleet ${JAVA_LIB_INSTALL_DIR}) So I'm really at a loss as to how you expect to "embed the %{_jnidir} logic inside the cmake system". Do you want to add -DJAVA_LIB_INSTALL_DIR=%{_jnidir} to the %cmake rpm macro? I would prefer a %{cmake_jni} macro in jpackage similar to %{cmake_kde4} in kde-filesystem.
I concur with orion, 1. It's not clear what you're asking for , but... 2. My best guess is that what you want to achieve can be done elsewhere more easily to provide the rpm macros you want, though I'm curious what's so bad about the current/status-quo of just using: %cmake -DVAR_INSTALL_DIR:PATH=/var -DBUILD_PKI_CORE:BOOL=ON -DJAVA_LIB_INSTALL_DIR=%{_jnidir} .. (or perhaps to avoid all the copy-n-paste duplicated code, and for convenience, do define your own %{cmake_jni} somewhere), say in /etc/rpm/macros.jpackage or even /etc/rpm/macros.jpackage-cmake owned by a subpkg jpackage-utils-cmake if you insist on avoiding a dependency on cmake.
The end state is that when I build, the CMake system should determine where the JNI libraries are, and I should not have to explicitly pass that value on the CMake command line. cmake -DJAVA_LIB_INSTALL_DIR=/usr/lib64/java ... should not be necessary. THe only time that JAVA_LIB_INSTALL_DIR would be other than /usr/lib64/java on a 64 bit system would be when compiling 32 bit native libraries, a very uncommon undertaking.
In this case there seems to be a couple issues: - jss is not packaged according to the current guidelines and puts jss4.jar in %{_libdir}/java instead of %{_libdir}/jss. - In cmake if you: include(GNUInstallDirs) you will get a variable called CMAKE_INSTALL_LIBDIR set to lib or lib64 as appropriate. This can be use by the project to set paths, e.g.: set(JAVA_LIB_INSTALL_DIR /usr/${CMAKE_INSTALL_LIBDIR}/java)
(In reply to comment #5) > In this case there seems to be a couple issues: > > - jss is not packaged according to the current guidelines and puts jss4.jar in > %{_libdir}/java instead of %{_libdir}/jss. > There was a lot of discussions surrounding the placement of JNI jar files as documented in: * Bugzilla Bug #665576 - "build-classpath swt" fails on 64bit * Bugzilla Bug #734590 - Refactor JNI libraries for Fedora 16+ . . . That being said, I do not believe that the existing instructions have been updated to document these decisions: * http://fedoraproject.org/wiki/Packaging:Java#Packaging_JAR_files_that_use_JNI However, for simplicity, I will add symlinks to the three JNI components that Dogtag utilizes: * %{_libdir}/jss/jss4.jar -> %{_libdir}/java/jss4.jar * %{_libdir}/osutil/osutil.jar -> %{_libdir}/java/osutil.jar * %{_libdir}/symkey/symkey.jar -> %{_libdir}/java/symkey.jar While this is somewhat reversed from some of the statements in the existing Fedora packaging guidelines for JNI, I believe it should suffice to add these benign (and somewhat informational) symlinks. > - In cmake if you: > > include(GNUInstallDirs) > > you will get a variable called CMAKE_INSTALL_LIBDIR set to lib or lib64 as > appropriate. This can be use by the project to set paths, e.g.: > > set(JAVA_LIB_INSTALL_DIR /usr/${CMAKE_INSTALL_LIBDIR}/java) I have created a TRAC Task for the integration of these changes: * https://fedorahosted.org/pki/ticket/109