Gentle MySQL Maintainers,
The purpose of this note is to inform you that Stratus
Technologies has successfully ported MySQL Community Server,
Release 5.0.75, to its Stratus OpenVOS Operating System, Release
In accordance with the terms of the GNU General Public License,
Version 2, we hereby provide you with the changes that we made
to this version of MySQL to get it to build, execute, and pass
its tests on OpenVOS 17.0.1aq.
The Stratus OpenVOS (formerly "VOS") operating system has its
own implementation of the POSIX standard. We use GCC/G++ and
much of the higher-level GNU software but the actual POSIX
headers and functions were written by Stratus software engineers
or ported from FreeBSD. This porting effort found a few latent
defects in our own code, which have been corrected in the
version of OpenVOS mentioned above.
OpenVOS is a proprietary, fault-tolerant, 32-bit operating
system that runs on Intel Xeon(tm) processors. OpenVOS data is
stored in Big-Endian format, and this is implemented by the
compilers. Our binaries have a mandatory executable suffix.
Our file system enforces more restrictive object naming rules
that Unix or Linux.
We encountered just a few compatibility issues with the MySQL
code while porting it to OpenVOS. Listed roughly in descending
order of importance, they are:
1. Assumption that all Intel processors are Little-Endian.
OpenVOS is Big-Endian. I can recall only one such place.
2. Assumption that filenames and directory names can be of any
length and can contain nearly any byte value. OpenVOS file
names can be long (up to 255 bytes) and can be composed of
most ASCII printing characters but our directory names are
limited to 32 characters and are restricted to a smaller set
of ASCII printing characters. We shortened some names and
changed other names to work within the limits of our system.
3. Various 32-bit vs. 64-bit coding issues led to compile-time
warnings or execution-time warnings. We changed the MySQL
code to eliminate the warnings.
4. Dependence on some POSIX features that OpenVOS did not
implement. In some cases we added the necessary support,
and in other cases we changed the MySQL code.
5. Inconsistent treatment of an executable suffix. We
corrected all of the issues that we found.
6. Inability to build and test the MySQL source code in any
location other than the source code hierarchy. We corrected
all of the issues that we encountered.
7. Use of non-POSIX-compliant time zone strings. We changed
the time-zone strings to comply with the POSIX standard.
8. We neutered the Makefile rules that rebuilt configure,
Makefile.in and similar "source" files. This allowed us to
edit these "source" files.
9. Mangling pathnames that happen to contain "printf" control
sequences (percent characters). This character has special
meaning in OpenVOS pathnames and is frequently present.
These errors were exceptionally hard to track down, but we
found them and fixed them.
10. Use of the number-sign character (#) in temporary file
names. This character also has special meaning and is
frequently present in OpenVOS pathnames. It is unavailable
for use in filenames. We tracked these down and changed
11. Miscellaneous implementation differences from Linux and Unix
systems. Generally, we changed the MySQL source code to
work around these issues. In some cases, we both changed
the MySQL source code and changed OpenVOS -- for example, we
changed the MySQL test cases to avoid years in the range
1970 to 1980 but then we eventually changed OpenVOS to
handle these years.
This was a fairly large effort, involving several engineers over
about a 6-month period of time. Most of the changes that we
made to your source code were, I hope, preserved the style and
platform-independence of the MySQL source code. A few changes
that we made were made "in the heat of the moment" and would not
pass the platform-independence test. For example, we changed a
number of the test scripts to get them to execute on OpenVOS.
These changes are relevant only to OpenVOS and, I trust, are
uninteresting to any other platform.
As this was a large effort and covered many different issues,
and since many of the issues were due to variations in the
OpenVOS implementation from de-facto industry standards, I don't
feel it is appropriate to request that the bulk of these changes
be applied to the source code base. Instead, I will simply
single out a few key changes that I think you might find useful.
I will be happy to work with you to extract diffs for just these
changes if you wish to pursue them. I welcome a dialogue; it is
hard for me to know which changes you might find useful.
1. Recognizing the OpenVOS platform.
2. Separating the build tree from the source tree.
3. Correcting 32-bit vs. 64-bit issues.
4. Not mangling pathnames that contain % characters.
5. Support for a big-endian Intel implementation.
6. Consistent treatment of executable suffixes.
Unified Differences Files
Please fetch the following text files to view the changes that
we made. Here is a brief explanation of each file. The files
are located in the following directory. I will leave them here
-- This file.
-- Every change we made to the files in
-- Every Makefile* change we made. Most of these changes
simply neutered the rules that rebuilt Makefile.in from
-- Every non-Makefile* change we made. This file, together
with the mysql.vos.makefile.patch.txt file, contains all
of the patches found in the mysql.vos.all.patch.txt
-- A listing of the files we changed and the reasons why we
changed each one, where I could remember.
That this effort was even possible, much less successful, is a
tribute to the dedication to portability that is evident in the
MySQL source code base. Thank you for the work you have done to
make the code portable and thank you for offering this code
under the GNU General Public License.
I reported on my previous porting attempt at:
If you have any questions, please feel free to contact me.
Paul Green, Senior Technical Consultant, Stratus Technologies.
Voice: +1 978-461-7557; FAX: +1 978-461-3610; Mobile: +1 (978) 235-2451;