Go to the previous, next section.
This document describes the installation of version 2.0beta1 of the Inter-Language Unification (ILU) system.
If you succeed in installing ILU on a particular platform,
we'd appreciate it if you could send a note to ilu-core@parc.xerox.com
telling us (1) what operating system you succeeded with, and what version
of that OS, (2) which versions of what compilers you used, and (3) which
version of ILU you used. We're accumulating
a list of operating systems and compilers that work with ILU. If you
had to make any changes to make it work on your system, please send them
along, and we'll incorporate them into the next release.
You will need an ANSI C compiler to build and install
ILU, along with an ANSI C-compliant `libc.a'.
Note that GNU gcc doesn't always work as an ANSI C compiler.
The simple test we use to qualify a compiler is whether it can compile and link
the following program without warnings or errors:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <limits.h>
int main(int ac, char **av) {
int i = INT_MAX;
char *p = (char *) malloc(1048);
memmove(p, *av, strlen(*av)+1);
printf("%s %d\n", p, i);
return 0;
}
ILU requires the imake program from the MIT X Consortium release
of the X Window System, version 4 or later. This is available via FTP
from the ftp servers ftp.x.org on the East Coast, or gatekeeper.dec.com
on the West Coast. You can also get it from
ftp://ftp.parc.xerox.com/pub/ilu/imake/imake.tar.gz.
ILU normally provides support for a number of languages, currently ANSI C, C++, Java, Python, and Common Lisp (Franz Allegro 4.3), but the 2.0beta release only contains solid support for ANSI C, Java, C++, and Python. The C++ support provided conforms to the CORBA 2.0 specication. The old ILU mapping for C++ support is still provided, but no longer maintained more than minimally. There is good support for Common Lisp in 2.0alpha, but it lacks some of the features provided for C, Java, and Python. There is rough support for Guile Scheme, contributed by Siemens Corporate Research, Inc. ILU support for the Perl programming language is available from Owen Taylor; see http://www.msc.cornell.edu/~otaylor/ilu/ for details.
g++ seems
to work well with ILU. It has also been tested with Lucid's Energize lcc compiler,
CenterLine's CC compiler, and Sun's CC compiler.
select system call instead of poll (which is present but decidecly inferior on Linux). ILU also supports various beta releases (some of which might require special handling). Support for applets or Netscape is not generally available. Hotspot is not yet supported.
guile -c '(use-module '(ice-9 slib))' to see
if yours is configured properly.
Begin by creating two directories: one, ILUHOME, to install the ILU in, and the other, ILUSRC, to unpack the sources in, and build the system in. It is often convenient if ILUSRC is a sub-directory of ILUHOME, but it is not necessary. At PARC, we use `/import/ilu' for ILUHOME, and `/import/ilu/src' for ILUSRC.
Copy the compressed tar file `ilu-2.0beta1.tar.Z' or `ilu-2.0beta1.tar.gz' to
ILUSRC. Uncompress it if necessary with
the uncompress or gunzip program:
% uncompress ilu-2.0beta1.tar.Z
or
% gunzip ilu-2.0beta1.tar.gz
Then unpack the tar file:
% tar xf ilu-2.0beta1.tar
We suggest you then look at the ILU home page, ftp://ftp.parc.xerox.com/pub/ilu/ilu.html, to see whether a patch file for release 2.0beta1 exists. If so, fetch that patch file and apply it according to the instructions at the top of the file. It's best to fetch the patch file using FTP instead of the Web; the additional line-ending transformations that Web browsers (particularly Netscape) apply can render the patches in the file worthless.
You can try just unpacking it, and then typing
% make
at the top of the source tree. A minimal configuration using defaults will be built, sufficient for testing. This takes you up through step 2 of the "Building" section below.
ILU uses the GNU autoconf system to configure the release, before building. The very simplest way to configure your system is type type
% ./configure
at the top of the source tree.
What will happen is that ILUSRC/imake/configure will go out and look along
the value of your PATH environment variable for various executable
programs. If it finds cc, it will assume that you want to build
ANSI C support for ILU. If it finds java, it will assume
that you want to build Java support for ILU. If it
finds cl or franz, it will assume that you want to build
Lisp support for ILU. If it finds python, it will
assume that you want to build Python support for
ILU. If it finds CC or cxx or c++, it will assume that you want to build
C++ support for ILU. It will also assume that the
first executable with an appropriate name is the one you wish to use for
compiling programs in that language. By default, it will assume that you
wish to include support only for using ONC RPC over TCP/IP.
By default, it will assume that you do not wish to provide support for OMG IDL.
imake must be on your path, or in `/usr/bin/X11/', for the build to work properly.
Since our Makefiles are constructed via imake from Imakefiles, which involves running the C preprocessor, watch out for use of predefined C preprocessor symbols in pathnames! Common boobytraps include names of processors, vendors, and operating systems (e.g., "sparc", "sun", "hpux"), which are used (as isolated tokens according to C rules) in some folks' conventions for naming directories. If you're lucky, you can solve these problems with quoting. A more heavy-duty approach is to configure, then #undef the offending macros at the start of `ILUSRC/imake/ilu.defs.new', and re-#define them at the end of that file.
The program configure can be invoked with a number of command line options, to customize
the build for your site. It actually supports more options than shown here, but these
are the only options that will work at this point in the release process. For those options
that begin --enable-FEATURE, you can specify the switch either with --enable-FEATURE, to enable the feature or option, or --disable-FEATURE, to disable the feature or option.
--with-destdir=PATH -- this should be the name of the directory you would like
the files installed into, in the make Install step. The default
is `/usr/local/ilu', which may be OK for your system.
--with-iluhome=PATH -- this should be the name of the directory
users will expect ILU to be installed under, the value of ILUHOME. The two options
--with-destdir and --with-iluhome are provided separately because a directory may have
two different names that are used to access it in different ways. At PARC, for instance,
installation directories are often write-protected if named with their ordinary names,
and a special name has to be given to enable writing in that directory. If your site
does not have this type of restriction, the switches for --with-destdir and --with-iluhome
should probably have the same values. Note that the default is `/usr/local/ilu', which
may be OK for your system.
--prefix=PATH -- if specified, this becomes the default for ILUHOME and DESTDIR,
if they are not specified explicitly.
--with-binding-dir=PATH -- a world-writable directory in a shared file system,
for supporting the "simple binding" service described in Chapter 1. This option and the use
of a binding service (see next item) are mutually exclusive.
--with-binding-server=REALM:HOST:PORT -- an alternative to using the shared file system for simple
binding, this says that a binding registration server for the binding realm called REALM will be available
on port PORT of host HOST. The binding server will be built and installed as part of
the build process, but still has to be started manually. This option and the use of a binding directory are mutually exclusive.
--enable-version-2-type-uids -- compiles in support for documented type UID hash algorithm instead of the old default type UID hash algorithm. Versions of ILU configured with one algorithm are not generally compatible with versions configured with the other algorithm.
--enable-debugging -- compiles in debugging printfs and a small amount of additional
debugging code. Recommend enable. Enabled by default.
--enable-testing-scripts -- allows support for some testing scripts. Enabled by default.
--enable-os-threads[=TYPE] -- compiles in support for using either "solaris2", "posix", or "dce" (also known as POSIX.4) threads with the C support. If the TYPE isn't specified, it will attempt to guess the right default. The default is to enable thread support for platforms where the configure script knows thread support exists (currently only Solaris 2 (Solaris 2 threads), OSF 3 (DCE threads), OSF 4 (POSIX threads), AIX 4.x (POSIX threads), IRIX 6.x (POSIX threads), and linux-gnu (POSIX threads if `/usr/lib/libpthread.a' is present)). See the following section on "Manual Fixups for Threading", as well.
--enable-new-keywords-plain -- normally, keywords added to ISL subsequent to 2.0alpha11 begin with "ILU", to avoid conflicts with user interfaces. However, by throwing this switch, this prefix will be omitted, and new keywords such as "string" and "state" will be recogized directly, rather than as "ilustring" and "ilustate".
--enable-type-support -- includes support for runtime type registration. If either the IIOP or w3ng protocols is included, type support must be enabled. (Enabled by default).
--enable-pickle-support -- includes support for a dynamically typed data type, called pickle in ILU and any--enable-pickle-format-2 -- includes support for type 2 pickles. (The pickle type is supported with several formats, currently with version numbers 2 and 3.) (Enabled by default).
--enable-pickle-format-3 -- includes support for type 3 pickles. (The pickle type is supported with several formats, currently with version numbers 2 and 3.) (Enabled by default if the w3ng protocol is included; disabled by default otherwise.)
--enable-omg-idl-support -- includes support for parsing interface description files written in OMG IDL. (Enabled by default.)
--enable-idl2isl-support -- builds old ILU OMG IDL support program called idl2isl. You will need to have a C++ compiler (CFRONT 3.0 or later) on your path. g++ seems to work fine. You will need to have fetched the source tar file from `ftp://ftp.parc.xerox.com/pub/ilu/misc/idl2isl.tar.gz', and to have unpacked it in the ILUSRC directory, before configuring. The version of OMG IDL recognized by this parser is no longer current valid OMG IDL. (Disabled by default.)
--enable-xml-parser-library -- includes a validating XML parser library. (Disabled by default.)
--enable-security -- causes the GSS-based transport filter to be built, and also the GSS implementation. Default is disabled.
--enable-ssl-security -- causes the SSL mechanism for GSS to be built. Not for public use (the public distribution of ILU does not contain the SSL mechanism in either source or binary form because of our inability to enforce export controls). Requires --with-rsaref=... and --with-libdes=.... Default is disabled.
--with-rsaref=LIB:INSTALLDIR -- specifies the location of the RSAREF-2.0 library file and installation directory. The installation directory is the parent of the `source' directory. This is only needed if you are building the SSL mechanism for the GSS shell (the SSL mechanism is not distributed publicly due to our inability to implement export controls).
--with-libdes=LIB:INCLUDEDIR -- specifies the location of the libdes 3.0 library file and include directory. This is only needed if you are building the SSL mechanism for the GSS shell (the SSL mechanism is not distributed publicly due to our inability to implement export controls).
--enable-sunrpc-protocol -- compiles in support for using ONC RPC across address spaces. (Enabled by default.) This is probably our most flexible and most widely tested protocol.
--enable-courier-protocol -- compiles in support for using XNS Courier RPC across address spaces. (Disabled by default) This protocol is more efficient than the ONC RPC protocol in terms of bytes-on-the-wire, but may have slightly higher marshalling and unmarshalling overhead.
--enable-corba-iiop -- includes support for using the CORBA Internet Inter-Orb Protocol across address spaces. (Enabled by default) IIOP is the standard interoperability protocol for CORBA; people using ILU mainly for CORBA purposes should probably also specify IIOP as their default protocol (see --with-default-protocol).
--enable-http-protocol -- compiles in support for using the World Wide Web HTTP 1.x between address spaces. (Disabled by default) This also provides support for implementing Web servers and clients with ILU.
--enable-w3ng-protocol -- compiles in support for using a prototype of the HTTP-NG wire protocol between address spaces. (Disabled by default) This is a relatively new protocol which is probably the most efficient of all our supported protocols.
--with-default-protocol=PROTOCOL -- specifies which `wire protocol' to use as the default one for inter-process communication. The default default protocol is "sunrpc". If you're interested in doing CORBA work with ILU, you may want to specify "iiop" as the default protocol, since IIOP is the standard CORBA interoperability protocol.
--enable-tcp-transport -- includes support for using TCP/IP to transport messages. (Enabled by default.)
--enable-sunrpcrm-transport -- compiles in support for the ONC RPC record-marking transport filter. This transport filter can be used with the w3ng or sunrpc protocols to provide record-marking on top of a byte-stream layer. (Enabled by default.)
--enable-w3mux-transport -- compiles in support for using a prototype of the HTTP-NG multiplexing transport filter. (Disabled by default.) The current implementation of this transport requires the use of threads.
--enable-zlib-transport -- compiles in support for using zlib message compression on messages. you also need to specify --with-zlib=FOO for this transport. (Disabled by default.)
--with-zlib=LIB:INCLUDE_DIR -- specifies the location of the zlib library and include directory. This is only needed if you are including support for the zlib compression transport. (No default.)
--enable-c-support -- includes ILU support for the ANSI C programming language. (Enabled by default.)
--enable-c-shared-library -- causes shared-library version of the C runtime to be built. (Disabled by default.)
--enable-c-timing-statistics -- if enabled, adds code to the C runtime to collect statistics on call times. (Disabled by default.)
--enable-corba-cplusplus-support[=PROG] -- enables CORBA-style C++ support. This support is not compatible with the original ILU style of mapping for C++. The two options are mutually exclusive; if neither is specified, but a C++ compiler is available, the CORBA-style C++ support will be selected. If PROG is specified, treats PROG as the command to use for C++ compilation; PROG must be the full path name. Default is to enable C++ support iff the environment variable CXX is defined,
in which case CXX should be the full path name of the compilation command, or if any of the programs CC, CXX, cxx, c++, or g++ are available on your PATH environment variable.
--with-cplusplus-mapping=OPTION -- only valid if CORBA C++ support is specified. Controls which of the three major CORBA C++ mapping genres is produced, depending on whether your C++ compiler has support for namespaces, nested classes, or neither. OPTION must be one of Namespaces, NestedClasses, or Underscores. If not specified, the configuration process attempts to choose something reasonable (and usually succeeds).
--with-cplusplus-libs=LIBS -- defines the Makefile symbol CPLUSPLUS_LIBRARIES to be the value of LIBS, with all colon characters in LIBS replaced with space characters. This is used to record the libraries your C++ code must be linked with to function properly. This information can then be used to build libraries of C++ code that can be used with other programming languages. If not specified, this symbol is defined as `not specified'. If your C++ really doesn't need any extra libraries, you should still specify --with-cplusplus-libs explicitly, but give the special value of none for LIBS. If you are planning to use ILU true modules implemented in C++ interoperate with other non-C++ modules in a single address space, you will have to figure out the correct setting for this switch.
--enable-old-cplusplus-support[=PROG] -- enables old original ILU-style C++ support. This support is not compatible with the CORBA 2.0 style of mapping for C++. If PROG is specified, treats PROG as the command to use for C++ compilation; PROG must be the full path name. Default is to enable ILU-style C++ support iff (1) the CORBA-style C++ support has been explicitly disabled, and (2) the environment variable CXX is defined, in which case CXX should be the full path name of the compilation command, or if any of the programs CC, CXX, cxx, c++, or g++ are available on your PATH environment variable. Note that this option is incompatible with the option --enable-corba-cplusplus-support; only one of the two may be selected.
--enable-java-support -- enables Java support. (Default is to enable it if a program called java is on your PATH environment variable, and if the configuration script decides that the Java installation is well-formed; disabled otherwise.)
--with-java-nopoll -- specifies that the Java runtime must use the select system call rather than poll. This is needed only on Linux, where we haven't yet figured out how to make autoconf make the right decision automatically.
--with-java-threads=KINDS -- specifies which version(s) of Java's runtime multi-threading support to configure ILU for. Possible choices for KINDS are green, native, or both. Use this only if the default configuration logic gets it wrong. Don't use this if ILU is being configured to use JNI for native methods.
--enable-java-jni -- specifies that the Java runtime must use JNI for the Java native method implementation. Use this only on Java releases jdk1.2 and later as ILU requires JNI features not available on previous releases. Default is: use JNI only if the older native method implementation is not available and the Java release is jdk1.2 or later.
--enable-java-with-omg -- specifies that the Java runtime should includes ILU's own version of org.omg.CORBA classes. Default behaviour is to use ILU's classes with jdk 1.1 and the standard classes with jdk1.2.
--enable-java-cosnaming-prefix -- force use of standard (but conflicting) CosNaming prefix for Java classes. (Disabled by default.)
--enable-python-support{=PYTHON-HOME} -- enables Python support. If PYTHON-HOME is specified, treats PYTHON-HOME as the directory in which the Python system is installed. Default is: enabled if the program python is on your PATH environment variable; disabled otherwise.
--enable-old-python-gc-behavior -- Prevents Python true objects from being garbage collected by the Python runtime, even if there are no Python references to the object. This was the default in versions of ILU previous to 2.0alpha10. The default is to disable this.
--enable-corba-python-mapping -- Causes the Python stubber to produce, and the runtime to expect, the proposed CORBA mapping of OMG IDL (and ILU ISL) to Python, instead of the `classic' ILU mapping. This CORBA mapping is a work in progress; we expect significant changes to it in the future. Use at your own risk. The default is to disable this.
--enable-python-dictionaries -- In both the `classic' and CORBA mappings of ILU ISL to Python, causes all sequence types matching a certain profile to be mapped to and from Python dictionaries instead of Python lists. The sequence type must have a name that ends with either "dict" or "Dict"; the base type of the sequence type must be a record type; the record type must have exactly two fields; the two fields must be named name and value; and the type of the name field must be either an integer, byte, string, or cardinal type. The default is to disable this.
--enable-perl-support{=PERL-HOME} -- enables Perl support. If PERL-HOME is specified, treats PERL-HOME as the directory in which the Perl system is installed. Default is to enable this iff the PERL environment variable is defined (and in that case it should be defined to be the absolute filename of the Perl interpreter).
--enable-guile-support -- enables Guile Scheme support. Default is: enabled if the program guile is on your PATH environment variable, disabled otherwise.
--enable-lisp-support[=PROG] -- enables Franz Allegro Common Lisp support. Default is: enabled if any of the programs franz, cl, or lisp (in that order) are on your PATH environment variable, disabled otherwise. You can also explicitly specify the full pathname of the Lisp interpreter with PROG.
--enable-old-lisp-method-names -- at one point, the mapping of method names to Common Lisp was interface:methodname. This was ambiguous; it was changed to interface:typename.methodname. If this switch is specified, both old and new names will be available. (Disabled by default.)
--enable-xview-support -- builds the libraries to interface the XView GUI library to the ILU main loop. (Disabled by default)
--enable-xt-support -- builds the libraries to interface Xt-based GUI libraries to the ILU main loop. (Disabled by default)
--enable-tk-support -- builds the libraries to interface Tk-based GUI libraries to the ILU main loop. If this is enabled, the switches --with-tk-includes-dir and --with-tcl-includes-dir should also be specified. (Disabled by default)
--with-tk-includes-dir=DIR -- specifies where to find the Tk header files.
--with-tcl-includes-dir=DIR -- specifies where to find the Tcl header files.
--with-testing-python=EXECUTABLE -- can be used to specify a Python executable of version 1.5 or later, for use with the Python testing scripts. This is useful if you are not configuring in support for Python, or if you are configuring in support for a pre-1.5 Python. If not specified, reasonable attempts to find a good Python are taken.
The particular ANSI C compiler to use may be specified by setting the environment variable CC to the full path name of the C compilation command before running configure. Similarly, the particular C++ compiler to use may be specified by setting the environment variable CXX to the full path name of the C++ compilation command to use.
Once you've run the configure script, the output is stored in several files. The file which contains the symbols which control all of the Makefiles in the system is in ILUSRC/imake/ilu.defs.new. If you wish to fiddle with compiler options or things of that sort, that's the file to hack, before doing the make.
Sadly, our autoconf stuff is not yet fully up to the task of configuring for use of threads; you sometimes have to do a manual step or two, before and/or after running configure. This is better than it used to be; manual fixups should no longer be required for Solaris 2, OSF 3--4, IRIX 6.2--6.7, Linux 2.0, or AIX 4.1.4--4.4.
On some operating systems, linking POSIX threads programs requires a special flag, -lpthread, to appear at the end of the linkage command line. On others, the special flag is -lthreads or -lpthreads. If you operating system is not one of those listed above and you've configured with --enable-os-threads, you should find out out what the appropriate library for your system is and then edit `ILUSRC/imake/ilu.defs.new' after running configure but before running make. You should find a definition of the make variable SYSAUX_LIBRARIES and fix it (if necessary) to end with the appropriate -lwhatever for your system's threads.
On some operating systems the C and C++ compilers require a certain preprocessor symbol be #defined when compiling sources to be included in threaded programs (and it's OK to #define these symbols for single-threaded programs too). If configuring to include OS-supplied thread support on an operating system not listed above but requiring such a symbol definition, make sure you also explicitly supply a C compilation command, and that it includes -Dwhatever to #define this symbol.
On Linux, when using Provenzano's pthreads (POSIX threads) library, you use special scripts provided instead of gcc and g++. Those scripts are normally located at `/usr/local/pthreads/bin/pgcc' and `/usr/local/pthreads/bin/pg++'. Use the facilities described above to configure these scripts as your C and C++ (if you're doing C++) compilers. It's OK to compile even single-threaded programs this way. On our Linux systems, these scripts produce the following warning messages when linking executables:
bfd assertion fail /opt/release/pub/bin/binutils/bfd/elf32-i386.c:624 bfd assertion fail /opt/release/pub/bin/binutils/bfd/elfcode.h:4716
Despite the dire-sounding warnings, the linker seems to produce working executables. Provenzano knows about this, but hasn't tracked it down yet. Sadly, the warning messages trick our autoconf script into thinking this compilation failed, and thus that the requested compilers aren't ANSI-C compliant. To cope with this, we configure to compile with scripts that call the Provenzano scripts and filter out these messages; here's the one for C:
#!/bin/sh -f /usr/local/pthreads/bin/pgcc $* 2>/tmp/$$-cctmp ccstatus=$? fgrep -v "bfd assertion fail /opt/release/pub/bin/binutils/bfd/elf32-i386.c:624" </tmp/$$-cctmp | fgrep -v "bfd assertion fail /opt/release/pub/bin/binutils/bfd/elfcode.h:4716" >&2 rm -f /tmp/$$-cctmp exit $ccstatus
Now that you have configured the release, do the following to build the system. Note
that the capitalization of the arguments to make is important.
% cd ILUSRC
% make
% cd ILUSRC/examples/test1 % make test ../../stubbers/c/c-stubber Test1.isl header file for interface Test1 to ./Test1.h... common code for interface Test1 to ./Test1-common.c... code for surrogate stubs of interface Test1 to ./Test1-surrogate.c... code for true stubs of interface Test1 to ./Test1-true.c... ../../stubbers/c/c-stubber Test2.isl header file for interface Test2 to ./Test2.h... common code for interface Test2 to ./Test2-common.c... code for surrogate stubs of interface Test2 to ./Test2-surrogate.c... code for true stubs of interface Test2 to ./Test2-true.c... ../../stubbers/c/c-stubber Test3.isl header file for interface Test3 to ./Test3.h... common code for interface Test3 to ./Test3-common.c... code for surrogate stubs of interface Test3 to ./Test3-surrogate.c... code for true stubs of interface Test3 to ./Test3-true.c... rm -f clnt.o cc -c -g -I. -I../../runtime/c -I../../runtime/kernel clnt.c rm -f Test1-surrogate.o cc -c -g -I. -I../../runtime/c -I../../runtime/kernel Test1-surrogate.c rm -f Test1-common.o cc -c -g -I. -I../../runtime/c -I../../runtime/kernel Test1-common.c rm -f Test2-surrogate.o cc -c -g -I. -I../../runtime/c -I../../runtime/kernel Test2-surrogate.c rm -f Test2-common.o cc -c -g -I. -I../../runtime/c -I../../runtime/kernel Test2-common.c rm -f Test3-surrogate.o cc -c -g -I. -I../../runtime/c -I../../runtime/kernel Test3-surrogate.c rm -f Test3-common.o cc -c -g -I. -I../../runtime/c -I../../runtime/kernel Test3-common.c rm -f client cc -g -I. -o client clnt.o Test1-surrogate.o Test1-common.o \ Test2-surrogate.o Test2-common.o Test3-surrogate.o Test3-common.o \ ../../runtime/c/libilu-c.a ../../runtime/kernel/libilu.a rm -f srvr.o cc -c -g -I. -I../../runtime/c -I../../runtime/kernel srvr.c rm -f Test1-true.o cc -c -g -I. -I../../runtime/c -I../../runtime/kernel Test1-true.c rm -f Test3-true.o cc -c -g -I. -I../../runtime/c -I../../runtime/kernel Test3-true.c rm -f server cc -g -I. -o server srvr.o Test1-common.o Test1-true.o \ Test2-common.o Test3-common.o Test3-true.o \ ../../runtime/c/libilu-c.a ../../runtime/kernel/libilu.a ./testserver Starting server... Running client against server... Client run successful. Killing server... ./testserver: 27469 Terminated Exiting with status 0. %
% cd ILUSRC % make Install
% make CleanYou may wish to use
make Clean at any time, to get your
system into a consistent state.
make Clean', and redo the installation starting at step 2. If you run
into problems that can be fixed without changing the configuration files, you can re-build
the system by starting at step 3.
ILU tools use a number of UNIX environment variables under the covers. Note three distinct phases when these variables might have significance: (1) when building and installing ILU, (2) when developing an ILU application, and (3) when running an ILU applicaiton.
ILUHOME: there are C preprocessor and make variables of this name, holding the value of ILUHOME. The environment variable of this name is rarely, if ever, significant. The only possibilities are in: phase 2 use of the LISP stubber, phase 3 use of LISP, and phase 3 use of Scheme.
ILUPATH and ILUPATH_NO_ILUHOME are significant to the stubbers and other interface-processing tools, normally used in phase (2). They collectively define a set of directories to be appended to the interface search path given on the relevant tool's command line. If ILUPATH is not defined, `.' and `ILUHOME/interfaces' are appended. If ILUPATH is defined, it should contain a colon-separated list of directories, and they are appended, followed -- unless ILUPATH_NO_ILUHOME is defined (with any value) -- by `ILUHOME/interfaces'.
PATH
environment variable to include the directory `ILUHOME/bin' during phase (2). This makes it possible to invoke ILU development tools (e.g., stubbers, TIM tools) by short names. Most of the ILU development tools can be invoked by their full pathnames, without `ILUHOME/bin' being on your PATH; some of the TIM tools require `ILUHOME/bin' to be on your PATH.
MANPATH variable can have the directory `ILUHOME/man' on it.
SYSDCLPATH to find system descriptions. It should
be a colon-separated list of directories. A good initial value might be
.:${ILUHOME}/lisp. See Appendix A of the reference manual for more details on the portable
DEFSYSTEM.
PYTHONPATH
should include the directory in which the ilu library for
Python has been installed;
that's normally `ILUHOME/lib'.
java
interpreter is on your PATH, and that `ILUHOME/bin' is on
your PATH. The value of the environment variable CLASSPATH should
have `ILUHOME/lib/ilu.jar' on it, or if on Windows,
`ILUHOME/lib/classes' on it. Add the `ILUHOME/lib/ilujavaobv.jar' to the class path, if the program uses the Java object by value feature. The value of the environment
variable LD_LIBRARY_PATH should have `ILUHOME/lib' on it.
LD_LIBRARY_PATH
should include the directory in which the ilu library for Guile has been installed;
that's normally `ILUHOME/lib'. Additionally, the environment variable SCHEME_LOAD_PATH
should contain `ILUHOME/guile', so that the ILU Guile files can be found.
ISLDEBUG can optionally be set to any value to enable tracing
in the ISL parser.
ILU_TYPE_UID_VERBOSE can optionally be set to any value to enable tracing the calculations of type UIDs in the stubbers.
ILU_DEBUG can be optionally be set to a colon-separated list of
trace values to enable tracing in the ILU runtime, and ILU_DEBUG_FILE can optionally be set to a file name pattern for where to write the tracing output. See section Debugging ILU Programs, for more information.
ILU_BINDING_DIRECTORY
to the path of a different directory.
ILU_BINDING_SERVICE to a string of the form "realm-name:host:port". Any of the three fields may be empty, so you could override just the port, for example, by using a value of the form "::2034", which would mean to use the default values for REALM-NAME and HOST, and the value of 2034 for the port.
CORBA::ORB::list_initial_services() during phase (3). If the environment variable ILU_COS_NAMING_IOR is set to the IOR of a CosNaming service, ILU will offer the NameService service, using that IOR to access the service.
ILU_ASSERTION_FAILURE_ACTION, ILU_MEMORY_FAILURE_ACTION, and ILU_CHECK_FAILURE_ACTION to an integer value, which is then used to set the respective ILU kernel failure mode. See `ILUSRC/runtime/kernel/iluxport.h' for the documentation of which integer codes are appropriate for ilu_SetAssertionFailureAction() (note -2 for coredump with message, -1 for loop forever with message, positive value to exit with that value), ilu_SetMemFailureAction() (same as for ilu_SetAssertionFailureAction), and ilu_SetCheckFailureAction() (briefly, -3 to raise the error internally, -2 to coredump with message, -1 to loop forever).
ILUPATH environment variable directly into Python. Automatic enabling of this mechanism can be defeated by setting the environment variable ILU_PYTHON_DISABLE_AUTOIMPORT to any value before loading the ILU module into Python. In addition, setting the variable ILU_PYTHON_IMPORT_VERBOSE will cause the auto-import mechanism to print status messages when loading an interface.
ILU_NO_SUNRPC_UNIX_AUTH to any value. Also with Sun RPC, setting the variable ILU_SUNRPC_PREFERRED_IDENTITY to the name of an identity type will cause an identity of that type to be passed in the request message, if such an identity can be found in the client-side passport.
There are several ways to test the build. The most straightforward is to build and install it somewhere. Set up your environment variables as described above. Then make a scratch directory, which we'll refer to as TESTDIR, and do the following:
% cd TESTDIR
% cp ILUHOME/examples/test1/* .
% ilumkmf
% make client server
ILUHOME/bin/c-stubber Test1.isl
header file for interface Test1 to ./Test1.h...
common code for interface Test1 to ./Test1-common.c...
code for surrogate stubs of interface Test1 to ./Test1-surrogate.c...
code for true stubs of interface Test1 to ./Test1-true.c...
ILUHOME/bin/c-stubber Test2.isl
header file for interface Test2 to ./Test2.h...
common code for interface Test2 to ./Test2-common.c...
code for surrogate stubs of interface Test2 to ./Test2-surrogate.c...
code for true stubs of interface Test2 to ./Test2-true.c...
ILUHOME/bin/c-stubber Test3.isl
header file for interface Test3 to ./Test3.h...
common code for interface Test3 to ./Test3-common.c...
code for surrogate stubs of interface Test3 to ./Test3-surrogate.c...
code for true stubs of interface Test3 to ./Test3-true.c...
rm -f clnt.o
cc -c -g -I. -IILUHOME/include clnt.c
rm -f Test1-surrogate.o
cc -c -g -I. -IILUHOME/include Test1-surrogate.c
rm -f Test1-common.o
cc -c -g -I. -IILUHOME/include Test1-common.c
rm -f Test2-surrogate.o
cc -c -g -I. -IILUHOME/include Test2-surrogate.c
rm -f Test2-common.o
cc -c -g -I. -IILUHOME/include Test2-common.c
rm -f Test3-surrogate.o
cc -c -g -I. -IILUHOME/include Test3-surrogate.c
rm -f Test3-common.o
cc -c -g -I. -IILUHOME/include Test3-common.c
rm -f client
cc -g -o client clnt.o Test1-surrogate.o Test1-common.o \
Test2-surrogate.o Test2-common.o Test3-surrogate.o \
Test3-common.o ILUHOME/lib/libilu-c.a \
ILUHOME/lib/libilu.a
rm -f srvr.o
cc -c -g -I. -IILUHOME/include srvr.c
rm -f Test1-true.o
cc -c -g -I. -IILUHOME/include Test1-true.c
rm -f Test3-true.o
cc -c -g -I. -IILUHOME/include Test3-true.c
rm -f server
cc -g -o server srvr.o Test1-common.o Test1-true.o \
Test2-common.o Test3-common.o Test3-true.o \
ILUHOME/lib/libilu-c.a ILUHOME/lib/libilu.a
% ./server &
[1] 7079
% exported ilu:Test1-Server/Test1_Initial_Object;ilu%3AiX2w6hjR-...
% ./client
Test1.O1.U-CSS-to-U
u._d=5, u._u.boolean = 1, u._u.O1 = 0x1ffee7c
Test1.O1.f-CSS-to-R0
ro->i=9
Test1.O1.R-ScS-to-F
f=39.700001
Test1.O1.a-RO
Test1.O1.get-O2
got O2, sbh = ilu:Test1-SunRPC-Server/1;ilu%3AaUtts57Ywbp2fxe6+-...
Test1.o2.OO-A0-to-CSS
Test1.O2.R-I-A1-to-I-A0
Test1.O1.get-O3
making O3...
got O3, sbh = ilu:Test1-Server/2;ilu%3An+eRrvAZ8JB9v2qoX7sJGPxdX...
Test1.O3.RS-R-to-R-IS
Test1.O3.O1-U-to-U
u._d=3, u._u.boolean = 0, u._u.O1 = 0xd2b78
Test1.O1.get-O3
got O3, sbh = ilu:Test1-Server/3;ilu%3Ab-mNa9uj0TsJAp7YrlEh0AUfX...
Test3.O.RS-R-to-R-IS
Test3.O.O1-U-to-U(0xd7520, {3})
u._d=3, u._u.boolean = 0, u._u.O1 = 0xd2b78
Test3.O.I-to-Test1U(397)
Test3_O_I_to_Test1U: u2._d=5, u2._u.boolean = 1, u2._u.O1 = 0x10a88d0
Test1.O1.get-O3
making O4...
got O3, sbh = ilu:Test1-Server/4;ilu%3Ad8sZGQLLpVsJ2PBL5BoIX45qO...
Test1.O4.R_to_R (12345.6789000000) => 1020304.0506070800
doubles: r1 is 12345.6789000000, r2 is 1020304.0506070800
%
You can proceed to test the various other clients and servers in different languages against each other. See the file `ILUHOME/examples/test1/README' for more information.
From Yongjun Zhang, zhang@quickturn.com: "When using plain xlc on AIX 4.2, when configured with support for OS threads with --enable-os-threads, my images would SEGFAULT. Switching to the xlc_r compiler fixed that."
From hassan@db.stanford.edu: "In order to get ILU 2.0a to compile on HP/UX, I had to set the CC
environment variable to the following before running configure: setenv CC "/bin/cc -Aa +z -D_HPUX_SOURCE"."
From hassan@db.stanford.edu: "Use cc instead of gcc as the C compiler,
and make sure to include the `-taso' switch."
From jg@w3.org: "I built [ILU 2.0 alpha on OSF 3.2B] without the `-taso' switch.
Is this still needed? c-stubber certainly ran without it this release."
Note that the default Sun C compiler is not ANSI C, nor is gcc when
installed against the normal Sun header files and `/lib/libc.a'. You will have to use either
gcc with the GNU C Library glibc, or the SunPro ANSI C compiler acc, or Lucid Energize lcc, or some other ANSI compiler.
On RedHat 5.2 (and perhaps other Linux systems), you will need to have the stdc++-devel RPM
installed to build the CORBA C++ support. If you want to build the Python
support with support for linking Python modules into other programs, you'll want the
development RPM for Python installed.
The following example uses of ILU are provided in the installed tree as subdirectories of `ILUHOME/examples/' (those of any given language are listed roughly in order of increasing complexity/obscurity):
ASYNCHRONOUS methods, a test of pipelining,
and a test of call order preservation (AKA serialization),
and a test of both pipelining and call order preservation.
All are available only in C.
Read the `README' file in each directory first.
No standard "name service" or binding service that works with all ILU objects
is provided (though we do provide an implementation of the CORBA name service
CosNaming). We feel that this is an area
to be addressed independently, and we may include a name service in future releases of ILU.
An experimental simple name service bootstrap interface is available as the simple binding system.
See the ANSI C ILU_C_PublishObject, ILU_C_WithdrawObject, and ILU_C_LookupObject,
and corresponding routines in the other languages, for more details. This interface is intended to
be only sufficient to find the real name service.
Two implementations of this are available, one using an ILU service to store the information, the other using a shared filesystem. They can be selected at configuration time, by specifying either "--with-binding-dir=DIRECTORYNAME", or "--with-binding-service=REALM:HOST:PORT", where REALM may be a user-specified string identifier, that is the name of some conceptual space which the simple binding server serves. These values are compiled into the ILU kernel library, but may be overridden with environment variables at runtime.
An implementation of the CORBA name service, ILUCosNaming, is included. It will by default start
up with the object key of "NameService" for its root context, and listening on port 9999, as
specified in the OMG INS specification. You can only register objects on it which inherit
from the ILU type ilu.CORBA-Object. See the man page for ILUCosNaming for more information.
ILU documentation is provided in a pre-formatted form, PostScript. The source form
of the documentation is called TIM, and is documented in the ILU reference manual.
If for some reason you do need to rebuild the documentation, you should have the systems TeX, Perl, ghostscript, dvips,
and pbmplus; if you can't find these yourself,
please send mail to ilu-core@parc.xerox.com for info on how to find them.
To be added to, or deleted from, any ILU mailing list, please send mail to ilu-request@parc.xerox.com. Do not send mail to the list itself.
The general ILU discussion mailing list is ilu@parc.xerox.com. People post questions, discuss changes, and help each other out on that list. Another list, used only for announcements of ILU things, and consequently much lower-volume, is ilu-interest@parc.xerox.com. The ilu list receives everything that the ilu-interest list receives; there is no need to be on both lists. Again, send mail to ilu-request@parc.xerox.com to be added to or removed from either of these lists.
Archives of these lists can be found at http://www.findmail.com/listsaver/ilu/?archive/.
--disable-corba-cplusplus-support
during the configuration step.
It is written with with a new stubber generator generator, genstub,
which can be found in `ILUSRC/stubbers/genstub/'.
ilu:kernel-server has been changed. If no protocol or transport is specified, the default
protocol and transport will now be used, instead of "sunrpc". The keyword :default-server can
be used to control whether the new kernel-server becomes the default. The keyword :noport
can be used to keep the instantiation from explicitly creating a port. New methods add-port,
native-cinfo, and add-cinfo have been added to the kernel-server type.
Various bugs in the support of pickles with Common Lisp have been fixed.
ILUCosNaming, has been updated
to support OMG's Interoperable Name Service specification. By default, it now starts listening
on port 9999, and the default object key of the root naming context is "NameService".
A bug in ILUCosNaming about re-binding of the same object has been fixed.
The normal ILU string-to-object functions now support both the iioploc and iiopname
URL forms. The INS-specified command-line switches -ORBInitRef and -ORBDefaultInitRef
are now supported by Python, C, and C++.
Java RMI. Also, a new ILU interface exists which allows transport of arbitrary Java serializable objects with ILU. Third, a very experimental DIRECTIVE-EXPERIMENTAL mechanism which optionally allows classes implementing ILU object types to avoid extending org.omg.CORBA.Object (and optionally, extend java.rmi.Remote).
Also, custom mapping may now be specified in the ISL file using the DIRECTIVE-EXPERIMENTAL keyword.
name and value, and the type of the name field is an integer or string type, and the name of the sequence type ends with "dict" or "Dict", the sequence type will be mapped to a Python dictionary instead of to a list. The key value of each item in the dictionary will be the value of the name field of a record value, and the value value of the item will be the value of the corresponding value field of the same record value. This mapping may change in the future.
ilu module will cause a call to ilu.AutoImport(), with no parameters. This can be defeated by setting the environment variable ILU_PYTHON_DISABLE_AUTOIMPORT before loading the ilu module, and ilu.AutoImport can still be called manually at a later time.
w3ng, does so.
rfc822),
and one example of a (non-secure) authentication mechanism (called nil).
Due to U.S. export controls on cryptographic technology, we don't
plan to release publicly any `secure' namespace or authentication mechanisms,
as all of those that we're aware of rely on controlled cryptographic algorithms
to provide that security. We expect that serious users of the GSS will provide
their own namespaces and mechanisms. See `ILUSRC/GSS/README' for more
information on this GSS shell. Note that this release does not provide support for
the ILU gss transport filter.
w3ng. This
is the first wire protocol actually designed for use with ILU. It exhibits
a number of efficiency improvements over existing wire protocols supported
by ILU.
w3ng and IIOP protocols.
PICKLE
no longer automatically interact with the ILU runtime, so the ILU
runtime library for Java no longer needs to be loaded to support non-ILU
use of these types.
ILU_C_CallerIdentity()ILU_C_GetPassportContext()
HTTP support will now properly redirect for responses.
It also responds to non-1.0 versions of the HTTP protocol more
kindly, and has the beginnings of support for HTTP 1.1.
IIOP is available as "siiop";
note that since the OMG spec clearly identifies IIOP as
concurrent (in the ILU sense), "siiop" should only
be used between ILU clients and servers.
"w3mux", allows for multiple simultaneous sessions
or connections over a single TCP/IP connection. It supports message fragmentation
and interleaving of streams. It supports bi-directional connections over
the TCP/IP connection, thereby supporting callbacks through firewalls.
portmapper is now included,
in `ILUSRC/etc/portmapper/'. Included is an ILU ISL
description of the portmapper interface, which can be used directly with other
languages.
import
mechanism in Python can now be augmented by calling the function ilu.AutoImport()import so that, when
attempting to import a module called foo, if it fails to find `foo.py'
and `foo.pyc' on the PYTHONPATH environment variable, it will then
walk down the directories listed in the ILUPATH environment variable, looking
for either `foo.isl', or, if OMG IDL support is enabled, `foo.idl'.
If either of these are found, it will run the Python stubber on the file,
putting the results in a temporary directory, and then load the resulting surrogate-side
`foo.py' file.
ILU_C_Object *) are now reference counted. An application must be careful
to use CORBA_Object_duplicate and CORBA_Object_release correctly to
avoid memory smashes.
--enable-pickle-support and --enable-corba-iiop have been selected,
full type information on all compiled-in or dynamically-loaded ISL
types is now cached in memory. This makes it theoretically possible for someone
to write a CORBA Interface Repository service for ILU (or something
more useful). Note changes in ilu_DefineMethod, ilu_DefineException,
and the new function ilu_DefineMethodArg.
HTTP protocol may now
be selected with the string "http_1_0p", which causes it to send
Connection: "Keep-Alive" headers, and not close the connection between calls
(assuming of course that the other end of the connection also supports this
behavior - fairly common.) The programs in examples/httest have been updated
accordingly. In addition, it is now possible to use HTTP over
a boundaried transport.
idl2isl
compiler now, for an OMG IDL exception E, generates an
ISL exception called E, and an ISL type called
ilu--prefix-idlExceptionType-E. The stubbers handle this type variously;
the C stubber renames it to E, as required by the CORBA
spec; the Python stubber renames it to E__omgidl_exctype;
the Lisp stubber folds it into the definition of the condition
E, and doesn't support the type directly at all.
iluMainLoop class in the old
C++ runtime.
Sun RPC can be created.
idl2isl
is now part of the Windows build.
PICKLE, to pass arbitrary typed values across interfaces. Pickle support is implemented in such a fashion as to be interoperable with CORBA any, and our OMG IDL to ISL translator in fact maps any directly to PICKLE.
HTTP, version 1.0, between address spaces. This makes ILU programs Web servers and clients, though only in a very limited sense. See the `Protocols and Transports' chapter of the user manual for more information.
ilusbls. A program, ilusbls, that will list the objects known to the simple binding service, is provided. ilusbls will work with either the shared files simple binding or the ILU service simple binding.
ilu_IdentityInfo.
--enable-os-threads, and your Python installation has been built with thread support, thread support will also be available in the Python ILU runtime. A new Python function, ilu.ThreadedOperation(), has been added to enable use of threads.
This release contains some major changes, and is NOT compatible "on the wire" with any previous version of ILU. There are also a few API changes. There may be further changes in 2.0beta and 2.0.
8) Generalized cleanup and bug fixing. This includes more attention to making it practical for others to add transport and protocol meta-objects. This also includes a more rigorous treatment of exceptions in the kernel and runtimes, with a taxonomy of exceptions aligned with CORBA's. It also includes fixes that change the type ID's and protocol mappings, which caused us to bump the major version number. All ONC RPC and Courier program numbers, and ISO object IDs are now official. The Courier type-ID-to-program-number mapping registry has been eliminated.
This means that if you wish to use ILU 1.6.4 clients or servers with ILU 1.7, you should edit the 1.6.4 SunRPCRegistry file to use the 1.7 program number and version for each particular object type.
This also means that the ILU on-the-wire mapping for objects has been changed (slightly) to allow for NIL object references. Applications that do not use NIL objects will not encounter this change.
KNOWN BUGS:
Release 2.0beta1:
Release 2.0alpha10:
Release 2.0alpha9:
Report bugs (nah! -- couldn't be!) to the Internet address ilu-bugs.parc@xerox.com,
or to the XNS address ILU-bugs:PARC:Xerox. Bug reports are more helpful with
some information about the activity; please read section Debugging ILU Programs,
for more information on how to look at problems. General comments and suggestions can
be sent to either ILU@parc.xerox.com or ILU-bugs.
Go to the previous, next section.