This site uses advanced css techniques
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.
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.
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
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.
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 apparently 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.
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.
# 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:
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
On an old SCO Open Server 3.2v5.0.5 system with GCC 2.7.2, we needed to build OpenSSL to then build a modern OpenSSL. The machine was very old and slow, and it took upwards of an hour to configure, build, and test everything — we needed several runs to get it right.
We initially tried ./config to auto-select the environment, but didn't find how to pass a number of config options downstream, so ultimately just ran ./Configure directly.
exec ./Configure sco5-gcc \ no-asm \ no-dso \ no-threads \ no-hw