Jdk-8010250 Sign Specific Binaries For Mac

• Jdk-8010250 Sign Specific Binaries For Mac Download
• Jdk-8010250 Sign Specific Binaries For Mac Os
• Jdk-8010250 Sign Specific Binaries For Mac

Good news everyone! You can now put your Java 8 applications onto the mac app store. How do I know?

Jdk-8010250 Sign Specific Binaries For Mac Download

See the sign-off page for details. Tested Platform Failed Passed Total Test Time (s). To update your build to use this specific build, you can use the software repository at. Mac OSX (Mac/Cocoa/x86_64) eclipse-SDK-4.8-macosx-cocoa-x86_64.dmg. Source Tarball.

Because I put a little hackathon app I wrote. The better news is that Oracle is working on making this very simple with the JavaFX packager. You can get some of the early bits in the open source repo for OpenJFX (building and using open source code is left as an exercise for the reader). If you don’t want to wait for the code to get an official release and you are comfortable doing stuff by hand then here are the steps you will need to follow. Prepare your Environment First you will need to be signed up as part of the Mac Develoer program at developer.apple.com. For this tutorial I will presume your name is Alice Duke, that your Team ID is JJJJJJJJJJ and that the app you are shipping is titled AwesomeJavaApp.

You will of course need to change these to real values. Download your signing keys if you haven’t done so already. You will need both the Mac App Distribution and Mac Installer Distribution, and they should automatically be placed in your keychain under the names 3rd Party Mac Developer Application: Alice Duke (JJJJJJJJJJ) and 3rd Party Mac Developer Installer: Alice Duke (JJJJJJJJJJ). You will also need an entitlements file. Read all about them at the. You will have to turn on the app-sandbox entitlement as well as any of the other entitlements you will be using.

Be sure to keep track of what entitlements you grand and why they are needed. Apple will be asking you to justify every one of them. Prepare the Application Next, create your Mac.app bundle the normal way you are doing with the javafxpackager, Ant, Maven, or Gradle build. Make sure this app works as it is what we will be bundling up. Next, you will need to copy the info.plist from the existing JDK or JRE into the embedded JRE in your app. It should be either at /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Info.plist or /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Info.plist, but it is likely to be the first one.

Copy this file to AwesomeJavaApp.app/Contents/PlugIns/jdk1.8.0.jdk/Contents/Info.plist. Cp /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Info.plist AwesomeJavaApp.app/Contents/PlugIns/jdk1.8.0.jdk/Contents/Info.plist Now we need to strip a library. The Mac App Store doesn’t accept apps that even mention the deprecated Quicktime API, so we will need to remove the media capabilities tom JavaFX.

If your app uses the JavaFX media apis you are out of luck for the time being. There is a to fix this in a future release. The good news is that the Java 8 license lets us fix the problem, at least when it comes to JavaFX. Remove the file libjfxmedia.dylib. Rm AwesomeJavaApp.app/Contents/PlugIns/jdk1.8.0.jdk/Contents/Home/jre/lib/libjfxmedia.dylib Sign the Application Signing the app (in may different places) is next.

Apple loves their cryptographic hashes. First, you may need to make the JDK in the app bundle writeable. The codesign program won’t sign read-only binaries. Chmod -R +w AwesomeJavaApp.app/Contents/PlugIns/jdk1.8.0.jdk should do the trick.

You need to sign all jars, dylibs, and executable files in the bundle (with one exception). Enumerating them is left as an exercise to the reader. Any decent build tool can do it for you. You will need to sign it with both the identity you have and the entitlements you want codesign -f -s '3rd Party Mac Developer Application: Alice Duke' -entitlements There is one caveat.

Don’t sign the main excitable of the app bundle. It is in Contents/MacOS and has the name of your application, for example it would be AwesomeJavaApp.app/Contents/MacOS/AwesomeJavaApp. We will get that signed another way. Another quirk is that you can give different entitlements to each file. In the javafxpackger we sign with an entitlements file that contains only the app-sandbox and inherit entitlements, so they inherit all the entitlements from the main application.

Next, you will want to sign the Java directory itself. Actually you need to sign all plugins and frameworks in your app, but the overwhelming majority of java apps will only have one plugin: Java. Codesign -f -deep -s '3rd Party Mac Developer Application: Alice Duke' -entitlements AwesomeJavaApp.app/PlugIns/jdk1.8.0.jdk Finally, we can sign the application itself.

