OK, I'll start running them again tomorrow. Its just uncommenting a line in a shell script, no biggie.
FWIW, there had been numerous comments to the effect of "why do we even bother with this compiler?", and noone ever responded to my numerous threats to stop running the regression tests with SunPRO, so I just stopped them last week to save cycles. I didn't think they would be missed.
Fair enough. If only we could figure out why Boost.Test was failing (it looked like a legitimate compiler error), we could probably get the failure rate down quite a bit.
Who should I work with to get the appropriate tests marked as known-to-fail or N/A? This exercise is necessary for some gcc-on-Solaris tests as well. For instance, all of the "*_lib" tests in Boost.Thread fail because "gcc -static" won't link with *any* shared libs. Solaris does not provide static versions of -lrt or -lthread, so these tests fail to link. There really should really be a "-prefer-static" option to gcc.. Alternately, the Jamfiles could be hacked to use -Wl,-Bstatic / -Wl,-Bdynamic guards around the inclusion of the Boost.Thread lib for these tests.
That would probably be my preferred option, is it just a case of adding -Wl,-Bdynamic to the very end of the command line? Rene would probably know the best way to fix this. John.