2 Replies Latest reply on May 3, 2019 9:22 AM by user11763611

    OCI dynamic linking and libclntsh.so.X.Y dependency




      Provide detailed information about dynamic linking rules and resulting dependencies to libclntsh.so.X.Y lib versions!


      Tthe doc is too vague about that:




      Note the typo  "/imclude"  ... (anyway invalid directory no? with instant client we get sdk/include and with oracle server headers are in rdbms/public)


      Why does Oracle increment the libclntsh.so.X.1 version for each new feature release like 12/18/19?

      I suppose it's because new OCI APIs are introduced... correct?

      Would be nice to clarify this in the doc...


      Our need:

      We want to deliver our software with binaries loading our own shared lib as interface modules to Oracle Client.

      We want to support several Oracle Client environments from 11c to 19c and future releases.

      What is the recommended way (on Linux, AIX, Solaris)?


      We plan to provide the following database interface modules of our product:


      dbmora_11.so  => libclntsh.so.11.1       (for Oracle 11c client)

      dbmora_12.so  => libclntsh.so.12.1       (for Oracle 12c client)

      dbmora_18.so  => libclntsh.so.18.1       (for Oracle 18c client)

      dbmora_19.so  => libclntsh.so.19.1       (for Oracle 19c client)


      Eventually, since the client lib is backward compatible, we could only provide dbmora_12.so linked to libclntsh.so.12.1,

      assuming that we use only 12c OCI APIs.


      However, I think it's better to have dedicated modules for each "feature" version 11/12/18/19, in case if we need to

      use a specific API that is only available in such a version.