Yes, we can actually shave the yak at this point. Codesign -f -deep -s '3rd Party Mac Developer Application: Alice Duke' -entitlements AwesomeJavaApp.app You may or may not need all of the flags I’ve show with codesign, as I have not exhaustively tested them in all the possibly combinations. You may not need the -deep flag, but adding it will not get you out of signing all the interior jars and libraries. You may not need the -f flag but it insures that your signature will be the only one. Finally, you may want to add a -verbose=4 flag to see all the gory details. Packaging for Install I bet you thought you were done? Now we need to create an installer package to send to the app store.

Use the productbuld too to generate the need file productbuild -component AwesomeJavaApp.app /Applications -s '3rd Party Mac Developer Installer: Alice Duke' AwesomeJavaApp.pkg Note that you are signing this with the second key you downloaded: the one for installers. If you feel the need you can test the install: sudo installer -store -pkg AwesomeJavaApp.pkg Now you can load it into the Mac App store using the Application Loader tool. You will first need to go to iTunes Connect and set things up. But we have now left the Java specific part of the assembly so there are many other blog posts out there by more qualified and experienced Mac App Store developers.

Last Words There are many other potholes that you could run into. Two I hit were not having a 512x512@2x icon, and another was a dispute about copyright on an icon.

I changed the icon rather than wade through the appeals process to prove that the icon was in the public domain. I plan on keeping this post up to date with any changes or corrections, so feel free to bookmark this page. Posted by Danno Ferrin Apr 10 th, 2014.

Run make and make install Or, as a sequence of commands to execute: tar xfz gromacs-4.6.5.tar.gz cd gromacs-4.6.5 mkdir build cd build cmake.DGMXBUILDOWNFFTW=ON make sudo make install This will download and build first the prerequisite FFT library followed by GROMACS. If you already have FFTW installed, you can remove that argument to cmake.

Overall, this build of GROMACS will be correct and reasonably fast on the machine upon which CMake ran. It will generally be 30-50% faster than GROMACS 4.5.x, but if you want to get the maximum value for your hardware with GROMACS, you'll have to read further. Sadly, the interactions of hardware, libraries, and compilers are only going to continue to get more complex. GROMACS can be compiled for any distribution of Linux, Mac OS X, Windows (native, Cygwin or MinGW), BlueGene, Cray and many other architectures. Technically, it can be compiled on any platform with an ANSI C compiler and supporting libraries, such as the GNU C library.

However, Gromacs also comes with many hardware-specific extensions to provide very high performance on those platforms, and to enable these we have slightly more specific requirements since old compilers do not support new features, or they can be buggy. GROMACS requires an ANSI C compiler that complies with the C89 standard. For best performance, the GROMACS team strongly recommends you get the most recent version of your preferred compiler for your platform (e.g. GCC 4.7 or Intel 12.0 or newer on x86 hardware). There is a large amount of GROMACS code introduced in version 4.6 that depends on effective compiler optimization to get high performance - the old raw assembly-language kernel routines are all gone. Unfortunately this makes GROMACS more sensitive to the compiler used, and the binary will only work on the hardware for which it is compiled, but the good news is that it has enabled us to significantly accelerate performance compared to version 4.5. The GPU support from GROMACS version 4.5 using OpenMM is still contained in the code, but in the “user contributions” section ( src/contrib).

You will need to set -DGMXOPENMM=on -DGMXGPU=off -DGMXMPI=off -DGMXTHREADMPI=off in order to build it. It also requires CUDA, and remains the only hardware-based acceleration available for implicit solvent simulations in GROMACS at the moment. However, the long-term plan is to enable this functionality in core Gromacs, and not have the OpenMM interface supported by the GROMACSteam. In some cases, OpenMP parallelism is an advantage for GROMACS, but support for this is generally built into your compiler and detected automatically. The one common exception is Mac OS X, where the default clang compiler currently does not fully support OpenMP. You can install gcc version 4.7 instead, but the currently available binary distribution of gcc uses an old system assembler that does not support AVX acceleration instructions. There are some examples on the Internet where people have hacked this to work, but presently the only straightforward way to get both OpenMP and AVX support on Mac OS X is to get the Intel compiler.

In summary, for maximum performance you will need to examine how you will use GROMACS, what hardware you plan to run on, and whether you can afford a non-free compiler for slightly better performance. The only way to find out is unfortunately to test different options and parallelization schemes for the actual simulations you want to run. You will still get good performance with the default build and runtime options (better than in version 4.5), but if you truly want to push your hardware to the performance limit the days of just blindly starting programs like ' mdrun' are gone. GROMACS requires CMake version 2.8.0 or higher.

Lower versions will not work. You can check whether CMake is installed, and what version it is, with cmake -version.

If you need to install CMake, then first check whether your platform's package management system provides a suitable version, or visit for pre-compiled binaries, source code and installation instructions. The GROMACS team recommends you install the most recent version of CMake you can. If you need to compile CMake yourself and have a really old environment, you might first have to compile a moderately recent version (say, 2.6) to bootstrap version 2.8. This is a one-time job, and you can find lots of documentation on the CMake website if you run into problems. If you build FFTW from source yourself, get the most recent version and follow its installation guide available from.

