Uninstalling MacFuse on Lion

Last Updated on Samedi, 28 janvier 2012 09:15 Written by Henri Gomez Samedi, 28 janvier 2012 09:13

If you installed MacFuse on Lion (10.7) and tried to uninstall you may encountered the following error :

sudo /Library/Filesystems/fusefs.fs/Support/uninstall-macfuse-core.sh
MacFUSE Uninstaller: Can not find the Archive.bom for MacFUSE Core package.

Uninstaller didn’t check for Lion (uname -r reporting 11.x).
So fix is easy, just edit uninstaller script /Library/Filesystems/fusefs.fs/Support/uninstall-macfuse-core.sh and add 11*) in case next to 10*)

...

OS_RELEASE=`/usr/bin/uname -r`
case "$OS_RELEASE" in
  8*)
    log "Incorrect uninstall. Use the Tiger version please."
    exit 1
    ;;
  9*)
    PACKAGE_RECEIPT="$INSTALL_VOLUME/Library/Receipts/MacFUSE Core.pkg"
    OUTER_PACKAGE_RECEIPT="$INSTALL_VOLUME/Library/Receipts/MacFUSE.pkg"
    BOMFILE="$PACKAGE_RECEIPT/Contents/Archive.bom"
    ;;
  10*|11*)
     PACKAGE_RECEIPT=""
     BOMFILE="$INSTALL_VOLUME/var/db/receipts/com.google.macfuse.core.bom"
     ;;
esac

Building Universal Apache Tomcat Native Library on OS/X

Last Updated on Jeudi, 1 décembre 2011 08:39 Written by Henri Gomez Mercredi, 13 juillet 2011 03:41

I recently notice that my Apache Tomcat running on OS/X 10.6.8 couldn’t use Apache Tomcat Native Library.

INFO: The APR based Apache Tomcat Native library which allows optimal
performance in production environments was not found on the
java.library.path:
.:/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java
Jul 13, 2011 11:02:30 AM org.apache.coyote.http11.Http11Protocol init

After digging around and with the help of ASFer Mladen Turk, I figure my previous build was stick to 64bits mode only and I switched my JVM to 32bits mode using -d32.

The fix was then easy, just had to rebuild tomcat-native and asking OS/X gcc to produce both 32/64 bits model library using the following CLFAGS/APXSLDFLAGS.

CFLAGS='-arch i386 -arch x86_64' APXSLDFLAGS='-arch i386-arch x86_64'

Here is a small script I’m using now to produce Apache Tomcat Native Library on OS/X.

curl http://mir2.ovh.net/ftp.apache.org/dist//tomcat/tomcat-connectors/native/1.1.20/source/tomcat-native-1.1.22-src.tar.gz -o tomcat-native-1.1.22-src.tar.gz
tar xvzf tomcat-native-1.1.22-src.tar.gz
cd tomcat-native-1.1.22-src/jni/native

CFLAGS='-arch i386 -arch x86_64' APXSLDFLAGS='-arch i386 -arch x86_64' ./configure --with-apr=/usr --with-ssl=/usr --with-java-home=/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
make clean
make

sudo cp .libs/libtcnative-1.0.1.22.dylib /usr/lib/java
sudo rm -f  /usr/lib/java/libtcnative-1.dylib
sudo ln -s /usr/lib/java/libtcnative-1.0.1.22.dylib /usr/lib/java/libtcnative-1.dylib

A note about Lion

If you get Java on Lion using the java command on terminal or via the Java Developer Package for Mac OS X 10.7, Java headers are not on the usual location and you could find them under /System/Library/Frameworks/JavaVM.framework/Versions/A/Headers

You should then update the configure command line like this :

CFLAGS='-arch i386 -arch x86_64' APXSLDFLAGS='-arch i386 -arch x86_64' ./configure --with-apr=/usr --with-ssl=/usr --with-java-home=/System/Library/Frameworks/JavaVM.framework/Versions/A/

Lion came with Xcode 4.1 and there is also an impact on linker side, libtcnative is now produced as libtcnative-1.0.dylib

Commands became so :

curl http://mir2.ovh.net/ftp.apache.org/dist//tomcat/tomcat-connectors/native/1.1.20/source/tomcat-native-1.1.22-src.tar.gz -o tomcat-native-1.1.22-src.tar.gz
tar xvzf tomcat-native-1.1.22-src.tar.gz
cd tomcat-native-1.1.22-src/jni/native

CFLAGS='-arch i386 -arch x86_64' APXSLDFLAGS='-arch i386 -arch x86_64' ./configure --with-apr=/usr --with-ssl=/usr --with-java-home=/System/Library/Frameworks/JavaVM.framework/Versions/A/
make clean
make

sudo cp .libs/libtcnative-1.0.dylib /usr/lib/java
sudo rm -f  /usr/lib/java/libtcnative-1.dylib
sudo ln -s /usr/lib/java/libtcnative-1.0.dylib /usr/lib/java/libtcnative-1.dylib

Apple JDK’s / OpenJDK – back to benchs

Last Updated on Dimanche, 17 avril 2011 05:59 Written by Henri Gomez Samedi, 16 avril 2011 02:52

It’s good to see works in progress for Aqua/Cocoa – AWT ports but what about JVM performances ?

Test vms

I selected 4 VMs to be tested


Apple Java 1.6.0_22 - java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04-314-10M3406a)
Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-314, mixed mode)



Apple Java 1.6.0_24 - java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07-348-10M3406a)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02-348, mixed mode)



