| Oracle® Outside In File ID Developer's Guide Release 8.4.0 Part Number E12875-03 |
|
|
View PDF |
| Oracle® Outside In File ID Developer's Guide Release 8.4.0 Part Number E12875-03 |
|
|
View PDF |
The UNIX implementation of File ID is delivered as a set of shared libraries. For a list of the currently supported platforms, see:
http://www.oracle.com/technetwork/indexes/documentation/index.html#middleware
Click on Outside In Technology, then click the Certification Information PDF.
This chapter includes the following sections:
To install the demo version of the SDK, copy the tgz file corresponding to your platform (available on the web site) to a local directory of your choice. Decompress the tgz file and then extract from the resulting tar file as follows:
gunzip tgzfile tar xvf tarfile
The installation directory should contain the following directory structure.
| Directory | Description |
|---|---|
|
/docs |
Includes HTML and PDF versions of the manual you are reading right now. |
|
/redist |
Contains a working copy of the UNIX version of the technology. |
|
/sdk/common |
Contains the C include files needed to build or rebuild the technology. |
|
/sdk/demo |
Contains the compiled executable of the sample application. |
|
/sdk/resource |
Contains localization resource files. |
|
/sdk/samplecode |
Contains a subdirectory holding the source code for a sample application |
|
/sdk/samplefiles |
Contains sample files designed to exercise the technology. |
On the UNIX platforms, Outside In Technology SDKs are delivered with a set of shared libraries. All libraries should be installed to a single directory. Depending upon your application, you may also need to add that directory to the system's runtime search path. Please see Section 3.4, "IBM AIX Compiling and Linking", Section 3.5, "Linux Compiling and Linking", and Section 3.6, "Oracle Solaris Compiling and Linking" for platform-specific path information.
The following is a brief description of the included libraries and support files. In instances where a file extension is listed as .*, the file extension varies for each UNIX platform (sl on HP/UX, so on Linux and Solaris, and a or o on IBM AIX):
API Libraries: These libraries implement the API. They should be linked with the developer's application.
libsc_fi.*: File Identification module (identifies files based on their contents). The File ID Specification may not be used directly by any application or workflow without it being separately licensed expressly for that purpose.
Support Libraries
libsc_fut.*: Filter utility module
libsc_lo.*: Localization library (all strings, menus, dialogs and dialog procedures reside here)
libsc_ut.*: Utility functions, including IO subsystem
libwv_core.*: The System Call GDI Abstraction layer
This section contains information about basic usage and options.
Any source code that uses File ID should #include the file sccfi.h, and #define UNIX. For example, a 32-bit UNIX application might have a source file with the following lines:
#define UNIX #include <sccfi.h>
and a 64-bit UNIX application might have a source file with the following lines:
#define UNIX #define UNIX_64 #include <sccfi.h>
The software creates a default list of options. It is built as needed, usually the first time the product runs. You do not need to ship it with your application.
This list (*.opt) is stored in the $HOME/.oit directory. If the $HOME environment variable is not set, the file is placed in the same directory as the Outside In Technology. If a .oit directory does not exist in the user's $HOME directory, the .oit directory is created automatically by the technology. The file is automatically regenerated if corrupted or deleted.
The option file ends in *.opt and is intended to be unique enough to avoid conflict for any combination of machine name and install directory. This is intended to prevent problems with version conflicts when multiple versions of the Outside In SDKs are installed on a single system. The file name is built from an 11-character string derived from the directory the Outside In technology resides in and the name of the machine it is being run on. The string is generated by code derived from the RSA Data Security, Inc. MD5 Message-Digest Algorithm.
|
Note: The Java Native Interface (JNI) allows Java code to call and be called by native code (C/C++ in the case of OIT). You may run into problems if Java isn't allowed to handle signals and forward them to OIT. If OIT catches the signals and forwards them to Java, the JVMs will sometimes crash. OIT installs signal handlers when DAInitEx() is called, so if you call OIT after the JVM is created, you will need to use libjsig. Refer here for more information:
|
Libraries and sample applications are all built with the $ORIGIN variable as part of the binaries' runtime search path. This means that at runtime, OIT libraries will automatically look in the directory they were loaded from to find their dependent libraries. You don't necessarily need to include the technology directory in your LD_LIBRARY_PATH or SHLIB_PATH.
As an example, an application that resides in the same directory as the OIT libraries and includes $ORIGIN in its runtime search path will have its dependent OIT libraries found automatically. You will still need to include the technology directory in your linker's search path at link time using something like -L and possibly -rpath-link.
Another example is an application that loads OIT libraries from a known directory. The loading of the first OIT library will locate the dependent libraries.
Note:
This feature does not work on AIX and FreeBSD.
A number of environment variables must be set at run time. They are described elsewhere. Following is a short summary of those variables and their use.
| Variable | Description |
|---|---|
|
Platform-specific variable used to specify the location of the shared libraries used by the technology. See Section 3.4, "IBM AIX Compiling and Linking", Section 3.5, "Linux Compiling and Linking", and Section 3.6, "Oracle Solaris Compiling and Linking" for details. |
|
|
Must be set to allow the system to write the option list. |
All of the strings used in the UNIX versions of Outside In products are contained in a file called lodlgstr.h. This file, located in the resource directory, can be modified for internationalization and other purposes. Everything necessary to rebuild the resource library to use the modified source file is included with the SDK.
Along with lodlgstr.h, an object file, scclo.o, has been provided which is necessary for the linking phase of the build. A makefile has also been provided for building the library. The makefile allows building on all of the UNIX platforms supported by Outside In. It may be necessary to make minor modifications to the makefile so that the system header files and libraries can be found for compiling and linking. There are standard INCLUDE and LIB make variables defined for each platform in the makefile. Edit these variables to point to the header files and libraries on your particular system. Other make variables are:
TECHINCLUDE: May need to be edited to point to the location of the Outside In common header files that are supplied with the SDK.
BUILDDIR: May need to be edited to point to the location of the makefile, lodlgstr.h, and scclo.o (which should all be in the same directory).
Once these make variables are set, change to the build directory and type make. The resource library, libsc_lo, will be built and placed in the appropriate platform-specific directory. To use this library, copy it into the directory where the Outside In product resides, and the new, modified resource strings can then be used by the technology.
All libraries should be installed into a single directory and the directory must be included in the system's shared library path ($LIBPATH) as well as the executable path ($PATH).
Note:
$LIBPATH MUST be set and must point to the directory containing the Outside In technology.
Outside In Technology has been updated to increase performance, at a cost of using more memory. It is possible that this increased memory usage may cause a problem on AIX systems, which can be very conservative in the amount of memory they grant to processes. If your application experiences problems due to memory limitations with Outside In, you may be able to fix this problem by using the "large page" memory model. If you anticipate viewing or converting very large files with Outside In technology, we recommend linking your applications with the "-bmaxdata" flag (for example, 'cc -o foo foo.c -bmaxdata:0x80000000'). If you are currently seeing "illegal instruction" errors followed by immediate program exit, this is likely due to not using the large data model.
The libsc_fi.a library must be linked with your application. It can be loaded when your application starts by linking it directly at compile time or can be loaded dynamically by your application using library load functions (load and loadbind) with the ".o" versions of the libraries provided.
The following is an example command line used to compile the fisimple sample application from the /sdk/samplecode directory. This command line is only an example. The actual command line required on the developer's system may vary. The example assumes that the include and library file search paths for the technology libraries and any required X libraries are set correctly. If they are not set correctly, the search paths for the include and/or library files must be explicitly specified via the -I include file path and/or -L library file path options, respectively, so the compiler and linker can locate all required files.
Note:
Developers may need to use the -qcpluscmt flag to allow C++ style comments.
gcc -w -o ../fisimple/unix/fisimple ../fisimple/unix/fisimple.c -I../../common -L../../demo -lsc_fi
Two versions of some AIX modules have been included in this package. Including the libsc_fi.a file on the compiler's command line with a path that causes that path to be hard coded in the executable. The -L option does not detect object files, and forcing developers to keep a copy of this file in their own source directory would be clumsy at best. On the other hand, load does not work with library archive files, only with object files.
The libsc_fi.so library must be linked with your application. It can be loaded when your application starts by linking it directly at compile time or it can be loaded dynamically using library load functions (for example, dlopen).
The following example command line is used to compile the fisimple sample application from the /sdk/samplecode directory. This command line is only an example. The actual command line required on the developer's system may vary. The example assumes that the include and library file search paths for the technology libraries are set correctly. If they are not set correctly, the search paths for the include and/or library files must be explicitly specified via the -I include file path and/or -L library file path options, respectively, so that the compiler and linker can locate all required files.
Linux 32-bit
gcc -w -o ../fisimple/unix/fisimple ../fisimple/unix/fisimple.c -I../../common -L../../demo -lsc_fi -Wl,-rpath,../../demo -Wl,-rpath,'${ORIGIN}'
Linux 64-bit
gcc -w -o ../fisimple/unix/fisimple ../fisimple/unix/fisimple.c -I../../common -L../../demo -lsc_fi -DUNIX_64 -Wl,-rpath,../../demo -Wl,-rpath,'${ORIGIN}'
This product does not support the old "Solaris BSD" mode.
All libraries should be installed into a single directory and the directory should be included in the system's executable path ($PATH).
The libsc_fi.so library must be linked with your application. It can be loaded when your application starts by linking it directly at compile time or can be loaded dynamically by your application using library load functions (for example, dlopen).
The following is an example command line used to compile the fisimple sample application from the /sdk/samplecode directory. This command line is only an example. The actual command line required on the developer's system may vary. The example assumes that the include and library file search paths for the technology libraries are set correctly. If they are not set correctly, the search paths for the include and/or library files must be explicitly specified via the -I include file path and/or -L library file path options, respectively, so the compiler and linker can locate all required files.
cc -w -o ../fisimple/unix/fisimple ../fisimple/unix/fisimple.c -I/usr/include -I../../common -L../../demo -lsc_fi -Wl,-R,'${ORIGIN}'
Note: When running the 32-bit SPARC binaries on Solaris 9 systems, you may see the following error:
ld.so.1: simple: fatal: libm.so.1: version `SUNW_1.1.1' not found (required by file ./libsc_vw.so)
This is due to a missing system patch. Please apply the following patch (or its successor) to your system to correct.
For Solaris 9: Patch 111722-04
|
 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|