Choose the precision (i.e. Single or float vs. double) to match what you will later require for GROMACS. There is no need to compile with threading or MPI support, but it does no harm. On x86 hardware, compile only with -enable-sse2 (regardless of precision) even if your processors can take advantage of AVX extensions.

Since GROMACS uses fairly short transform lengths we do not benefit from the FFTW AVX acceleration, and because of memory system performance limitations, it can even degrade GROMACS performance by around 20%. There is no way for GROMACS to limit the use to SSE2 acceleration at run time if AVX support has been compiled into FFTW, so you need to set this at compile time. The best way to use CMake to configure GROMACS is to do an “out-of-source” build, by making another directory from which you will run CMake. This can be a subdirectory or not, it doesn't matter. It also means you can never corrupt your source code by trying to build it!

So, the only required argument on the CMake command line is the name of the directory containing the CMakeLists.txt file of the code you want to build. For example, download the source tarball and use $ tar xfz gromacs-4.6.5.tgz $ cd gromacs-4.6.5 $ mkdir build-cmake $ cd build-cmake $ cmake. CMake works in an iterative fashion, re-running each time a setting is changed to try to make sure other things are consistent. Once things seem consistent, the iterations stop. Once cmake returns, you can see all the settings that were chosen and information about them by using e.g.

The curses interface $ ccmake. You can actually use ccmake (available on most Unix platforms, if the curses library is supported) directly in the first step, but then most of the status messages will merely blink in the lower part of the terminal rather than be written to standard out.

Most platforms including Linux, Windows, and Mac OS X even have native graphical user interfaces for CMake, and it can create project files for almost any build environment you want (including Visual Studio or Xcode). Check out for general advice on what you are seeing and how to navigate and change things.

The settings you might normally want to change are already presented. If you make any changes, then ccmake will notice that and require that you re-configure (using ' c'), so that it gets a chance to make changes that depend on yours and perform more checking. This might require several configuration stages when you are using ccmake - when you are using cmake the iteration is done behind the scenes. Once you become comfortable with setting and changing options, you may know in advance how you will configure GROMACS. If so, you can speed things up by invoking cmake with a command like: $ cmake.DGMXGPU=ON -DGMXMPI=ON -DCMAKEINSTALLPREFIX=/home/marydoe/programs to build with GPUs, MPI and install in a custom location. You can even save that in a shell script to make it even easier next time.

You can also do this kind of thing with ccmake, but you should avoid this, because the options set with ' -D' will not be able to be changed interactively in that run of ccmake. Often it is possible to ensure portability by choosing the least common denominator of SIMD support, e.g. SSE2 for x86 and ensuring the CMake option GMXUSERDTSCP is off if any of the target CPU architectures does not support the RDTSCP instruction. However, we discourage attempts to use a single GROMACS installation when the execution environment is heterogeneous, such as a mix of AVX and earlier hardware, because this will lead to slow binaries (especially mdrun), on the new hardware. Building two full installations and locally managing how to call the correct one (e.g. Using the module system) is the recommended approach.

Alternatively, as at the moment the GROMACS tools do not make strong use of SIMD acceleration, it can be convenient to create an installation with tools portable across different x86 machines, but with separate mdrun binaries for each architecture. To achieve this, one can first build a full installation with the least common denominator SIMD instruction set, e.g. SSE2, then build separate mdrun binaries for each architecture present in the heterogeneous environment. By using custom binary and library suffixes for the mdrun-only builds, these can be installed to the same location as the ”generic“ tools installation.

S mentioned above, sometimes vendor BLAS and LAPACK libraries can provide performance enhancements for GROMACS when doing normal-mode analysis or covariance analysis. For simplicity, the text below will refer only to BLAS, but the same options are available for LAPACK. By default, CMake will search for BLAS, use it if it is found, and otherwise fall back on a version of BLAS internal to GROMACS.

Jdk-8010250 Sign Specific Binaries For Mac Os

The CMake option GMXEXTERNALBLAS will be set accordingly. The internal versions are fine for normal use. If you need to specify a non-standard path to search, use -DCMAKEPREFIXPATH=/path/to/search.

If you need to specify a library with a non-standard name (e.g. ESSL on AIX or BlueGene), then set -DGMXBLASUSER=/path/to/reach/lib/libwhatever.a.

