Shared Libraries and Shared Objects Support

Shared objects are dynamically linked and appear as a single object file containing code for every function in the library. When your program uses a function from a shared object, the content of the shared library is placed into the virtual address space of your process at run time. In addition, other programs use the code in the shared objects simultaneously at run time.

Shared libraries provide the following advantages over archives:

• Shared library code requires less disk space because it is not copied into the executables that use it.

• The system needs less physical memory because library code is shared at run time.

• Shared objects can be updated without having to relink applications that depend on them, because symbol resolution is delayed until the program actually runs.

Creating the Shared Library for Pro*C and Oracle*XA Clients

1. Create the shared library.

2. Create executables that use shared code.

3. Ensure that the shared library is accessible at program runtime.

Attention: Make sure no applications using libclntsh.so are running when you rebuild libclntsh.so.

Oracle7 and Pro*C products must be installed before the shared library is generated. If you install Oracle*XA later, the Oracle Installer re-runs the makefile to include Oracle*XA in the shared library.

You must rebuild the client-side shared library when you:

• install or de-install SQL*Net version 2 protocol adapters

• apply a patch to any of the following static Oracle libraries:

• libora.a

• libsqlnet.a

• libxa.a

• libsql.a

• libcore3.a

• libnlsrtl3.a

• libc3v6.a

• libocic.a

• change any static operating system or optional networking libraries referenced in the $ORACLE_HOME/rdbms/lib/sysliblist file

1. Change the directory to $ORACLE_HOME/rdbms/lib.

2. Build the shared library using the make command.

Example:

$ cd $ORACLE_HOME/rdbms/lib

$ make -f clntsh.mk libclntsh

Creating Executables that Use the Shared Library

	% make -f $ORACLE_HOME/proc/lib/proc.mk \ 
	  ORA_CLIENT_LIB=shared OBJS=foo.o EXE=foo

You can also set the variable ORA_CLIENT_LIB in your environment, then generate the executable without explicitly passing in the environment variable. For example:

	% make -f $ORACLE_HOME/proc/lib/proc.mk OBJS=foo.o \ 
	  EXE=foo

Using Shared Code at Runtime

• When you create the executable, set the environment variable LD_RUN_PATH to the directory path of the shared library at link time. This stores a list of directories in the executable itself.

Use this method if you are using setuid programs. They ignore LD_LIBRARY_PATH at runtime, to avoid security problems.

• Set the LD_LIBRARY_PATH environment variable at runtime to to the directory path of the shared library.

If the executable runs in an $ORACLE_HOME directory other than the one in which it is linked, you must set LD_LIBRARY_PATH. You can use the UNIX ldd command to determine where the dynamic linker is searching for shared objects.

If the dynamic linker is unable to find the shared object, a message similar to the following appears:

$ ./sample1 
  ld.so.1: sample1: fatal: libclntsh.so: 
  can't open file: errno=2 
  Killed 

Restrictions