Building and Installing TAO

The following table summarizes platforms on which TAO runs:

Fully supported, i.e., continually tested and used daily	Solaris 2.5, 2.6, 7, and 8, Windows NT/2000 (MSVC 5.x, 6.x, and 7.x and Borland C++ Builder 5), Linux/Intel, Linux/Alpha, VxWorks, LynxOS, Digital UNIX 4.0 and 5.0, IRIX 6.x, and QNX Neutrino 2.0
Nearly fully supported, i.e., periodically tested	Windows 9x/ME, HP/UX 10.x and 11.x, AIX 4.x
Partially supported, i.e., infrequently tested	FreeBSD, NetBSD, SunOS 4.x, Chorus
Planned support, i.e., pending	pSoS, MVS, Windows CE, Tandem, SCO, UnixWare

Any UNIX/POSIX/Win32 variation is a potential target platform for ACE. If you have porting questions or have a problem compiling the ACE wrappers on the platforms shown above please send email to either ACE Newsgroup or the ACE mailing list and we'll try to help you fix the problems. You can also submit bug reports and enhancement requests in our bug tracking system.

TAO can be obtained electronically via the WWW and ftp. ACE is bundled with the TAO release. You'll always need the most recent version of ACE because TAO tracks changes to ACE very closely.

On UNIX platforms

1. Set ACE_ROOT environment variable as outlined in the ACE installation notes.

2. Build and install ACE under $ACE_ROOT.
   • Change directory to $ACE_ROOT/ace and execute make.

   • Also build GPERF under $ACE_ROOT/apps/gperf

3. Set TAO_ROOT environment variable to $ACE_ROOT/TAO.

4. Build and install the TAO release under $TAO_ROOT.

   The easiest and recommended way to compile the complete TAO distribution by simply simply executing make in the $TAO_ROOT directory.

   A smaller subset, that may be of interest to test basic TAO functionality, is: $TAO_ROOT/tao, $TAO_ROOT/TAO_IDL, $TAO_ROOT/tests/Param_Test. Then you can execute the run_test.pl script in $TAO_ROOT/tests/Param_Test and/or follow the instructions contained in the README file in the same directory.

   If you wish to compile the services distributed with TAO, including the Naming_Service you must include $TAO_ROOT/orbsvcs to the list above.

5. To test that the TAO release is properly configured, follow instructions on executing the various examples under $TAO_ROOT/tests.

A Note On Make

GNU Make can be obtained from various places in source form.

For Cross-Compiled Targets, such as VxWorks and LynxOS

Cross-compiling TAO is not much different than building it for self-host. The one major difference is that TAO's IDL compiler must be built and run on the host; it's not necessary to run it on the target. There are several ways to do this, below we document the two most common approaches:

Modifying the default location for the IDL compiler

By default TAO assumes that the IDL compiler is located in: $TAO_ROOT/TAO_IDL/tao_idl and that the GPERF tool is located in $ACE_ROOT/bin/gperf, this is fine for hosted builds, but not for cross-compilation. Unfortunately there is no good default for cross-compilation builds because different sites choose a different location for their tools.

You can override the default values by adding two lines in your platform_macros.GNU file, as follows:

$ echo 'TAO_IDL := /your/path/tao_idl' \
     >> platform_macros.GNU
$ echo 'TAO_IDLFLAGS := -g /your/path/gperf' \

You could even use:

$ echo 'TAO_IDL := tao_idl' \
     >> platform_macros.GNU
$ echo 'TAO_IDLFLAGS := -g gperf' \

Obviously you must first build the tools for the host platform, typically you would do this as follows:

# (1) Create a clone directory for the host:

$ cd ACE_wrappers
$ mkdir -p build/HOST
$ ./bin/create_ace_build build/HOST

# (2) Configure the host build:

$ echo '#include "ace/config-HOST.h"' > build/HOST/ace/config.h
$ echo 'include $(ACE_ROOT)/include/makeinclude/platform_HOST.GNU' \
     > build/HOST/include/makeinclude/platform_macros.GNU

# Often host builds are static:
$ echo 'static_libs_only=1' \
     >> build/HOST/include/makeinclude/platform_macros.GNU

# (3) Build the host tools

$ cd build/HOST
$ export ACE_ROOT=$PWD
$ make -C ace
$ make -C apps/gperf
$ make -C TAO/TAO_IDL

Then configuring the location of the tools for the target could be done as shown here:

# (4) Create a clone directory for the target:

$ cd ACE_wrappers
$ mkdir -p build/TARGET
$ ./bin/create_ace_build build/TARGET

# (5) Configure the target build:

$ echo '#include "ace/config-TARGET.h"' > build/HOST/ace/config.h
$ echo 'include $(ACE_ROOT)/include/makeinclude/platform_TARGET.GNU' \
     > build/TARGET/include/makeinclude/platform_macros.GNU