OpenJDK 7 bsd-port - openjdk version "1.7.0-internal"
OpenJDK Runtime Environment (build 1.7.0-internal-henri_2011_04_11_08_24-b00)
OpenJDK 64-Bit Server VM (build 21.0-b07, mixed mode)



OpenJDK 7 macosx-port - openjdk version "1.7.0-internal"
OpenJDK Runtime Environment (build 1.7.0-internal-b00)
OpenJDK 64-Bit Server VM (build 21.0-b07, mixed mode)


Test system

My test system is an Apple iMac (iMac11,1 ) with Intel i7 2.80Ghz and 8Gb DDR3 1067Mhz, running under SnowLeopard 10.6.7 64bits.
I wanted to test 64bits VMs on a 64bits machine and this time use a stronger processor with more threads (ie: 4 cores with hyperthreading).

DaCapo Benchmarks

I keep the DaCapo 9.12-bach.

Bench tests launched with -n X, ie (java -jar dacapo-9.12-bach.jar -n 10 pmd)

Conclusion

Latest Apple JVM, 1.6.0-24 perform better than the old 1.6.0-22 in all of the tests and is near OpenJDK 7 results.

OpenJDK 7 from the bsd-port perform a little better than the macosx-port. The main difference in build is bsd-port is using stock gcc whereas macos-port use llvm-gcc.

bsd-port using stock-gcc during OpenJDK build

Compiling /Users/henri/Documents/jenkins/data/jobs/openjdk-1.7-bsdport-x86_64/workspace/hotspot/src/share/vm/adlc/arena.cpp
rm -f ../generated/adfiles/arena.o
/Users/henri/Documents/jenkins/data/jobs/openjdk-1.7-bsdport-x86_64/workspace/ALT_COMPILER_PATH/g++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 -I/Users/henri/Documents/jenkins/data/jobs/openjdk-1.7-bsdport-x86_64/workspace/hotspot/src/share/vm/prims -I/Users/henri/Documents/jenkins/data/jobs/openjdk-1.7-bsdport-x86_64/workspace/hotspot/src/share/vm -I/Users/henri/Documents/jenkins/data/jobs/openjdk-1.7-bsdport-x86_64/workspace/hotspot/src/cpu/x86/vm -I/Users/henri/Documents/jenkins/data/jobs/openjdk-1.7-bsdport-x86_64/workspace/hotspot/src/os_cpu/bsd_x86/vm -I/Users/henri/Documents/jenkins/data/jobs/openjdk-1.7-bsdport-x86_64/workspace/hotspot/src/os/bsd/vm -I/Users/henri/Documents/jenkins/data/jobs/openjdk-1.7-bsdport-x86_64/workspace/hotspot/src/os/posix/vm -I/Users/henri/Documents/jenkins/data/jobs/openjdk-1.7-bsdport-x86_64/workspace/hotspot/src/share/vm/adlc -I../generated -DASSERT -DTARGET_OS_FAMILY_bsd -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_bsd_x86 -DTARGET_OS_ARCH_MODEL_bsd_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1  -fno-rtti -fno-exceptions -pthread -fcheck-new -m64 -pipe -Werror -g -c -o ../generated/adfiles/arena.o /Users/henri/Documents/jenkins/data/jobs/openjdk-1.7-bsdport-x86_64/workspace/hotspot/src/share/vm/adlc/arena.cpp

macosx-port using llvm-gcc during OpenJDK build

Compiling /Users/henri/Documents/jenkins/data/jobs/openjdk-1.7-macosx-universal/workspace/hotspot/src/share/vm/adlc/arena.cpp
rm -f ../generated/adfiles/arena.o
llvm-g++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 -I/Users/henri/Documents/jenkins/data/jobs/openjdk-1.7-macosx-universal/workspace/hotspot/src/share/vm/prims -I/Users/henri/Documents/jenkins/data/jobs/openjdk-1.7-macosx-universal/workspace/hotspot/src/share/vm -I/Users/henri/Documents/jenkins/data/jobs/openjdk-1.7-macosx-universal/workspace/hotspot/src/cpu/x86/vm -I/Users/henri/Documents/jenkins/data/jobs/openjdk-1.7-macosx-universal/workspace/hotspot/src/os_cpu/bsd_x86/vm -I/Users/henri/Documents/jenkins/data/jobs/openjdk-1.7-macosx-universal/workspace/hotspot/src/os/bsd/vm -I/Users/henri/Documents/jenkins/data/jobs/openjdk-1.7-macosx-universal/workspace/hotspot/src/os/posix/vm -I/Users/henri/Documents/jenkins/data/jobs/openjdk-1.7-macosx-universal/workspace/hotspot/src/share/vm/adlc -I../generated -DASSERT -DTARGET_OS_FAMILY_bsd -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_32 -DTARGET_OS_ARCH_bsd_x86 -DTARGET_OS_ARCH_MODEL_bsd_x86_32 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1  -fno-rtti -fno-exceptions -pthread -fcheck-new -m32 -march=i586 -mstackrealign -pipe -Werror -g -c -o ../generated/adfiles/arena.o /Users/henri/Documents/jenkins/data/jobs/openjdk-1.7-macosx-universal/workspace/hotspot/src/share/vm/adlc/arena.cpp

Performances gain in OpenJDK7 VM vs latest Apple 6 VM is smaller than previously (see previous articles on Apple JDK vs OpenJDK 6), switching to OpenJDK 7 will not be only for pure speed but for functionalities.