Is there any way to force Studio to use the compat-gcc-34-c++ stdc++ versions instead of (the likely default) libstdc++-devel-4.x directories?
I have been successfully using the latest Studio version, 12.3, with OCCI with both Solaris and Linux (with -compat=g flag for Linux) I have found no issues with a Centos 5.8 (64bit) development box or Solaris, but when I try to build the same source on a newer Centos 6.3 box (64bti), I get several unresolved linker errors that look something like this:
director.cpp:(.rodata+0xa0): undefined reference to __gthrw_pthread_cancel
I traced this down to some weak references introduced in gcc 4, specifically in this directory:
There, several headers define macros that create references by pasting tokens (don't know yet which one I am including though)
# define __gthrw_(name) __gthrw_ ## name
The only workaround I've found is to move the 4.x directories out of the way: then, Studio finds and uses the compat-gcc-34-c++ versions and life is good again.
I should add that a simple program that doesn't use OCCI builds fine, so i don't have a simple example that illustrates this problem...
First, I hope you realize that Centos is not a supported OS. Only Solaris, OEL, and RHEL are supported.
The compiler uses some heuristics to find the default installed version of gcc. There is currently no option to tell it to look in a specific place, or to pick one of multiple installed versions. In addition, we test only with the default versions of gcc on the supported platforms, so a different gcc version might not work well. (Considerable work is usually needed to get Studio to work with new Linux versions and new gcc versions.)
You can usually force a specific version of gcc by adding -I and -L options. The compiler will look in those directories before looking in the default directories. You would also need to set the runpath for shared libraries and executables to pick up the right gcc libraries.
Moving (renaming) the top-level gcc directories you want to avoid will work if the one you want is in a usual place.
Both of these workarounds are hacks to some degree, and might not be sustainable.
The moving/renaming of directories was just part of the investigative process and not intended as a reasonable workaround.
The forced includes and library search directories is enough of a workaround.
RHEL6.3 ships the same version, 4.6.6, but we use CentOS 6.3 instead, since it tracks RHEL well enough.