To link statically against external libraries as well, the GMXPREFERSTATICLIBS=ON option can be used. Note, that in general CMake picks up whatever is available, so this option only instructs CMake to prefer static libraries when both static and shared are available. If no static version of an external library is available, even when the aforementioned option is ON, the shared library will be used. Also note, that the resulting binaries will still be dynamically linked against system libraries if that is all that is available (common on Mac OS X). It is sometimes convenient to have different versions of the same GROMACS libraries installed. The most common use cases have been single and double precision, and with and without MPI. By default, GROMACS will suffix binaries and libraries for such builds with ' d' for double precision and/or ' mpi' for MPI (and nothing otherwise).

This can be controlled manually with GMXDEFAULTSUFFIX (ON/OFF), GMXBINARYSUFFIX (takes a string) and GMXLIBSSUFFIX (also takes a string). This can also be useful for resolving libary-naming conflicts with existing packges ( GMXPREFIXLIBMD also can be useful). For instance, to set a custom suffix for binaries and libraries, one might specify. Since 2011, the GROMACS development uses an automated system where every new patch is subject to regression testing. While this improves reliability quite a lot, not everything is tested, and since we increasingly rely on cutting edge compiler features there is non-negligible risk that the default compiler on your system could have bugs.

Jdk-8010250 Sign Specific Binaries For Mac

We have tried our best to test and refuse to use known bad versions in CMake, but we strongly recommend that you run through the regression tests yourself. It only takes a few minutes, after which you can trust your build. The simplest way to run the checks is to build GROMACS with -DREGRESSIONTESTDOWNLOAD, and run make check. GROMACS will automatically download and run the tests for you. Alternatively, you can download and unpack the tarball yourself from, and use the advanced CMake option -DREGRESSIONTESTPATH=/path to specify the path to the unpacked tarball, which will then be used for testing (can set -DREGRESSIONTESTDOWNLOAD=NO at the same time if downloading the file prevents successful configuration.).

If this doesn't work, then please read on. Hopefully you will get a report that all tests have passed. If there are individual failed tests it could be a sign of a compiler bug, or that a tolerance is just a tiny bit too tight. Check the output files the script directs you too, and try a different or newer compiler if the errors appear to be real. If you cannot get it to pass the regression tests, you might try dropping a line to the gmx-users mailing list, but then you should include a detailed description of your hardware and an example logfile from mdrun (which contains valuable information in the header). Post to the GROMACS users emailing list gmx-users for assistance. Be sure to give a full description of what you have done and why you think it didn't work.

Give details about the system on which you are installing. Copy and paste your command line and as much of the output as you think might be relevant - certainly from the first indication of a problem.

In particular, please try to include at least the header from the mdrun logfile, and preferably the entire file. People who might volunteer to help you do not have time to ask you interactive detailed follow-up questions, so you will get an answer faster if you provide as much information as you think could possibly help.

High quality bug reports tend to receive rapid high quality answers. Building on Windows using native compilers is rather similar to building on Unix, so please start by reading the above.

Then, download and unpack the GROMACS source archive. The UNIX-standard.tar.gz format can be managed on Windows, but you may prefer to browse to obtain a zip format file, which doesn't need any external tools to unzip on recent Windows systems. Make a folder in which to do the out-of-source build of GROMACS.

For example, make it within the folder unpacked from the source archive, and call it “build-cmake”. For CMake, you can either use the graphical user interface provided on Windows, or you can use a command line shell with instructions similar to the UNIX ones above. If you open a shell from within your IDE (e.g. Microsoft Visual Studio), it will configure the environment for you, but you might need to tweak this in order to get either a 32-bit or 64-bit build environment. The latter provides the fastest executable. If you use a normal Windows command shell, then you will need to either set up the environment to find your compilers and libraries yourself, or run the vcvarsall.bat batch script provided by MSVC (just like sourcing a bash script under Unix).

Computation on BlueGene floating-point units is always done in double-precision. However, single-precision builds of GROMACS are still normal and encouraged since they use cache more efficiently. The BlueGene hardware automatically converts values stored in single precision in memory to double precision in registers for computation, converts the results back to single precision correctly, and does so for no additional cost. As with other platforms, doing the whole computation in double precision normally shows no improvement in accuracy and costs twice as much time moving memory around. While it is our best belief that GROMACS will build and run pretty much everywhere, it's important that we tell you where we really know it works because we've tested it. We do test on Linux, Windows, and Mac with a range of compilers and libraries for a range of our configuration options. Every commit in our git source code repository is currently tested on x86 with gcc versions ranging from 4.4 through 4.7, and versions 12 and 13 of the Intel compiler as well as Clang version 3.1 through 3.3.

For this we use a variety of GNU/Linux flavors and versions as well as recent version of Mac OS X. Under Windows we test both MSVC and the Intel compiler. For details, you can have a look at the continuous integration server at.