2008-09-16

Build and install of OpenAccess

Decompress the tarball,
tar zxvf oaSrc_XXX.tar.gz # set this directory as OA_TOP_DIR
cd oa/

Modify the compiler setting in the Make rules for your system,
cd $OA_TOP_DIR
cd build/make
# According to your system, modify the *.variables.
# For example, in linux 64bit system, the file to modify is linux_rhel64_gcc411_64.variables if you also want to make the OA by gcc4.1.1

Set the necessary environment variables:
setenv LEFDEF_HOME /proj/nsio/tools/lefdef/current_gcc411
setenv TCL_HOME    /proj/nsio/tools/tcltk/current_gcc411
setenv FLEX_HOME   /usr
setenv BISON_HOME  /usr
setenv ZLIB_HOME   /usr
setenv OA_COMPILER gcc411

Execute make,
# LIB_MODE=archive shared relocatable
# OPTMODE=opt dbg optMT dbgMT
make install OPTMODE=opt LIB_MODE=shared

If you want to package OpenAccess into your application, the installation path should comply with the result from oaGetLibPath. For example, the root installation path is in /proj/MY_APP/oa,
  1. The OA libraries should be put in /proj/MY_APP/oa/lib/linux_rhel30_gcc411_64/dbg
  2. The DM plugins should be put in /proj/MY_APP/data/plugins.
  3. The OA binaries should be put in /proj/MY_APP/bin.
The string linux_rhel30_gcc411_64 describing the system you are using is from the result of oaGetLibPath.

I spent some time on figuring out where to place DM plugins in the installation path. They were placed some place in the installation path, but the OA complains the wrong installation DM plugins at runtime. So I looked into the code and found out as long as the plugins are placed in a directory 3 levels beneath the root installation path. It will be an OK place for them. But why?

265 const char *
266 InstallDir::getInstallDir()
267 {
268     if (instDir.size()) {
269         return instDir.c_str();
270     }
271
272     instDir = getLibPath();
273
274     size_t idx = string::npos;
275


Look at line 276, it's a hard-coded magic number 4 indicating that the plugin should be searched 3 levels down the root installation. Then, I change the DM plugin path in the installation to something like /proj/MY_APP/1/2. At runtime, OA doesn't complain about the wrong DM plugin path. This time, it hangs forever. I was wondering if it is in the forever loop trying to get the database lock. But, I was tired. So I turned to use the structure returned from oaGetLibPath. And it worked as a charm.

Besides, the OA_BIT and OA_MODE are another make variables you can use to control your build. In my system, they are
setenv OA_BIT 64
setenv OA_MODE opt

沒有留言:

張貼留言