[Python-3000] Solaris support in 3.0? (original) (raw)

Nicholas Bastin nick.bastin at gmail.com
Wed Sep 5 19:54:57 CEST 2007

On 9/5/07, Guido van Rossum <guido at python.org> wrote:

On 9/5/07, "Martin v. Löwis" <martin at v.loewis.de> wrote: > > This is a combination question-and-status-report email. The question > > would be, what does the "somewhat" tag mean on Solaris support in the > > release notes for 3.0a1, and does someone have a list of things that > > don't work, or does that just mean it hasn't been tested? > > Not sure what "somewhat" means, but you can take a look at the build > failures in the Solaris buildbot - this is what is "officially" known > not to work.

The "somewhat" was my word -- I meant that when I last looked at the Solaris buildbot, I saw a few failures; and also that I don't have access to Sun hardware. And also what Martin says below. I'd be happy though to replace "somewhat" with specific indications of h/w and s/w versions if you are willing to commit to supporting these throughout the 3.0 life cycle.

I have access to Solaris 8 and 9 on Sparc, and Solaris 10 on x86. My Solaris 10 x86 installation is currently in a VM, and it's unpleasant to work with (performance is terrible for some reason), but I can at least make a passing attempt to build and run unit tests in that environment. I have to have Python on Sparc for my application, so I'm going to continue to work on Python 3.0 on Solaris 8/9 for Sparc throughout the entire cycle to make sure that we have a usable product there.

> As always with Solaris, there are several dimensions to be considered: > - version (2.5,2.6,7,8,9,10,11); not sure what the oldest Solaris > version is that we still want to support. > - compiler: gcc vs. SunPRO/Forte > - 32 vs. 64 bits > - SPARC vs. x86

I will at least build and test the following configurations. I will also attempt to fix any platform specific bugs, but I suspect the Unicode failures are going to create some interesting discussions around here. :-)

Solaris 8, 32-bit, 64-bit, Sparc, gcc and SunPro 11 Solaris 9, 32-bit, 64-bit, Sparc, gcc and SunPro 11

I will try to get to:

Solaris 10, 32-bit, x86, gcc

Because there's no reason not to since I have an x86 machine and VMWare. :-)

> > If anyone wants more data on any of these particular failures, let me > > know, otherwise I'm going to start working through the ones that fail > > in 3.0 that don't fail in 2.6. All of the md5 failures are because > > of the lack of SSL, so I'm not sure that the tests should be 'failing' > > in this configuration. > > I think that's a serious issue to consider. As so much code now depends > on OpenSSL, setup.py should try harder to find it. E.g. on the build > slave, it can be found in /usr/sfw - not sure whether that is normal > on a Solaris 10 installation, and not sure whether there is a > Sun-provided OpenSSL on Solaris 8. > > Notice that the tests don't 'fail', they are skipped. There are also > failing test cases, something that is more worrisome than a skipped > test case.

Yes, this is a serious issue -- we are totally dependent on openssl for computing MD5 checksums. Several modules use MD5 checksums casually, and it's not good that these fail when openssl isn't available (or if it's too old, like what happened on an ancient Red Hat 7.3 system I have at home). I'm tempted to put the old RSA-copyrighted md5.c back in as a fallback, even though its license is impopular. Or perhaps we could make a copy of a small fraction of openssl and use that? I think MD5 is the only one that's popular enough to warrant this treatment; I think SHA1 is a distant second.

MD5 is defined in RFC 1321, there's no reason to have to use any particular code with a bad license - there's plenty of LGPL MD5 implementations out there (although you could probably argue that if they'd ever looked at 1321, which they almost certainly did, then they've been tainted by the RSA code).

Also, the NIST SHA-1/256/384/512 code is freely available, there's also no reason to rely on OpenSSL for it (although it looks like the PKI reference implementation links that I can find are dead, so we might have to hunt a little bit).

In either case, we could probably copy the relevant pieces out of OpenSSL.

-- Nick

More information about the Python-3000 mailing list