http://www.oracle.com/technology/software/products/berkeley-db/xml/index.html.http://www.oracle.com/technology/software/products/berkeley-db/htdocs/popup/xml/2.5.16/xml-targz.html.$PTII/vendors/misc
is where $PTII/configure will look for Oracle Berkeley XML DB.
cd $PTII/vendors/misc tar -zxf ~/Downloads/dbxml-2.5.16.tar.gz
buildall.sh.
--enable-java, the dbxml.jar
and db.jar Java jars will be created in your_installation_path/install/lib/.
cd dbxml-2.5.16 sh buildall.sh -b 64 --enable-java >& build.out & tail -f build.out
your_installation_path/dbxml-2.5.16/install/bin,
and execute the command dbxml
cd $PTII/vendors/misc/dbxml-2.5.16/install/bin
./dbxml
Note: if the system cannot find this command, try to include the whole path of this command your_installation_path/dbxml-2.5.16/install/bin/dbxml.
- The dbxml prompt (
dbxml>) will appear. You can test whether the XMLDB runs properly by testing with the guidance from your_installation_path/dbxml-2.5.16/dbxml/docs/intro_xml/running.html.
- Add
dbxml.jar and db.jar to your
classpath. The easiest way is to run configure:
cd $PTII
./configure
Problem
32 vs. 64 bits
Under Mac OS X, Java 1.5 was 32 bits, Java 1.6 was 64 bits. So, under
Mac OS X with Java 1.5, we did not have the -b 64 flag,
under Java 1.6, we did have the -b 64 flag. One way to
tell whether this flag is necessary is to use java
-version to determine whether the JVM is 64 bit:
bash-3.2$ java -version
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02-279-9M3165)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01-279, mixed mode)
In the above, the JVM is 64-bit.
Then use file on the shared library.
In the example below, dbxml was built without -b 64 which
is wrong for Java 1.6 under Mac OS X:
bash-3.2$ file $PTII/vendors/misc/dbxml-2.5.16/install/lib/libdb_java-4.8.jnilib
libdb_java-4.8.jnilib: Mach-O dynamically linked shared library i386
Building under Java 1.5
This is no longer relevant, as the Ptolemy build uses Java 1.6, but
we leave it as a record of past problems.
Unfortunately, the build under Mac OS X may fail because
jni.h
cannot be found.
The error message will be something like
ln -s .libs/libdb_cxx-4.8.a libdb_cxx.a
./libtool --mode=compile gcc -c -I. -I../dist/.. -O3 -fno-strict-aliasing ../dist/../libdb_java/db_java_wrap.c
libtool: compile: gcc -c -I. -I../dist/.. -O3 -fno-strict-aliasing ../dist/../libdb_java/db_java_wrap.c -fno-common -DPIC -o .libs/db_java_wrap.o
../dist/../libdb_java/db_java_wrap.c:137:17: error: jni.h: No such file or directory
See http://forums.oracle.com/forums/thread.jspa?messageID=3484341.
A hack is to create links in /usr/local/include to
your jni.h
bash-3.2$ sudo -i
Password:
Claudius-Ptolemaus-MacBook-Pro:~ root# cd /usr/local/include
Claudius-Ptolemaus-MacBook-Pro:include root# which java
/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Commands/java
Claudius-Ptolemaus-MacBook-Pro:include root# ln -s /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Headers/* .
Claudius-Ptolemaus-MacBook-Pro:include root# exit
The problem with this hack is that if you change versions of Java,
then your /usr/local/include will have links to the old version.