I am often asked whether a particular open-source package can be ported to some release of VOS or OpenVOS (“VOS”, for short). My general answer is that most open-source packages that perform only user-mode operations can be ported to VOS. Because Stratus customers are using many different releases of VOS, and because with each new release of VOS we have added new capabilities to the POSIX environment, it is hard to give a more specific answer without actually trying to port the package in question.

I estimate that I have ported over a million lines of source code to VOS. I think I have encountered most of the issues that anyone is likely to face when porting software to VOS. The first rule of thumb is that you should use the latest release of VOS that your organization has installed. If your release is several years old, which is not an uncommon age among our customers, then there is almost certainly a newer release that you can install. Even if you are still using our older, Continuum systems, we have continued to improve the POSIX libraries in the maintenance releases of VOS 14.7, and it is still worth upgrading to get these additions and corrections. If you have a newer, V Series module, then you should use OpenVOS 17.0.1, which has the most complete POSIX support of any release.

As I discussed in the “Porting Open-Source Code to VOS” (see my previous blog post)¬†presentation even when VOS is missing some POSIX header or function, it is generally not hard to either work around the absence by modifying the original source code, or by porting the missing code from another open-source operating system.

I think you will find that the “openvos.save.evf.gz” and “posix.save.evf.gz” packages on the VOS anonymous FTP site will simplify the task of porting open-source software to VOS. I also hope you will read the just-reference presentation because it contains many helpful suggestions.

My experience is that many open-source packages will port to OpenVOS Release 17.0.1 without any changes. Even when changes are needed, they are usually fairly minor. The one remaining problem area is dynamic linking, which current releases of VOS do not support. Some packages require dynamic linking only for running the test cases (e.g., the Sleepycat Berkeley DBMS), and some require it to build at all (e.g., the current release of MIT Kerberos). You may be able to use an Internet Search Engine to find an older copy of the package that still supports static linking. You can then bring that support forward to the current version. Stratus is presently implementing dynamic linking for a future release of OpenVOS.

You always have the option of hiring Stratus Professional Services experts to perform the port and related testing, and turn the results over to you. We have ported gSOAP, Xerces, and other packages for our customers, and of course we have ported everything from GCC to MySQL for our library of software products.