# (6) Configure the TARGET build to use the HOST IDL compiler and
#     gperf tools, as described above.

Alternative configuration, using links

Some developers prefer to set up the host tools using symbolic links (Unix) or copy of tao_idl (NT). By way of example, here is how you could setup a croos-compilation environment for Unix, the host is SunOS5/g++, the target is VxWorks. It assumes that the ACE+TAO distribution has been unpacked, with TAO below ACE_wrappers. It uses the ACE_wrappers/bin/create_ace_build script to create a shadow build tree:

1. cd ACE_wrappers
2. bin/create_ace_build SunOS5_g++
3. bin/create_ace_build vxworks
4. cd build/vxworks/TAO
5. /bin/rm -r TAO_IDL
6. ln -s ../../SunOS5_g++/TAO/TAO_IDL

To build on the host:

1. cd build/SunOS5_g++
2. export ACE_ROOT=`pwd`; export LD_LIBRARY_PATH=`pwd`/ace:$LD_LIBRARY_PATH
3. (cd ace; make && cd ../tests; make && cd ../TAO; make) > make.log
4. cd ../vxworks
5. export ACE_ROOT=`pwd`
6. (cd ace; make && cd ../tests; make && cd ../TAO; make) > make.log

For NT hosts, please see the detailed instructions for building and installing ACE and TAO in ../ACE-INSTALL.html, and Building ACE on Tornado/NT hosts for VxWorks targets

Please note that dynamic loading of libraries is not supported by TAO for any cross-compiled target. Therefore, dynamic service configuration of the TAO ORB is not supported.

If using perfect hashing, TAO_IDL needs gperf to be built on the host. That's the default on many platforms. First, build gperf in the ACE_wrappers/apps/gperf/src/ directory. Then, add a symlink or copy to the bin/ directory for the target.

Which one is right for me?

Using links to cross-compile TAO may appear simpler at first glance. However, storing the location in the platform_macros.GNU is more amenable for sites where many developers share the same configuration files, or where ACE+TAO are compiled once and used by a medium or large size group.

On Windows NT and Windows 2000

TAO_IDL does not contain its own preprocessor, so it needs to use an external preprocessor. Depending on which compiler was used to build TAO_IDL, the default preprocessor will change. For example, if compiled with MSVC, TAO_IDL will look for CL.EXE in the path. There are cases where this will not work, such as in cross-compiling or if the preprocessor is not in the path. These situations require that environment variables are set on the machine to override the built-in settings. More information about these environment variables can be found in the TAO_IDL documentation.

It is also advisable to set either the ACE_ROOT environment variable as outlined in the ACE installation notes or the TAO_ROOT environment variable. This is only required if you are planning to use the <orb.idl> standard include in your IDL code. Notice that some of the TAO services use this feature, so you are better off definining the environment variable in all cases.

Visual C++ 5.0/6.0

It works best if TAO is placed in ACE_wrappers so TAO ends up in ACE_wrappers\TAO because the Visual C++ 5/6 Project files are set up to work in this configuration. If you move it, then make sure you change the project files to look for the include and library files in the correct place.

1. Make sure ACE is built (For Visual C++ 5.0/6.0, use ace.dsw).

2. First make sure ACE_wrappers\bin is listed in the Executable Directories in Tools|Options. This is needed if using the TAO_IDL compiler under MSVC. If you intend to also use the release version of the libraries, also add ACE_wrappers\bin\Release to the directories. Note: The order that these are listed is important. If your main development is with the debug versions, make sure \bin is before \bin\Release, otherwise put the \bin\Release first. Because the output names for the release and debug versions of TAO_IDL are the same, extra care must be taken when both versions are generated simulataneously.

3. Load the workspace tao\TAO.dsw and build the TAO library.

4. To build the Cubit test, load the workspace performance-tests\Cubit\TAO\IDL_Cubit\IDL_Cubit.dsw and build both client and server.

TAOACE.dsw and other collection dsw files

TAOACE.dsw is a Visual C++ 5.0/6.0 workspace that loads the projects ACE, TAO, TAO_IDL (the compiler), gperf, the orb services libraries, and the standalone executables (such as Naming Service, etc.). It can be used to build all the files needed to build/run TAO applications.

Borland C++ Builder

To build TAO using C++Builder please follow the ACE installation notes, with the difference being that you should run:

make -f Makefile.bor

from the ACE_ROOT\TAO directory instead of ACE_ROOT\ace.

For more detailed information on building and using TAO with Borland's C++ Builder environment, please see the online help provided by Christopher Kohlhoff.

Upgrading From Older Releases

When a newer version of ACE/TAO is installed, rebuild all should be used to make sure everything is built correctly.

Changing Include Paths

If you prefer #include <corba.h> over #include <tao/corba.h> then you will need to change your Project Settings to also contain the TAO/tao directory. You'll find this in the C/C++ settings under Input.

