I’ve been working on a proof of concept migration of on HP-UX v11.11 PA-RISC to R12.1.2 on HP-UX v11.31 Itanium for past couple of weeks. This is not a complete reference on how to make that happen, but still, there are some gotchas I had to workaround in cross-platform migration phase. Here is the list of issues and solutions to the problems spotted during application of the customer-specific update patch (provided by uploading manifest file created with perl adgenpsf.pl to http://updates.oracle.com/PlatformMigrating )

  1. Patch fails with errors ar: lib<module>.a not in archive format

    Extracting object modules for product ad...
    ar: /u01/ar121/TR12/apps/apps_st/appl/ad/12.0.0/lib/libad.a not in archive format
    adlibout: error: cannot get table of contents in library file for product ad
    File name is /u01/ar121/TR12/apps/apps_st/appl/ad/12.0.0/lib/libad.a
    Skipping to next product...

    those files are present, but when you check the type of file, it’s clear it’s in PA-RISC format, which is not OK for HP-UX Itanium

    file /u01/ar121/TR12/apps/apps_st/appl/ad/12.0.0/lib/libad.a
      /u01/ar121/TR12/apps/apps_st/appl/ad/12.0.0/lib/libad.a:    archive file -PA-RISC2.0 relocatable library

    The solution is simple, just rename those files and they will get recreated:

    mv /u01/ar121/TR12/apps/apps_st/appl/ad/12.0.0/lib/libad.a /u01/ar121/TR12/apps/apps_st/appl/ad/12.0.0/lib/libad.a.BCK
    mv /u01/ar121/TR12/apps/apps_st/appl/alr/12.0.0/lib/libalr.a /u01/ar121/TR12/apps/apps_st/appl/alr/12.0.0/lib/libalr.a.BCK
    mv /u01/ar121/TR12/apps/apps_st/appl/ap/12.0.0/lib/libap.a /u01/ar121/TR12/apps/apps_st/appl/ap/12.0.0/lib/libap.a.BCK
    mv /u01/ar121/TR12/apps/apps_st/appl/ar/12.0.0/lib/libar.a /u01/ar121/TR12/apps/apps_st/appl/ar/12.0.0/lib/libar.a.BCK
  2. Relink phase of the patch fails with ld: Mismatched ABI (not an ELF file) for many binaries

    Relinking module 'ALECTC' in product alr ...
    make -f /u01/ar121/TR12/apps/apps_st/appl/admin/TR12/out/link_alr_21558.mk
    Starting  link of alr executable 'ALECTC' on Tue Apr 20 10:17:09 EETDST 2010
    ....many lines skipped....
    ld: Mismatched ABI (not an ELF file) for
    Fatal error.
    *** Error exit code 1

    This is similar to the previous one, some part of all *.o files turned out to be “PA-RISC2.0 relocatable object” format which is not usable here. But the strange thing was that the customer specific patch contained the correct type of those files, so why weren’t they applied? I checked the $APPL_TOP/admin/$TWO_TASK/log/adpatch_custspec5.lgi (the files has the same name that you set for adpatch logfile, just the extention is “.lgi”), to find the reason why the file was not applied:

    Will not apply aldvss.o: Files have same version.
      Patch  : /u01/ar115/TR12/install/Platform_patch/9597333/alr/lib/aldvss.o, v120.0
      On-Site: /u01/ar121/TR12/apps/apps_st/appl/alr/12.0.0/lib/aldvss.o, v120.0

    adpatch was still able to figure out the version of PA-RISC type file, so it did not apply those files in the end, therefore I had to force adpatch apply the files. To do that I just renamed the PA-RISC type files listed in the adpatch_custspec5.lgi file. I used this simple command to do that (it checks the lgi for files which were not applied, checks the type of the file, and if it contains “PA-RISC”, renames it by adding “.PRE_CUSTSPEC” to the filename)

    --use at your own risk
    cd $APPL_TOP/admin/$TWO_TASK/log/
    grep On-Site adpatch_custspec5.lgi | awk '{print $2}' | sed 's/,//' | xargs -n 1 file | grep PA-RISC | awk -F ':' '{print $1 ' ' $1 '.PRE_CUSTSPEC' }' |     xargs -n 2 mv

    After doing this the adpatch has to be restarted (don’t continue the previous adpatch session when asked).

  3. Relink phase of the patch fails with cat: Cannot open /opt/appltr12/apps/tech_st/10.1.2/lib32/ldflags: No such file or directory for many binaries

    The errors is a consequence of incorrect softlinks for some files in R12 techstack. The links were pointing to obvisously incorrect location at “/apps/R12/ab/apps/R1211XB9”, which looks to be the path where the techstack was located before packing it into the installation media. The solution is to find the wrong links and recreate them correctly. Use this to find all links in techstack (there are not too many of them):

    cd /u01/ar121/TR12/apps/tech_st
    ls -l `find . -type l` # verify for wrong links

    I used those commands to recreate the links:

    cd /u01/ar121/TR12/apps/tech_st
    ln -sf ../../10.1.3/lib32/libclntsh.so.10.1 ./10.1.3/instantclient32/libclntsh.so.10.1
    ln -sf ../../10.1.3/lib32/libheteroxa10.so ./10.1.3/instantclient32/libheteroxa10.so
    ln -sf ../../10.1.3/lib32/libnnz10.so ./10.1.3/instantclient32/libnnz10.so
    ln -sf ../../10.1.3/lib32/libocci.so.10.1 ./10.1.3/instantclient32/libocci.so.10.1
    ln -sf ../../10.1.3/lib32/libocijdbc10.so ./10.1.3/instantclient32/libocijdbc10.so
    ln -sf ../../10.1.3/lib/ldflags ./10.1.3/lib32/ldflags
    ln -sf ../../10.1.3/lib/libagtsh.so.1.0 ./10.1.3/lib/libagtsh.so
    ln -sf ../../10.1.3/lib32/libocci.so.10.1 ./10.1.3/lib32/libocci.so
    ln -sf ../../../10.1.3/nls/lbuilder/lbuilder ./10.1.3/bin/lbuilder
    ln -sf ../../10.1.3/lib32/hsdb_odbc.so ./10.1.3/lib/hsdb_odbc.so
    ln -sf ../../10.1.3/lib32/libnavhoa.a ./10.1.3/lib/libnavhoa.a
    ln -sf ../../10.1.3/lib32/hsdb_ora.so ./10.1.3/lib/hsdb_ora.so
    ln -sf ../../10.1.3/lib32/hsdb_inf.so ./10.1.3/lib/hsdb_inf.so
    ln -sf ../../10.1.3/lib32/hsdb_oing.so ./10.1.3/lib/hsdb_oing.so
    ln -sf ../../10.1.3/lib32/hsdb_syb.so ./10.1.3/lib/hsdb_syb.so
    ln -sf ../../10.1.3/lib32/libagtsh.so.1.0 ./10.1.3/lib32/libagtsh.so
    ln -sf ../../10.1.2/lib32/libclntsh.so.10.1 ./10.1.2/instantclient32/libclntsh.so.10.1
    ln -sf ../../10.1.2/lib32/libheteroxa10.so ./10.1.2/instantclient32/libheteroxa10.so
    ln -sf ../../10.1.2/lib32/libocijdbc10.so ./10.1.2/instantclient32/libocijdbc10.so
    ln -sf ../../10.1.2/lib32/libnnz10.so ./10.1.2/instantclient32/libnnz10.so
    ln -sf ../../10.1.2/lib32/libocci.so.10.1 ./10.1.2/instantclient32/libocci.so.10.1
    ln -sf ../../10.1.2/lib/libagtsh.so.1.0 ./10.1.2/lib/libagtsh.so
    ln -sf ../../10.1.2/lib32/libocci.so.10.1 ./10.1.2/lib32/libocci.so
    ln -sf ../../10.1.2/lib32/libagtsh.so.1.0 ./10.1.2/lib32/libagtsh.so
    ln -sf ../../10.1.2/lib32/libnavhoa.a ./10.1.2/lib/libnavhoa.a
    ln -sf ../../10.1.2/lib32/hsdb_inf.so ./10.1.2/lib/hsdb_inf.so
    ln -sf ../../10.1.2/lib32/hsdb_odbc.so ./10.1.2/lib/hsdb_odbc.so
    ln -sf ../../10.1.2/lib32/hsdb_oing.so ./10.1.2/lib/hsdb_oing.so
    ln -sf ../../10.1.2/lib32/hsdb_syb.so ./10.1.2/lib/hsdb_syb.so
    ln -sf ../../10.1.2/lib32/hsdb_ora.so ./10.1.2/lib/hsdb_ora.so
    ln -sf ../../../10.1.2/webcache/bin/webcachectl ./10.1.2/bin/webcachectl
    ln -sf ../../10.1.2/lib/ldflags ./10.1.2/lib32/ldflags
    ln -sf ../../../10.1.2/nls/lbuilder/lbuilder ./10.1.2/bin/lbuilder
    ln -sf ../../../10.1.2/webcache/docs/readme.examples.html ./10.1.2/webcache/examples/readme.examples.html
    ln -sf ../../10.1.2/webcache/lib ./10.1.2/webcache/lib32
    ln -sf ../../../10.1.2/sysman/jlib/log4j-core.jar ./10.1.2/sysman/webapps/emd/WEB-INF/lib/log4j-core.jar
  4. Relink phase of the patch fails with ld: Unable to load shared library "/opt/langtools/lib/hpux64/libu2comp.so" for many binaries

    Quick browse over HP forums made me think it could be the missing “PHSS_39824 - 11.31 HP C/aC++ Compiler (A.06.23) patch” which provides those shared libraries. We hadn’t applied it because the MOS doc Oracle Applications Installation and Upgrade Notes Release 12 (12.1.1) for HP-UX Itanium [ID 762891.1] does not specify it as a requirement, it only says aCC_link is required, but that’s there on HP-UX v11.31 already without installation of additional packs.

    Despite that it’s not listed in the requirements we decided to have a go and install it. Normally this pack requires additional licences, but Oracle Applications Installation and Upgrade Notes Release 12 (12.0) for HP-UX Itanium [ID 555893.1] says:

    Install the HP C/aC++ Developer’s Bundle

    The HP aC++ linker is included in the HP C/aC++ Developer’s Bundle and is available from the HP Web site. Download and install the 60-day trial version. The 60-day trial period applies to the compiler only. Oracle Applications requires the linker included in the developer’s bundle, which can be used beyond the 60-day trial.

    Installation of the 60-day trial version of HP C/aC++ Developer’s Bundle resolved this issue.