Hyrax Package for OS-X: Difference between revisions
(→Hyrax) |
|||
Line 224: | Line 224: | ||
: make install | : make install | ||
== Building the OLFS == | |||
== PackageMaker == | == PackageMaker == | ||
Revision as of 20:22, 4 December 2010
Overview
The goal of this build was to produce a set of OS-X package installers for Hyrax. This includes bundling all of the Hyrax dependancies in an installer. In addition, all of the installed files (Hyrax and dependancies) should be confined to a single directory (tree) for the release. For this release I chose /usr/local/opendap./servers/hyrax-1.6.2
. This abbreviated is throughout this section as $prefix.
Development System
- Operating System
- OS-X 10.5.8
- Hardware
- MacBook Pro, 2.53GHz Intel Core 2 Duo, 4GB RAM
Building Hyrax Dependancies
In an effort to build a binary distribution for Hyrax I built all of our dependancies from source and rolled them up with PackageMaker. Here's an ordered list what got built an installed. Note that with some noted exceptions, each of the dependancies gets installed into its own directory.
szip
Required by: HDF4, hdf4_handler
File: szip-2.1.tar.gz*
The hdf4_handlers configure script does not provide options to allow the location of szip to be specified. When the hdf4_handlers configure script is run it looks in the --with-hdf4
location of szip, after that it looks in the usual places. In order to ensure that the correct szip (the one sent with the installer) was located we needed to install the szip library into the HDF4 library location.
- Build process
- ./configure --prefix=$prefix/deps/hdf-4.2.5
- make
- make check
- make install
zlib
Required by: HDF4, hdf4_handler
File: zlib-1.2.3.tar.gz
The hdf4_handlers configure script does not provide options to allow the location of zlib to be specified. When the hdf4_handlers configure script is run it looks in the --with-hdf4
location of zlib, after that it looks in the usual places. In order to ensure that the correct zlib (the one sent with the installer) was located we needed to install the zlib library into the HDF4 library location.
- Build process
- ./configure --prefix=$prefix/deps/hdf-4.2.5
- make
- make check
- make install
jpeg
Required by: HDF4, hdf4_handler
File: jpegsrc.v6b.tar.gz
The hdf4_handlers configure script does not provide options to allow the location of jpeg to be specified. When the hdf4_handlers configure script is run it looks in the --with-hdf4
location of jpeg, after that it looks in the usual places. In order to ensure that the correct jpeg (the one sent with the installer) was located we needed to install the jpeg library into the HDF4 library location.
- Build process
- ./configure --prefix=$prefix/deps/hdf-4.2.5
- make
- make check
- mkdir -p /usr/local/opendap/servers/hyrax-1.6.2/bin
- mkdir -p /usr/local/opendap/servers/hyrax-1.6.2/man/man1
- make install
- cp libjpeg.a $prefix/lib
- cp *.h $prefix/include
hdf5
Required by: hdf5_handler
File: hdf5-1.8.5-patch1.tar.gz
- Build process
- ./configure --prefix=$prefix/deps/hdf5-1.8.5-patch1
- make
- make check
- make install
netcdf
Required by: netcdf_handler
File: netcdf-3.6.3.tar.gz
- Build process
- ./configure --prefix=$prefix/deps/netcdf-3.6.3
- make
- make check
- make install
hdf4
Required by: hdf4_handler
File: hdf-4.2.5.tar.gz
- Build process
- ./configure --prefix=$prefix/deps/hdf-4.2.5 --disable-fortran --with-szlib=$prefix/deps/hdf-4.2.5 --with-netcdf=$prefix/deps/netcdf-3.6.3 --enable-production --enable-shared -with-jpeg=$prefix/deps/hdf-4.2.5
- make
- make check
- make install
icu
Required by: ncml_handler
File: icu4c-3_6-src.tgz
At run time ICU dependents failed to link correctly. Using otool -L
we could see in our libraries all of the ICU dependancies were shown like:
libicui18n.dylib.36 (compatibility version 36.0.0, current version 36.0.0)
When all the other libs had a full path like this:
/usr/local/opendap/servers/hyrax-1.6.2/lib/libbes_dap.3.dylib (compatibility version 5.0.0, current version 5.5.0)
The ICU build was producing only dynamic libraries where the links were only to the package name (no path). This also caused programs linking to one of theICU libs to get "path free" links.
James found the following in the last reply to this thread: http://bugs.php.net/bug.php?id=34089 (Thanks James!)
- The icu build system produces MAC platform libraries with an install name which does not include a path, this can be seen by running "otool -L" on any of the libraries or anything you build that links against any of the libraries.
- My solution was to edit icu's darwin config file found at "<icu-source-directory>/config/mh-darwin"
- By changing line 28 from:
-
LD_SONAME = -Wl,-compatibility_version -Wl,$(SO_TARGET_VERSION_MAJOR) -Wl,-current_version -Wl,$(SO_TARGET_VERSION) -install_name $(notdir $(MIDDLE_SO_TARGET))
- To:
-
LD_SONAME = -Wl,-compatibility_version -Wl,$(SO_TARGET_VERSION_MAJOR) -Wl,-current_version -Wl,$(SO_TARGET_VERSION) -install_name $(libdir)/$(notdir $(MIDDLE_SO_TARGET))
I made the recommended change and everything worked great.
- Build process
- ./runConfigureICU MacOSX --prefix=$prefix/deps/icu-3.6
- make
- make check
- make install
Hyrax
URL: http://scm.opendap.org/svn/branch/shrew/hyrax_1.6.2_release
Revision: 23904
- Summary
- I patched all of the Makefile.am targets for the OS-X packages (
make pkg
). I found numerous problems with small details such as incorrect package names for PackageMaker, Failure to preserve configure options in the package build. The code works now, but there are soma caveats for some of the packages. Details in each section below.
libdap
- Build process
- ./configure --prefix=$prefix
- make pkg
- make check
- make install
bes
- Build process
- ./configure --prefix=$prefix
- make pkg
- make check
- make install
dap-server
- Build process
- ./configure --prefix=$prefix
- make pkg
- make check
- make install
fileout_netcdf
The configure
command accepts:
- --with-netcdf=ARG netcdf directory
- --with-netcdf-include=ARG netcdf include directory
- --with-netcdf-libdir=ARG netcdf library directory
However for OS-X packages ONLY
--with-netcdf
will work!
- Build process
- ./configure --prefix=$prefix --with-netcdf=$prefix/deps/netcdf-3.6.3
- make pkg
- make check
- make install
freeform_handler
- Build process
- ./configure --prefix=$prefix
- make pkg
- make check
- make install
hdf4_handler
The configure
command accepts:
- --with-hdf4=ARG hdf4 directory
- --with-hdf4-include=ARG hdf 4 include directory
- --with-hdf4-libdir=ARG hdf 4 library directory
However for OS-X packages ONLY
--with-hdf4
will work!
- Build process
- ./configure --prefix=$prefix --with-hdf4=$prefix/deps/hdf-4.2.5
- make pkg
- make check
- make install
hdf5_handler
The configure
command accepts:
- --with-hdf5=ARG hdf5 directory
- --with-hdf5-include=ARG hdf5 include directory
- --with-hdf5-libdir=ARG hdf5 library directory
However for OS-X packages ONLY
--with-hdf5
will work!
- Build process
- ./configure --prefix=$prefix --with-hdf5=$prefix/deps/hdf5-1.8.5-patch1
- make pkg
- make check
- make install
nectdf_handler
The configure
command accepts:
- --with-netcdf=ARG netcdf directory
- --with-netcdf-include=ARG
- netcdf include directory
- --with-netcdf-libdir=ARG
- netcdf library directory
However for OS-X packages ONLY
--with-netcdf
will work!
- Build process
- ./configure --prefix=$prefix --with-netcdf=$prefix/deps/netcdf-3.6.3
- make pkg
- make check
- make install
ncml_handler
The configure
command accepts:
- --with-icu-prefix=PREFIX
- Prefix where icu is installed (optional)
- --with-icu-exec-prefix=EPREFIX
- Exec prefix where icu is installed (optional)
However for OS-X packages ONLY
--with-icu-prefix
will work!
- Build process
- ./configure --prefix=$prefix--with-icu-prefix=$prefix/deps/icu-3.6
- make pkg
- make check
- make install
Building the OLFS
PackageMaker
- When I built the package I got a large number warnings that the target install location had different owner/group than the install source.
- I used
chown
andchgrp
to change to install source files and folders to the same user as the target directories. This caused PackageMaker to hang permanently. Required a force quit (kill -9
). This was repeatable. - I changed back the ownership of the files to my user and group.
- In the contents "tab" on the Package I attempted to set the Owner and group to root / wheel.
- I still got the same warnings when building the package.
- I tested it on another mac
- It unpacked to
/usr/local/
as directed. - The files were all owned by root/wheel
- It unpacked to