Installation Notes for the ADAPTIVE Communication Environment (ACE)

Synopsis

The file explains how to build ACE on the various UNIX and Win32 platforms that it has been ported to. Please make sure you read the ACE FAQ before installing ACE. In addition, please consult the ChangeLog file to see whether any recent changes to the release will affect your code.

Document Index


Supported Platforms and Compilers

The ADAPTIVE Communication Environment has been ported and tested extensively on a wide range of C++ compilers and OS platforms. If you have a problem compiling the ACE wrappers on the platforms shown below please let me know and I'll try to fix it for you.
Win32 (Windows NT and Windows '95)

All of ACE has been ported to the Win32 API (which includes Windows NT and Windows '95). The entire release now compiles using the Microsoft Visual C++ 4.0 compiler (the 2.0 compiler should also work, but I haven't tested it recently). ACE can be built as both a static and dynamic library, using the Win32 installation process described below.

Sun OS 5.x/4.x (a.k.a. Solaris 2.x/1.x) using Sun CC 3.0.1, Sun C++ 4.0.x, Centerline C++ 2.x, and GNU gcc 2.7.x.

All the source code and tests should build and run without any problems on the Solaris and SunOS platforms using the Sun C++ compilers.

Sun OS 4.1.x using Centerline C++ 2.x, Sun CC 3.x, and Lucid Energize 3.2.

Note that shared libraries do not interact very well with Centerline C++ or Sun C++ on SunOS 4.1.x. This is due to odd behavior of the SunOS 4.1.x linker, which (1) does not properly call constructors of global objects within shared libraries and (2) does not call the init() and fini() functions in shared libraries, even though the manual claims that these functions are called! In particular, this means that the tests in the directory $(WRAPPER_ROOT)/tests/Service_Configurator/IPC-tests/server/ will not work for statically linked services...

Some versions of SunOS 4.1.x do not contain the /usr/lib/libnsl.a library. This library seems to be optional since System V Transport Layer Interface (TLI) support is optional on SunOS 4.1.x (in contrast, it's the "preferred" transport interface on Solaris).

The best work-around for now is probably to either add a dummy libnsl.a in /lib (which may not be feasible) or simply comment out the line:

LIBS += -lnsl

in the $WRAPPER_ROOT/include/makeinclude/wrapper_macros.GNU file. Naturally, any programs (e.g., the TLI_SAP tests) that use the TLI wrappers aren't going to work!

Note that on SunOS 4.x you may get warnings from the linker that "archive has no table of contents; add one using ranlib(1)" for certain libraries (e.g., libASX.a, libThreads.a, and libSPIPE.a). This occurs since SunOS 4.x does not support these features.

AIX

The ACE port to AIX assumes that the user has installed the AIX patch containing the dl*() APIs. To use these APIs, IBM has created a separate product (free to AIX licensees) called shared library hookable symbols (or slhs/6000). If you don't have this patch, the sv* commands for compiling and linking will not be present on the system.

Linux and SCO 4.2

ACE has been ported to Linux and SCO UNIX using the GNU G++ 2.7.2 compiler.

SGI IRIX 5.x

ACE builds fine using the SGI C++ and GNU GCC compilers for IRIX 5.x. I haven't tried this on IRIX 6.x, but I assume that will work too. If anyone can get ACE working with IRIX 6.x pthreads please let me know.

HP-UX 9.x and 10.x

The current HP/UX C++ compiler is incredibly lame and has problems compiling ACE templates and achieving template closure. I've heard that the next release is better... In the meantime, you might try using GNU GCC or SunC++ on HP/UX.

OSF/1 3.2 and 4.0 (a.k.a. Digital UNIX 4.0a)

The current OSF/1 C++ 5.4 compiler still seems to have problems with ACE's templates. It compiles the lib and test programs, although giving warnings about template usage. Most tests run, some dump core. Hopefully newer compiler releases will alleviate these problems.

GNU gcc 2.7.2.1 compiles without problems. All tests run (besides minor problems). Thanks to Thilo Kielmann < kielmann@informatik.uni-siegen.de> and David Trumble <trumble@cvg.enet.dec.com> for help with this port.

UnixWare 2.01

Steve Huston <shuston@ultranet.com> has ported ACE to work with UnixWare 2.01 and its standard C++ compiler.
VxWorks

David Levine <levine@cs.wustl.edu> has ported ACE to VxWorks 5.2 using the GreenHills 1.8.7 compiler.
MVS

Chuck Gehr <gehr@sweng.stortek.com> has ported ACE to IBM MVS.

Compiling ACE with GNU C++

If you use the GNU GCC C++ compiler please note the following:


Installation Process for UNIX

The installation process for installing ACE on UNIX is relatively simple (the Windows NT installation process is different). Here's what you need to do:

  1. Install GNU make 3.7 or greater on your system (available via anonymous ftp from prep.ai.mit.edu in the pub/gnu directory).

  2. Add an environment variable called WRAPPER_ROOT that contains the name of the root of the directory where you keep the ACE wrapper source tree. For example, in my .login file I have the following entry:

    
    % setenv WRAPPER_ROOT /home/cs/faculty/schmidt/ACE_wrappers 

    The ACE recursive Makefile system needs this information.

  3. Edit the $WRAPPER_ROOT/ace/OS.h file to update things like default hostname and port numbers you'd like the programs in the $WRAPPER_ROOT/{apps,tests} directories to use by default.

  4. Set the $WRAPPER_ROOT/ace/config.h file to point to the appropriate platform/compiler-specific header configurations (such as config-sunos5-sunc++-4.x.h). This file contains the #defines that are used throughout ACE to indicate which features your system supports (see the $WRAPPER_ROOT/ace/OS.h file for many examples of how the ACE build configuration is affected by these macro settings).

    There are config files for most versions of UNIX. If there isn't a version of this file that matches your platform/compiler, you'll need to make one. Please send me email if you get it working so I can add it to the master ACE release.

  5. Set the $WRAPPER_ROOT/include/makeinclude/platform_macros.GNU file to point to the appropriate platform/compiler-specific Makefile configurations (e.g., platform_sunos5_sunc++.GNU). This file contains the compiler and Makefile directives that are platform/compiler-specific

  6. Note that since ACE builds shared libraries, you'll need to set LD_LIBRARY_PATH to whereever you put the binary version of the libraries. For example, you probably want to do somethink like the following

    
    % setenv LD_LIBRARY_PATH $WRAPPER_ROOT/ace:$LD_LIBRARY_PATH 

  7. When all this is done, hopefully all you'll need to do is type:

    
    % make 

    at the root of the ACE source tree. This will build the static and shared object libraries and build the tests and the sample applications.


Installation Process for Windows NT and Windows '95 Static and Dynamic Libraries

The installation process for NT is a bit different than UNIX. First, I assume you're using MSVC++ 4.0(things are a little different for the 2.0 version...).


Advanced Topics

Cloning the Source Tree

On UNIX platforms, I typically like to support multiple platform builds using the same ACE source tree. This idiom is supported by ACE using the $(WRAPPER_ROOT)/bin/clone.c program. To build clone, perform the following steps:

% cd $WRAPPER_ROOT/bin 
% make 
% mv clone ~/bin 
% rehash

Then create a ./build subdirectory someplace (e.g., under $WRAPPER_ROOT), and then invoke the top-level Makefile with the "clone" target, e.g.:

% cd $WRAPPER_ROOT 
% mkdir build-SunOS5
% cd build-SunOS5 
% make -f ../Makefile clone 
% setenv WRAPPER_ROOT $cwd 
% make

This will establish a complete tree of links. When you do a make in this directory you will be producing object code that is not stored in the same place as the original source tree. This way, you can easily build another platform in a parallel tree structure.

VERY IMPORTANT!

If you use the "clone trick" discussed above, make sure that the symbolic links are correctly in place before starting the build. In particular, if you plan to clone the tree, it is preferable to do so before you start a build procedure on the original tree. This is because the build procedure create object directories (.obj and .shobj) and the cloning procedure will clone these directories also. You would end up with links pointing to object files of another platform. If you clone the tree after you've done a build on the original tree, make sure to remove all ".obj", ".shobj" and (any other files or directories) in all subdirectories before starting the build on your cloned tree.


Building CORBA Versions of ACE

Note that if you are compiling with IONA's Orbix implementation of CORBA or Visigenix's implementation of CORBA, you'll also need to set ORBIX_ROOT to point to the root of the Orbix source tree and ORBELINE_ROOT to point to the root of the ORBeline source tree. Since many platforms don't have these CORBA tools the default for ACE does *not* incorporate them. Thus, if you are compiling with Orbix or ORBeline, make sure that you set the symbolic links for $WRAPPER_ROOT/include/makeinclude/platform_macros.GNU and $WRAPPER_ROOT/ace/config.h to point to the the config* and platform* files that have "-orbix" in them!


Back to the ACE home page.