Certification news; PolyServe install. whitepaper; GCC version

Dear SuSE-Oracle customers,

News items today:
1) New PolyServe Matrix Server - SLES-8 - Oracle 9iR2 installation PDF
2) Certification updates for SLES8 (Apps 11i, iAS 1022 & 9iv2, OCS)
3) About the certified GCC version (and Apps 11.5.8 installation)


PolyServe
---------

ftp://ftp.suse.com/pub/suse/i386/supplementary/commercial/Oracle/docs/9iR2-RAC_sles8_polyserve.pdf
http://www.suse.com/en/business/certifications/certified_software/oracle/docs/9iR2-RAC_sles8_polyserve.pdf

PolyServe Matrix Server is a high-availability product that includes a
sophisticated cluster filesystem that also has optimizations for
databases. PolyServe concentrates on high-end, high-load Oracle RAC setups.

A few weeks ago SuSE and PolyServe engineers got together to write a
joined whitepaper on installation of the PolyServe - SuSE - Oracle
solution stack. Our test system was a 10-node Oracle 9iR2 RAC cluster,
"How we tested" is described in there, too.

You can find the details in the above linked PDF document (ca. 300KB)


Certifications
--------------

http://www.suse.com/en/business/certifications/certified_software/oracle/certified.html

- Oracle 9iR2 for S/390 has been certified (SLES-8 for IBM z-Series)
- Oracle 9iR2 for IA64 (SLES-8 for IA64) is being certified - we expect
completion in July
- Oracle iAS 1022 and iAS 9iv2 are expected to be certified for SLES-8
in early July
- Oracle Collaboration Suite is expected to be certified with SLES-8 by
end of July


GCC version
-----------

We have mentioned it before, but to make the point one more time: The
default C/C++ compiler in UL-1.0/SLES-8 is GCC 3.2. The compiler used
for Oracle certification of ALL Oracle products prior to 10i is gcc
2.95.3, available (both gcc and g++) in package "gcc_old" on United
Linux CD #2.

Reasons:
- All Oracle products (before 10i) were made using gcc 2.95.3
- Gcc 2.95.3 and 3.2 are not compatible in the C++ part, and since
Oracle relinks object files and libraries made using 2.95.3 during
installation that can be a problem

In particular, to give (one more) example, Oracle Apps 11.5.8
installation fails when gcc 3.2 is installed but works fine when there's
no 3.2 but only "gcc_old" 2.95.3.

We recommend before any Oracle product installation the following steps:
    1) Install gcc_old, either with "rpm -Uvh gcc_old*.rpm" from UL CD #2
or using YaST2
    2) Remove gcc 3.2 (C and C++), either using yast2 or using the command
"rpm -e gcc gcc-c++ --nodeps" (which ignores dependencies - if you
installed any development packages like "kernel-source" they will have a
dependency on gcc 3.2 but of course the operating system itself doesn't
need it)
    3) Create symlinks in /usr/bin, since some Oracle makefiles and
scripts have a hardcoded PATH variable or call "/usr/bin/gcc" instead of
"gcc".
    ln -sf /opt/gcc295/bin/gcc /usr/bin/gcc
    ln -sf /opt/gcc295/bin/gcc /usr/bin/cc
    ln -sf /opt/gcc295/bin/g++ /usr/bin/g++
    ln -sf /opt/gcc295/bin/g++ /usr/bin/c++

This is needed during installation and each time you relink an Oracle
component (e.g. Oracle patchset installation).

Please note that you must use gcc 3.2, NOT 2.95.3, to recompile any SuSE
Linux/United Linux component (e.g. the kernel)! Gcc 2.95.3 is for Oracle
*only*. This is important e.g. if you don't want to recompile the kernel
(please don't) but want to install a new hardware driver (or a newer
version of it) - this is something that *may* be allowed and you still
have a certified and supported system, but you should check with SuSE
support first!



Background and future:
- Oracle product release cycles have always been slower than Linux
release cycles.
- Oracle products are relinked, but not recompiled during installation.
- Therefore Oracle products have always had the problem that after a
while they are installed in a glibc/gcc environment they were not made
in. If Oracle were to deliver source code or binaries there would be
much less issues, the problem is the mix of object code.
- There were issue with Oracle products when Linux switched from glibc
2.0 to 2.1, and later from 2.1 to 2.2. Initially those issues were
addressed by installing the old glibc in a compatibility environment and
linking and running Oracle in it - ending up with TWO glibc versions on
the same system at the same time. This was solved with a glibc stubs
patch (first for Oracle 8.1.7) that is used only during the relinking
and is now included in most Oracle products.
- With the switch from gcc 2.95 to 3.2 Oracle has a similar issue now in
the compiler area.
- These problems will always be there as long as Oracle is relinked
during installation and as long as there is a major glibc/compiler
upgrade in Linux during the Oracle product lifetime.
- Those problems can be solved. They are and have been addressed by
Oracle and SuSE. The first step was the glibc stubs patch which hides
the glibc problem completely now, which Oracle made after a SuSE glibc
developer (Andreas Schwab) told them about this option. The next problem
is the compiler, and that would not be much of a problem if there
weren't Oracle scripts and makefiles using hardcoded paths to
/usr/bin/gcc - if they would rely on the PATH set in the environment
both the old compiler (for Oracle, now "gcc_old", 2.95.3) and the new
one can coexist on the same system by adding the path to the old one
first in PATH when running/installing Oracle. This is what the orarun
package does in /etc/profile.d/oracle.sh, if gcc_old is installed it
sets the PATH to point there first - for user "oracle" only though.
Oracle has agreed to check 10i to not use any hardcoded paths... until
then, it is necessary to remove gcc 3.2 from the Oracle system in the
way described above.


Best regards,
Michael Hasenstein
SuSE Inc.
Oakland, CA (US)