Strange Linker error using Forte 6

Question

Hi,
I am getting an unusual linker error while trying to compile something using Forte 6 update 2. First some backgrond
We have an internal application currently running on a Solaris 2.6 box. I wish to move it to a Solaris 8 box. The application uses mainly apache, perl and mysql. One of the perl modules used is the old SPGrove module written by James Clark (www.jclark.com), which in turn uses the libsp.a library from the 'sp' distribution by the same author. I can find information on compiling/running 'sp' on O/S versions upto solaris 7 but not 8. Having tried all the available versions of gcc I finally gave up and tried Forte 6.
Having had problems with applications and dynamic libraries complied with different compilers before I have compiled perl 5.6.1 using Forte 6, I have installed all the required perl modules and I have successfully compiled version 1.3.4 of the 'sp' package.
The old SGML::SPGrove modules is no longer available and has been replaced by two newer ones, SGML::Grove, which installs fine, and SGML::SPGroveBuilder, which has some C++ code which is linked against the libsp.a library as mentioned above. The module (once certain options have been set to get the correct environment) compiles fine but when I run the test suit I get the following error.
Can't load 'blib/arch/auto/SGML/SPGroveBuilder/SPGroveBuilder.so' for module SGML::SPGroveBuilder: ld.so.1: /usr/local/bin/perl: fatal: relocation error: file blib/arch/auto/SGML/SPGroveBuilder/SPGroveBuilder.so: symbol __1cG__CrunLvector_copy6Fpv1IIpF11_vpF1_v_v_: referenced symbol not found at /usr/local/lib/perl5/5.6.1/sun4-solaris/DynaLoader.pm line 206.
The symbol '__1cG__CrunLvector_copy6Fpv1IIpF11_vpF1_v_v_' is contained in libCrun.so in the Forte installation. I have no idea what it is, or why I get the error.
Sorry to be so long winded, but I wanted to give enough information so that I didnt get 'too many' easy to answer questions about the environment.
'uname -snrvmapiX' for the system is:
SunOS atlas 5.8 Generic_108528-13 sun4u sparc SUNW,Ultra-60System = SunOS
Node = atlas
Release = 5.8
KernelID = Generic_108528-13
Machine = sun4u
BusType = <unknown>
Serial = <unknown>
Users = <unknown>
OEM# = 0
Origin# = 1
NumCPU = 1
Many thanks.
Sean Timmins
Systems Administrator

Answer 1

Just to clarify, the I get the error during the 'make test' part of the normal perl module build process for installing the SGML::SPGroveBuilder module (perl Makefile.PL; make; make test; make install).
Perl and SGML::SPGroveBuilder are both complied using Forte 6 update 2. The only difference being that perl (being normal C code) was compiled using the C compiler '/usr/local/SUNWspro/bin/cc' and the module requires the C++ complile '/usr/local/SUNWspro/bin/CC'.
I have to make minor modifications to Makefile.PL before it will compile at all. These modifications are:
1) Forcing the C++ compiler as perl will try to use exactly the same binary as was used to compile itself.
2) Setting a few #define's so that the same ones are used to build the module as were used to build the sp library that is linked in with the module.
3) Adding the various directories where both libsp.a (yes statically linked, no dynamic one in the sp distribution) and the required header files (all in the sp distribution) are located.
I have since tried recompiling perl (with Forte 6 update 2) with no dynamicaly loaded libraries and get the same error. I have also found a tiny little patch to OpenSPv1.5pre5 (which is the replacement for the original sp distribution) which allowed me to compile eveything with gcc 3.1, perl, opensp (v1.5pre5) and SGML::SPGroveBuilder, and I get a very similar error at the same stage but a different symbol name.
I am begining to think that its gone to far and there are too many branching oppertunities where I have made a mistake (I've really tried way way way too many combinations now), or that the SPGroveBuilder module simply has a probelm with the C++ code in it. It has not been updated in some time.
I am going to try removing everything from the box and start from scratch, patch it to the hilt and try it from the beginning.
Of course, any flashes of brilliance that come to mind would still be greatly appreciated :-)
Sean Timmins
Systems Administrator