Another issue I ran into was that I unable to get MySQL 4.0.17 or PostgreSQL (7.4.2 or 7.3.2) to run the sql-bench benchmarks successfully. MySQL would die with an apparent file descriptor issue, while PostgreSQL would die from a bus error.
But that was then, and this is now. With OpenBSD 3.5 out, I decided to take a look. I've also been able to resolve the issues with MySQL, and I've got a batch of benchmarks to share as well as some other goodies.
When I attempted to run my compiled version of MySQL 4.0.17, the tests would eventually fail with errors such as this:
Can't find file: './test/bench_60.frm' (errno: 9) at ./test-create line 137
It looked to others as well as myself that this was a file descriptor issue, but kicking up the file discriptors to as high as 32,000 with sysctl as suggested (and documented in my response to the OpenBSD/sparc mailing list) failed to provide a resolution. The sql-bench benchmarks just wouldn't run without MySQL dying.
Why Didn't You Use Ports/Packages!?!?!
Well, there are a couple of reasons why I didn't use ports/packages for MySQL. The first being that OpenBSD 3.4 does not have a SPARC64 MySQL 4.0.x package or port. There is a 3.x MySQL package and port for SPARC64, but since I've used MySQL 4.0.17 for my other evaluations, comparisons with 3.x wouldn't provide much insight. Also, 4.0 is the current release of MySQL and has many features that 3.x does not.
OpenBSD 3.5 has added a package (which I tested, read on) for MySQL 4.0.18, but of course that wasn't around when wrote my OpenBSD 3.4 review.
Packages and Ports versus Compiling From Source
Some are of the the opinion that compiling from source is bad, even making the assertion that the OpenBSD FAQ claims not to compile from source unless absolutely necessary (it says no such thing, only recommending that packages are easier). Regardless, I disagree that you shouldn't compile from source.
While there are cases where packages and ports are easier, I tend (with certain exceptions of course) to prefer compiling from source code whenever possible.
For one, that's what they're there for; to compile applications. Packages and ports are meant as a compliment to source compilation and as a convienence, and not a wholesale replacement.
Also, I deal with a number of operating systems on a regular basis, so compiling from source provides a consistency accross a variety of platforms which simplifies my efforts.
Compiling from source gives me a great deal of control over the application such as where it's installed, what optimizations I may want to use, what features and modules are compiled in, and so forth. While such control can be available in ports (although arguably more difficult to control than it is in source), it's not available in packages.
There are of course situations where using ports or packages is perhaps the best solutions. For instance, applications that can be very tedious and take an inordinate amount of time to compile. Take GNOME or KDE, for example. They both take a long time to compile (especially on a 333 MHz UltraSPARC IIi), are comprised of a multitude of smaller libraries and components, and on a non-standard operating system is bound to come up with quite a few errors.
For very simple applications, such as the bash or tcsh shell, I also tend to use packages.
Another way that packages and source may help is with non-x86 platforms. In my NetBSD 1.6.2 SPARC64 evaluation, I elaborated the trouble I had with OpenSSL compilations from source. The OpenSSL source distribution didn't have a compile environment defined for NetBSD 1.6.2 SPARC64. The NetBSD ports section did, however, so I was able to get OpenSSL up and running. I was also able to use the modifications used in ports to get the OpenSSL source distribution compiled and running.
Also, a package or port may not be available for the version of the software (or available period) I'm interested, especially with the more esoteric applications. NetBSD didn't have OpenSSL 0.9.7, only 0.9.6. OpenBSD 3.4 didn't have MySQL 4.0.x. in either packages or ports for SPARC64.
However, applications such as Apache, MySQL, PHP, PostgreSQL, Perl, OpenSSH compile in a reasonable amount of time and are relatively easy to install. They're also components that are often mission and security-critical, so they may need to be updated frequently, and sometimes more quickly than ports or packages can be released.
Sometimes neither package nor port nor compiling from source will provide a solution, such as with NetBSD 1.6.2. The ports MySQL 4.0 just couldn't successfully compile MySQL 4.0.18, and the NetBSD group did not maintain SPARC64 packages at the time; only SPARC packages. They've since added a SPARC64 packages directory, although still no MySQL 4.0.x package. Compiling from source was also fruitless, and to this day I have no MySQL benchmarks for NetBSD SPARC64, which is a shame.