Hi. For more than a month now, I have been trying to fulfill the Solaris Standards testing requirements for integrating a number of Solaris header files bug fixes into ON.
I have successfully built ON with my header file changes. With help with the C Compiler Team, we have ran the Perennial C99 conformance tests on a system with patched header files. The C99 Tests were successful. We also ran the C++2003 Conformance Tests, but, due to Studio C++'s non-conformance with the C++2003 standard, there are a lot of failures. However, the UNIX03 Standards Tests are a different story. The VSX test script located at: /net/ca64-v40zb.cz.oracle.com/export/stds/suites/bin/install_vsx.sh is broken. It fails with the following error: x4150-brm-04$ . $HOME/vsx_env x4150-brm-04$ Checking mount routines. /net/ca64-v40zb.cz.oracle.com/export/stds/suites/sun-config/vsx/bin/change_mount.sh Changing gen_mnt, vsu_mnt, and filldisc cp: cannot access gen_mnt.zfs Error: unable to copy gen_mnt.zfs to gen_mnt! change_mount returned an error. Failure during configuration of tests on x4150-brm-04.us.oracle.com. The script itself is looking for files which do not exist, in spite of the claims made on our internal VSX Testing web site: http://braindump.uk.oracle.com/wiki/index.php/VSX_Testing where it is clearly stated that ZFS testing is supported. I have checked the entire directory tree, and these *.zfs files simply do not exist: gen_mnt.zfs vsu_mnt.zfs filldisc.zfs In the case of Solaris 12, other than ZFS, i'm not sure what other kind of filesystem type i would be able to use. I have contacted the RPE Group in Prague, and forwarded them this error. I have not heard back from them. Martin Rehak (who usually runs the Standards Tests) was on vacation this past week, and, apparently, there is no-one else in the Prague RPE Group who can fill-in when Martin is on vacation. The test harness script is also riddled with many other errors, such as looking for the Studio compiler in a hard-coded location, and not in the location indicated during install_vsx.sh. The way it is configured right now, the VSX Test Harness is simply not usable. Running these tests appears to be a prerequisite for integrating the header file changes into ON. The header files changes are necessary for C99 and C++2011. Further changes will be necessary for C11. Given the very significant amount of time (more than a month) that i have spent trying - unsuccessfully - to run this UNIX03 test harness, and given the fact that there does not appear to be a great deal of interest anywhere in having these Solaris header files corrected, i feel that i have to ask the following two questions: 1. Is Solaris still interested in maintaining Standards compatibility, with correct and conforming header files? The fact that our header files *appear* to be correct now, does not make them correct. In fact, they aren't correct at all. 2. There appears to be a very clear distinction being made between the Studio compilers and "other" compilers, for example, GCC. Case in point: if GCC rejects a large number of our header files (which it currently does), that is not considered important, or relevant, because GCC is "not an Oracle Compiler". But, isn't GCC, in fact, an Oracle product, shipped and supported like any other Oracle Solaris component? Do we not care any longer if GCC on Solaris works or not? At this point i have to choose between three possible courses of action: 1. I can ignore the errors in our Solaris header files, and fix them internally, but only for GCC or Clang. I can do that with these compilers' respective .../include-fixed/ directories. This will satisfy the Standards conformance requirements for C++2011 and C99, but ONLY for GCC and Clang. The Studio compilers will be left out, because they do not read, or use, the GCC or Clang .../include-fixed/ directories. When the next version of the Studio C++ compiler is released, supporting C++2011, and using the GNU C++ Standard Library shipped with GCC, it will *NOT* be able to use it. My understanding is that the Studio C++ Compiler *is* planning on using the GNU C++ Standard Library shipped with GCC. However, if I cannot fix the errors in the Solaris header files, this will *NOT* be possible, because the corrections to the broken Solaris header files will be private to GCC or Clang. 2. Continue on the path of trying to run this VSX Test Harness. Given the current status of the VSX Test Harness, and based on my experience thus far, this goal has no ETA. It is holding up the integration of GCC 4.7.2. I do not know when this test harness will be fixed, so that it is usable, or by whom. If it wasn't for this unusable VSX Test Harness, I could send the GCC 4.7.2 pre-RTI code review tomorrow morning. 3. Ignore the errors in the Solaris header files, and integrate a broken GCC. Needless to say, option #1 sounds very tempting at this point. Thank you for your time. --Stefan -- Stefan Teleman Oracle USA Corporation [email protected] _______________________________________________ userland-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/userland-discuss
