3 Replies Latest reply on Nov 21, 2007 11:45 PM by 569362

    OCCI Linking Error (undefined reference to `__intel_personality_routine')

    535014
      Machine: Itanium 2 (ia64)
      OS: Red Hat Enterprise Linux AS release 3 (Taroon Update 5)
      Oracle: Oracle 10g R2 (10.2.0.1.0) for Linux Itanium
      Compiler: gcc-3.2.3-52

      Problem:

      when I compile my application i get the following errors:

      /oracle/oracle/product/10.2.0/db_1/lib/libocci.so: undefined reference to `__intel_personality_routine'
        • 1. Re: OCCI Linking Error (undefined reference to `__intel_personality_routine')
          prajithparan
          One of the native I64 library is missing in your makefile.
          Please refer the makefiles in the demo directory of the Oracle server.
          • 2. Re: OCCI Linking Error (undefined reference to `__intel_personality_routine
            569362
            Hello prajithparan ,

            If no one of the already suggested approaches, including the one of linking against an earlier version of libtsdc++ (version 5 if I remember correctly doesn't work) try the below one:

            The unresolved symbol '__intel_personality_routine' seems to come from one of libcxa.so.* which seem to be one of the intel runtime libraries which are linked when you use Intel compilers. There are two such libraries in (I guess ORACLE shipped them...):

            $ORACLE_HOME/lib/libcxa.so.3
            $ORACLE_HOME/lib/libcxa.so.5 (64 bits I guess)

            In my opinion it seems that LIBOCCI.SO was generated using this library on the linking line which is a bit strange... However there could be some fixes of that:

            1. Hard way: To unpack the ORACLE DB installation kit on HDD and figue out and eventually change around some of the MAKEFILES which are used to generate libocci.a (as the shared version of it libocci.so.* is generated based on the static library libocci.a).

            2.To link your application against the correct libcxa.so.* (either one from ORACLE_HOME as above or maybe one from INTEL compiler framework IFC ...which should be downloaded somehow...I guess)
            3.The easiest but sometimes unsafer workaround is:

            --go to ORACLE libs:

            cd $ORACLE_HOME/lib

            --make safe copy of original OCCI lib:

            cp -fp /oracle/app/product/10.2.0/lib/libocci.so.10.1 /oracle/app/product/10.2.0/lib/libocci.so.10.1.orig

            --create a fake small a.c file with the following contetent:

            void __intel_personality_routine(){
            return;
            }

            compile it for your desired version: gcc -m64 -fPIC -c a.c (use your platform specific flags)

            --change genoccish from $ORACLE_HOME/bin adding a.o to linking line of OCCI shared library

            # Linker command and options

            LD="${GCC} -Wl,-soname=${OCCI_LIB} ${LDFLAGS_ARCH} -o ${LIB_DIR}/${OCCI_LIB} -shared \

            -Wl,--whole-archive ${LIB_DIR}/${OCCI_ARC} a.o -Wl,--no-whole-archive"

            -- run genoccish to generate the new shared library and check the new one by: nm -AL $ORACLE_HOME/lib/libocci.s0.1 | grep “__intel_personality_routine”

            TRY AGAIN and please let me know if one of the above worked...

            Regards,
            Ioan
            • 3. Re: OCCI Linking Error (undefined reference to `__intel_personality_routine
              569362
              Hello Mr. Romeo,

              Unfortunately this week I don't have access to the build and development platform IA64 RHEL 4.5 so I can offer you just some approximate hints related to your last question (my current working platform is Solaris 10 x86-64 but there are similarities):

              0. Unpack your shipped ORACLE database package using:

              gunzip <oracle version>database<OS platform>_<OS architecture>.cpio.gz
              cpio -ivd < <oracle version>database<OS platform>_<OS architecture>.cpio

              1.In order to see what are the components including OCCI please run one of the belows:

              find database/ -name '*' -type f -exec grep -i 'libocci' {} \; 1>occi.lst 2>/dev/null

              or better

              for f in `find database/ -name '*.jar' -type f -print`; do unzip -l $f | grep occi; if [ $? -eq 0 ]; then printf "COMPONENT ------------------ %s\n" $f; fi; done

              basically you should get the following list of components:

              database/stage/Components/oracle.rdbms.rsf.ic/10.2.0.1.0/1/DataFiles/filegroup2.jar
              database/stage/Components/oracle.rdbms.oci/10.2.0.1.0/1/DataFiles/filegroup3.jar
              database/stage/Components/oracle.rdbms.oci/10.2.0.1.0/1/DataFiles/filegroup2.jar
              database/stage/Components/oracle.rdbms.oci/10.2.0.1.0/1/DataFiles/filegroup1.jar
              database/stage/Components/oracle.rsf.hybrid/10.2.0.0.0/1/DataFiles/filegroup3.jar

              As you can see there three distinct components including references to troublesome OCCI component.

              The first (oracle.rdbms.rsf.ic) one usually includes the shared library 'lib/libocci.so.10.1' which was built under the mixed RFC.IC environment: please check it by:

              -- create temporary directory AAA:

              mkdir -p AAA

              -- extract the component you need out of archive:

              unzip database/stage/Components/oracle.rdbms.rsf.ic/10.2.0.1.0/1/DataFiles/filegroup2.jar lib/libocci.so.10.1 -d AAA/

              -- check it by:

              file AAA/lib/libocci.so.10.1 (to get the binary file profile info)

              nm -Al AAA/lib/libocci.so.10.1 | grep __intel_personality_routine (searching out for undefined symbol...please refer man page of nm for further info)

              objdump -h AAA/lib/libocci.so.10.1 (to collect ELF-EFI profile info ...first two are important -h and -f ...)

              objdump -f AAA/lib/libocci.so.10.1

              objdump -x AAA/lib/libocci.so.10.1

              Here try to pick up some conclusions and eventually send me the outputs if don't manage figure out the outputs you get.

              The next three entries are coming from the component oracle.rdbms.oci (our bad guy...) and should contain something like:

              2733 09-13-05 13:23 bin/genoccish

              %ORACLE_HOME%/bin/genoccish

              COMPONENT ------------------ database/stage/Components/oracle.rdbms.oci/10.2.0.1.0/1/DataFiles/filegroup3.jar
              2425378 10-19-05 16:55 lib/libocci10.a
              %ORACLE_HOME%/lib/libocci10.a
              1259357 10-04-05 16:27 lib/libocci10_296.so.10.1
              %ORACLE_HOME%/lib/libocci10_296.so.10.1
              1752124 10-04-05 16:27 lib/libocci10_296.a
              %ORACLE_HOME%/lib/libocci10_296.a

              COMPONENT ------------------ database/stage/Components/oracle.rdbms.oci/10.2.0.1.0/1/DataFiles/filegroup2.jar

              2115 10-15-02 02:19 rdbms/public/occi.h
              %ORACLE_HOME%/rdbms/public/occi.h
              11600 03-03-04 03:59 rdbms/public/occiAQ.h
              %ORACLE_HOME%/rdbms/public/occiAQ.h
              38530 06-23-05 07:55 rdbms/public/occiCommon.h
              %ORACLE_HOME%/rdbms/public/occiCommon.h
              73063 01-10-05 20:08 rdbms/public/occiControl.h
              %ORACLE_HOME%/rdbms/public/occiControl.h
              35218 11-08-04 21:36 rdbms/public/occiData.h
              %ORACLE_HOME%/rdbms/public/occiData.h
              29156 11-13-03 20:59 rdbms/public/occiObjects.h
              %ORACLE_HOME%/rdbms/public/occiObjects.h

              COMPONENT ------------------ database/stage/Components/oracle.rdbms.oci/10.2.0.1.0/1/DataFiles/filegroup1.jar

              The last one just include related header files and have no relevance in our issue, so lets have a look over the first two:

              bin/genoccish – is the well known generation script (you already dealt with it)

              lib/libocci10.a – is the static library which isn't built from *.o files being already shipped :-(

              lib/libocci10_296.a – are for gcc296 and should be used only for GCC296...

              So our static library (archive) lib/libocci10.a should be also checked by:

              nm -Al AAA/lib/libocci10.a | grep __intel_personality_routine (searching out for undefined symbol...please refer man page of nm for further info)

              Most probable the symbol is there and is undefined...:-( So for the time being our work-around seems to be the only way we have !!!

              The last component is for hybrid platforms only (it could be missing from your IA64...I am not sure is IA64 is still treated as an hybrid platform...:-) ) and contains the 32 bit versions...you can check them as in the previous cases from above but assuming that these 32 bit versions are clean (not referring any uresoved symbols...:-)) this is restricting you to build your applications for 32 bit only...

              1764366 09-08-05 03:43 lib32//libocci10.a
              %ORACLE_HOME%/lib32//libocci10.a
              1397960 10-20-05 02:54 lib32//libocci.so.10.1
              %ORACLE_HOME%/lib32//libocci.so.10.1

              COMPONENT ------------------ database/stage/Components/oracle.rsf.hybrid/10.2.0.0.0/1/DataFiles/filegroup3.jar

              All the best and let me know if you need more support with that,
              Ioan