Building software on SCO UnixWare/OpenUnix

A customer has a very large (> 400 users) SCO UnixWare system (also called OpenUnix), and I am called to build software on it often. In the process I've tripped across compatibility issues that have been annoying and substantial, so I'm summarizing the issues I've found in the hopes of helping others.

I will update this page was I find issues that are specific to this platform. Note that all of our building is done in the /source directory, which is actually a symlink to any place on the system that has room enough for the packages.

popt-1.7
rsync-2.5.5
diffutils-2.8.1
postfix-2.0.10

These weren't all installed at the same time, and intermediate OS upgrades may mean that options used to build one package may not apply to the next one.

popt-1.7

This is a command-line parsing library written in C, and it's used by quite a few other packages. This project's home can be found at freshmeat.

The SCO C compiler produces bogus code when the alloca() intrinsic is used from within another function call, such as:

char *dst = strcpy( alloca(n), src );

The compiler pushes the src argument onto the stack, and then calls alloca() to make the local buffer. But this operation changes the stack, completely losing track of the src parameter pushed earlier. When strcpy() gets called, the stack is messed up badly, and it only gets worse when this function exits. Saved registers get trashed, and it's just an unholy mess.

I've submitted a bug report to SCO, but the workaround at the source level is straightforward. We simply change the above constructions to:

char *dst = alloca(n); strcpy( dst, src );

This patch can be applied to the source to adjust this in three or four places. The patch has been submitted to the popt maintainers via comment posted at freshmeat.

Also - the shared library produced by the default configuration seem to be broken: code that depends on it won't even load properly. I spent some time trying to track this down but decided it wasn't worth the time. So I ended up just building and installing this library statically.

$ ./configure --disable-shared $ make $ make install

rsync-2.5.5

Building rsync was very troublesome due to the compiler bug identified in the popt-1.7 section. Rsync contains the popt source as a subdirectory, and it's used if there is no system-wide library for it. Though it's possible to patch the in-place popt with this patch, it's probably better to simply install the system-wide version instead.

diffutils-2.8.1

These are the GNU "diff" utilities, and the "configure" step fails with a "cannot create directory: ." error message. This arises because the mkdir -p path command returns failure status in the event that the directory to create is already there. The configure script is apparely expecting that failure status is only for true failures. Ugh.

Our fix for this was to build GNU fileutils-4.1 and install just the mkdir command to /usr/local/bin and insure that this was in the path before the system version at /usr/bin/mkdir.

postfix-2.0.10

We finally got tired of sendmail and replaced it with postfix. It didn't really do much meaningful local delivery, so it ended making things much cleaner. We ended up needing to install Berkeley DB as well, and these are the steps we took. Before building this, we ripped out as much of the sendmail environment as we could find.

Our environment:

# date
Sun May 25 21:40:15 PDT 2003

# uname -a
UnixWare hostname 5 7.1.2 i386 x86at Caldera UNIX_SVR5

# cc -V
UX:cc: INFO: Optimizing C Compilation System  (CCS) 4.0  06/09/01 (OU8.0.0bl7)

The postfix "hash" access method needs a DB package, and we're always of a mind to install the latest and greatest. This meant Berkeley DB 4.1. We fetched the software from Sleepycat Software and unpacked it to our build area.

# cd /source
# gtar -xzvf tarballs/db-4.1.25.tar.gz
# cd db-4.1.25/build_unix
# ../dist/configure
# make
# make install

This installs the software to /usr/local/BerkeleyDB.4.1/, but because this system doesn't seem to support the loader configuration file, it's too much work to insure that /usr/local/BerkeleyDB.4.1/lib is always in LD_LIBRARY_PATH. So, we make a symbolic link for the name loaded by the package to the real location:

# cd /usr/lib
# ln -s ../local/BerkeleyDB.4.1/lib/libdb-4.1.so.0.0.0 libdb-4.1.so.0

This puts the library required in the "usual" library path.

Then to Postfix, and it's a good idea to add the users required first:

# groupadd postfix
# groupadd postdrop
# useradd -g postfix -d /var/spool/postfix -s /bin/true -c 'Postfix' postfix

Then build the code. Because of the options involved, we typically create a small configuration file in the /source directory:

/source/configure-postfix


make makefiles DEBUG='' \
 CCARGS='-Kthread -I/usr/include -I/usr/ucbinclude -I/usr/local/BerkeleyDB.4.1/include -DHAS_DB' \
 AUXLIBS="-L/usr/local/BerkeleyDB.4.1/lib -ldb"

then configure and build Postfix:

# cd postfix-2.0.10
# sh ../configure-postfix
# make
# make install

The make install process will ask where the various parts of the system are to be installed, and I normally put everything under /usr/local/ - this is not the default location. Configure to taste, but in any case it will be necessary to create symbolic links so that the rest of the system knows how to inject mail into the system:

# ln -s ../local/bin/sendmail /usr/sbin/sendmail
# ln -s ../local/bin/sendmail /usr/lib/sendmail

Finally, we arrange for postfix to launch when the system boots:

# cd /etc
# cat init.d/postfix

#!/sbin/sh

PATH=/usr/local/bin:$PATH ; export PATH

case "$1" in
  start)
        echo "Starting postfix"
        postfix start
        ;;

  stop)
        echo "Stopping postfix"
        postfix stop
        ;;
esac

# ln -s ../init.d/postfix rc2.d/S99postfix
# ln -s ../init.d/postfix rc2.d/K01postfix

Navigate: More Tech Tips