I stopped running them last Monday (3/14). The general consensus seemed to be that the number of failures was so high that running the tests was a waste of time. This is with SunPRO 5.3, which is the only version I have access to.

Pity, I did used to check those results for Regex and Type Traits compatibility, one of the main annoyances was dependent libs like Boost.Test and Program Options not compiling, which caused some tests to fail unnecessarily; other than that many libs should really be supported on that platform. John.

On Mon, 21 Mar 2005 10:00:45 -0600, Aleksey Gurtovoy <agurtovoy@meta-comm.com> wrote:

John Maddock writes:

...

...

I stopped running them last Monday (3/14). The general consensus seemed to be that the number of failures was so high that running the tests was a waste of time. This is with SunPRO 5.3, which is the only version I have access to.

Pity, I did used to check those results for Regex and Type Traits compatibility, one of the main annoyances was dependent libs like Boost.Test and Program Options not compiling, which caused some tests to fail unnecessarily; other than that many libs should really be supported on that platform.

And the rest can be marked as "n/a", thus getting us a useable picture for tracking new failures / regressions.

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. 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. -- Caleb Epstein caleb dot epstein at gmail dot com

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.

One of the recent versions of Boost.Test should've compile with Sunpro 5.3. I will make sure release version pass this compiler either. Where could I see an errors? Gennadiy

I really wish I could run the tests with "bjam -j#". They are running on a single CPU of a 24-way box so they take ages. Turning on parallelism confuses the output processing to the point of making the results unusable however :(

I'm not sure if this would work, but how about: Do a clean build using the -j option (but discard the results). Then do an incremental test build (not parallel) and collect the results for processing. Not sure how well this would work though as we still have problems with incremental builds? John.

Caleb Epstein wrote:

OK, the SunPRO results are back now.

Thanks!

I will make sure release version pass this compiler either. Where could I see an errors?

Ok. Current cvs head should pass library compilation on this ^%$^% compiler. Gennadiy

On Tue, 22 Mar 2005 13:02:38 -0000, John Maddock <john@johnmaddock.co.uk> wrote:

...

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.

In my testing, I have found that you can't use "gcc -static" on Solaris if you have *any* shared libs to link with. It overrides even later uses of -Wl,-Bdynamic (in fact using both -static and -Wl,-Bdynamic causes a linker error - see below). If you want to link with static versions of some libs and dynamic versions of others (as one must in the case of the Boost.Thread tests which use -lpthread and -lrt for which no static versions exist), it appears that the only way to do this is to specify the static libs as fully qualified filenames (e.g. /path/to/libfoo.a). See the examples below: static.c: --- #include <curses.h> int main () { initscr (); endwin (); return 0; } --- Link statically with -lcurses (OK) % gcc -static -o static static.c -lcurses Try to link statically with -lcurses and -lrt (fails - no librt.a exists) % gcc -static -o static static.c -lcurses -lrt ld: fatal: library -lrt: not found ld: fatal: File processing errors. No output written to static collect2: ld returned 1 exit status Try to link statically with -lcurses and dynamically with -lrt (fails - linker error) % gcc -static -o static static.c -lcurses -Wl,-Bdynamic -lrt ld: fatal: option -dn and -Bdynamic are incompatible ld: fatal: library -lrt: not found ld: fatal: File processing errors. No output written to static collect2: ld returned 1 exit status Try to link statically with -lcurses only (OK): % gcc -o static static.c -Wl,-Bstatic -lcurses -Wl,-Bdynamic -lrt % ldd static librt.so.1 => /usr/lib/librt.so.1 libc.so.1 => /usr/lib/libc.so.1 libaio.so.1 => /usr/lib/libaio.so.1 libdl.so.1 => /usr/lib/libdl.so.1 /usr/platform/SUNW,Netra-T12/lib/libc_psr.so.1 Also, note that -Wl,-Bdynamic must be in effect at the end of the command line because gcc does not provide a static version of -lgcc_s. Not sure why this happens, though, because -static works for this case: hello.cpp: #include <iostream> int main () { std::cout << "Hello World!\n"; return 0; } % g++ -o hello hello.cpp -Wl,-Bstatic ld: fatal: library -lgcc_s: not found ld: fatal: library -lgcc_s: not found ld: fatal: File processing errors. No output written to hello collect2: ld returned 1 exit status % g++ -o hello hello.cpp -Wl,-Bstatic -Wl,-Bdynamic % ./hello Hello World! % g++ -static -o hello hello.cpp % ./hello Hello World! Not sure what the difference is between the -Wl,-Bstatic and -static cases is here. -- Caleb Epstein caleb dot epstein at gmail dot com

Hi, On Mar 22, 2005, at 6:11 PM, Caleb Epstein wrote:

On Tue, 22 Mar 2005 13:02:38 -0000, John Maddock <john@johnmaddock.co.uk> wrote:

...

...

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.

In my testing, I have found that you can't use "gcc -static" on Solaris if you have *any* shared libs to link with. It overrides even later uses of -Wl,-Bdynamic (in fact using both -static and -Wl,-Bdynamic causes a linker error - see below).

This might also be even more confusing on Solaris 10 - see this blog entry: http://tinyurl.com/5sqxc for details. [snip rest of message] Michael