Creating Static Libraries (*.lib)

TAO, orbsvcs, TAO_IDL, and the Simple Test all have extra project files for static library builds. TAOACE_static.dsw contains some of these projects, and is set up much like TAOACE.dsw, except that there are not as many static projects as their are dynamic projects and their isn't the same dependencies set up.

To use the static libraries in a project, make sure to the following settings are used in the Project Settings.

• C/C++ | General: Add the Preprocessor Definitions ACE_HAS_DLL=0, ACE_OS_HAS_DLL=0 and whatever other libraries that are included (such as TAO_HAS_DLL=0)
• Link: Link with the static libs, such as TAOs.lib or TAOsd.lib

How to add IDL files into your Visual C++ projects

Each IDL file generates .h, .i and .cpp files. Here is an example of adding an IDL file named foobar.idl into a VC project.

1. Create/open the workspace. In addition to creating server project and client project, create a separate "Utility Project" call foobar_idl for compiling the shared IDL file. Add the IDL file <foobar.idl> to foobar_idl project and other non-IDL generated files into both client and server projects.
2. Added foobarC.h, foobarC.i, foobarC.cpp, foobarS.h, foobarS.i, and foobarS.cpp into server project and foobarC.h, foobarC.i, foobarC.cpp into client projects.
3. Now open the project setting window of foobar_idl (Project -> Setting... or just press Alt-F7.) Select the IDL file in the projects. Choose to set the setting for "All Configuration." Make sure the "Always use custom build step" is checked and "Exclude from build" is unchecked.
4. Click on the "Custom Build" tab. Add this entry as the build command for IDL files:
   
   

   tao_idl $(InputPath) -o $(InputDir) -I $(InputDir)

   Notice that your absolute path to TAO_IDL may vary.
5. Now add the following entries as "Output file(s)."
   
   

         $(InputDir)\$(InputName)S.h
         $(InputDir)\$(InputName)C.h
         $(InputDir)\$(InputName)C.i
         $(InputDir)\$(InputName)C.cpp
         $(InputDir)\$(InputName)S.i
         $(InputDir)\$(InputName)S.cpp
         $(InputDir)\$(InputName)S_T.h
         $(InputDir)\$(InputName)S_T.i
         $(InputDir)\$(InputName)S_T.cpp
         

   Add only one entry in each line.
6. You might also want to add the TAO_IDL compiler in as a dependency here if you update TAO often. That way, if the compiler is changed, the IDL files are recompiled automatically in the next build.
7. We are all set. Click OK.
8. Add foobarC.cpp and foobarS.cpp to the server project and foobarC.cpp into the client project.
9. Make both client and server projects dependent projects of foobar_idl project to make sure the IDL file get compiled before client and server projects.

Notice that these procedures only setup the IDL compiler to perform correctly.

P.S. If anyone knows how to set a default setting in VC so we don't need to perform these procedures every time a new project gets set up, please let us know. Thanks.

Perl Scripts

Several of TAO's tests and examples contain perl scripts that automate the execution of these tests. The scripts are found as "run_test.pl" in the directory of the test.

The versions of perl that we use are 5.005_02 on NT and 5.003 on Solaris. The scripts may work on earlier versions of perl, but we cannot say for sure that they do.

Native Exceptions

TAO will use native exceptions if TAO_HAS_EXCEPTIONS is defined when it is compiled. This can be accomplished in two ways: by defining ACE_HAS_EXCEPTIONS in the config.h or config-*.h files (such as on Windows) or by using make exceptions=1 when you compile TAO.

Take note though, that this only enables support in ACE/TAO, the correct compiler flags must also be given to the compiler to enable them.

minimumTAO

By default, all components in TAO will be compiled. If you only want support for minimumTAO, define TAO_HAS_MINIMUM_CORBA. This can be accomplished in two ways: by defining TAO_HAS_MINIMUM_CORBA in the config.h or orbconf.h files or by using make minimum_corba=1 when you compile TAO.

Connection Caching feature

By default, TAO includes the connection caching and purging feature which reuses "old" connections by purging them according to the caching strategy opted for (Least Recently Used, Least Frequently Used, First In First Out). This way socket descriptors are reused thereby increasing scalability.

This feature can be controlled by defining or commenting out TAO_USES_ROBUST_CONNECTION_MGMT in $TAO_ROOT/tao/orbconf.h.

But the code related to this feature consists of classes with large template lists and can cause problems with linkers and assemblers which cant grok long names.

Tips:

Check on SunOS5.6 (and above) whether the assembler used is of the Sun Workshop 5 version else you could get linker errors due to huge symbols.

If using egcs2.95 as the compiler the -fsquangle option could be used which shortens the symbol names. Thanks to Skye Sweeney for trying it out and Ossama Othman for discovering the option with egcs. Note: Both the ACE library and TAO library need to built using this option.

System Resource Requirements

Back to the TAO home page.