http://www.dre.vanderbilt.edu/~schmidt/PDF/Svc-Conf.pdf Building and Installing ACE and Its Auxiliary Libraries and Services

Building and Installing ACE and Its Auxiliary Libraries and Services

Synopsis

The file explains how to build and install ACE, its Network Services, test suite and examples on the various OS platforms and compilers that it has been ported to. Please consult the NEWS and ChangeLog files to see whether any recent changes to the release will affect your code. In addition, you should check out our development process. As you start working with ACE, we suggest you get copies of the C++NPv1, C++NPv2, and APG books to help guide you after you've built and installed ACE. You should also consult the ACE Frequently Made Mistakes page. If you encounter any problems or would like to request an enhancement, then use our bug tracking system to submit a report in accordance with our bug report process.

Document Index

Platforms, C++ Compilers, and Support

ACE has been ported to a large number of platforms using many different compilers over the years. The DOC group, Riverace, OCI, Remedy IT, and members of the ACE user community have all contributed ports to make ACE the successful and far-reaching toolkit it is today. Any UNIX/POSIX/Windows variation is probably an easy target platform for ACE. If you have porting questions or have a problem compiling the ACE source distribution, please contact one of the commercial support companies, or send a copy of the PROBLEM-REPORT-FORM, located in the ACE_wrappers directory, to either the ACE Newsgroup or the ace-users mailing list. The DOC groups at Washington University, UC Irvine, and Vanderbilt University provide only "best effort" support for non-sponsors for the latest release, as described in docs/ACE-bug-process.html. Thus, if you need more "predictable" help, or help with earlier versions of ACE, it's recommend that you check out the list of commercial support companies for additional assistance.

The responsibility for maintaining ACE across the wide range of supported platforms is divided among a few different groups:

The build scoreboard records the current status of build and regression testing during development by all of the above groups. It is available to all users wishing to provide build results. Members of the ACE community that maintain ACE on platforms not maintained by the DOC group, Riverace, OCI, or Remedy IT are encouraged to provide build and regression test results for the scoreboard to ensure that all in-use platforms are represented. See the autobuild README for more information about how to set up a build; contact one of the above groups to inquire about how to get your build results recorded on the scoreboard.

Because older platforms that are not maintained tend to fall into a broken state and clutter the ACE sources with code that is no longer used, the development team reserves the right to remove ACE configuration files and source code specific to inactive platform configurations that are not listed on the scoreboard.

The table below summarizes each group's role and where you can get more detailed information. For information on TAO's platform coverage and support, please also see TAO's install document.

Groups Involved in ACE Development and Support
Group Platforms For more information
DOC Group Windows 2000, XP (MSVC++ 7.1, 8, 9, and 10); many versions of Linux/Intel (many compilers). DOC sites at ISIS, UCI and Washington University
Riverace Offers ACE training, support and consulting services for many platforms including AIX, HP-UX, Linux, Solaris, and Windows. Riverace's ACE Support page.
OCI Maintains ACE on certain platforms required for their TAO software and service offerings. OCI's web site, TAO page, and the TAO install document
Remedy IT Maintains ACE on many platforms required for their ACE and TAO service offerings. We support AIX, CodeGear C++ Builder 2007/2009, CodeGear RAD Studio 2007, Embarcadero C++ Builder 2010/XE, Windows CE, MinGW, Microsoft Visual C++ 7.1/8/9/10, GCC, Cygwin, VxWorks 6.x (kernel and rtp), OpenVMS 8.3 on IA64, BlueCAT Linux, RedHat Linux, Fedora, MacOSX, Solaris, Tru64, SuSE Linux on Alpha/IA32/EM64T/IA64, RTEMS, QNX, LynxOS, HPUX 11i v2/v3 on IA64, and Android (android-9). The Intel C++ compiler is supported on Windows 32/64bit, Linux IA32/EM64T/IA64, MacOSX. Remedy IT web site and the TAO install document
PrismTech Maintains ACE on certain platforms required for their TAO software and service offerings, including LynxOS. PrismTech's web site
ACE user community Responsible for continued maintenance and testing of platforms to which ACE has been ported, but aren't supported by the above groups. These include Digital UNIX (Compaq Tru64) 4.0 and 5.0; IRIX 6.x; UnixWare 7.1.0; Linux on PPC; OpenMVS; Tandem; SCO; FreeBSD; NetBSD; OpenBSD; Macintosh OS X; OS/9; PharLap ETS 13; QNX RTP and Neutrino 2.0; Interix (Windows Services for Unix)
Not maintained The following platforms have been ported to in the past but are no longer maintained and may be removed from ACE at any time. If you want to have support for these environments contact one of the commercial support organisations. The platforms include: Chorus; DG/UX; HP-UX 9, 10 and 11.00; pSOS; SunOS 4.x and Solaris with SunC++ 4.x; VxWorks 5.4 and earlier; Microsoft Visual C++ 5, 6, and 7.0; Borland C++ Builder 4, 5, 6, and 2006. For up-to-date listings on platform that are deprecated and pending removal from ACE, please see the NEWS file.

Although the DOC group has provided outstanding support for ACE over the years, ACE's success has greatly increased the amount of effort required to keep up with its maintenance, answer users' questions, and give design guidance. Riverace offers world-class commercial services to support ACE users. OCI, PrismTech, and Remedy offer similar services for TAO, allowing the DOC group's primary focus to shift back to their main goal: research. The DOC group is fundamentally focused on (and funded by) advanced R&D projects. The group continues to be intimately involved in ACE+TAO development and maintenance, but with revised priorities for maintenance. The bug fixing policies followed by the DOC group are designed to strike a balance between their many research projects and their commitment to the ACE+TAO user community. Naturally, we will be happy to accept well-tested patches from the ACE+TAO user community for any platforms that aren't supported by the DOC group, Riverace, OCI or Remedy IT.

Installation prerequisites

ACE (as well as TAO and CIAO) use MPC (MakeProjectCreator) to generate files used by all supported build tools (such as GNUmakefiles for UNIX based platforms, sln and vcproj files for VC71/VC8 and Embarcadero makefiles) on various platforms. To help new users to bootstrap quickly the release bundles of ACE (as well as TAO and CIAO) include all needed files to use the build instructions in this document.

If it is necessary to generate files for build tools for other compilers, one must run MPC to generate the appropriate files. Please see USAGE, README, and README for ACE files for details. The options that have been used to generate the above build files can be found in global.features file.

Building and Installing ACE

The following sections explain how to build ACE on:

General Rules

Building and Installing ACE on UNIX

As of ACE 6.0.6, you can building ACE on UNIX with:
  1. Traditional ACE/GNU Make Configuration
The build process for Windows is different from the UNIX methods.

Using the Traditional ACE/GNU Configuration

Here's what you need to do to build ACE using GNU Make and ACE's traditional per-platform configuration method:

  1. Install GNU make 3.79.1 or greater on your system (available via http anonymous ftp from ftp.gnu.org in the pub/gnu/make/ directory). You must use GNU make when using ACE's traditional per-platform configuration method or ACE won't compile.
  2. Add an environment variable called ACE_ROOT that contains the name of the root of the directory where you keep the ACE wrapper source tree. The ACE recursive Makefile scheme needs this information. There are several ways to set the ACE_ROOT variable. For example:
    TSCH/CSH: setenv ACE_ROOT /home/cs/faculty/schmidt/ACE_wrappers
    BASH or Bourne Shell: ACE_ROOT=/home/cs/faculty/schmidt/ACE_wrappers; export ACE_ROOT

    If you're building a number of versions of ACE, however, (e.g., for different OS platforms or for different releases of ACE) you might use the following approach (assuming TCSH/CSH):

    setenv ACE_ROOT $cwd
  3. Create a configuration file, $ACE_ROOT/ace/config.h, that includes the appropriate platform/compiler-specific header configurations from the ACE source directory. For example:
    #include "ace/config-linux.h"
    The platform/compiler-specific configuration file contains the #defines that are used throughout ACE to indicate which features your system supports. See the $ACE_ROOT/ace/README file for a description of these macro settings. If you desire to add some site-specific or build-specific changes, you can add them to your config.h file; place them before the inclusion of the platform-specific header file.

    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 email to the ace-users list if you get it working so it can be added to the master ACE release.

  4. Create a build configuration file, $ACE_ROOT/include/makeinclude/platform_macros.GNU, that contains the appropriate platform/compiler-specific Makefile configurations, e.g.,
    include $(ACE_ROOT)/include/makeinclude/platform_linux.GNU
    This file contains the compiler and Makefile directives that are platform/compiler-specific. If you'd like to add make options, you can add them before including the platform-specific configuration.

    NOTE! There really is not a # character before 'include' in the platform_macros.GNU file. # is a comment character.

  5. If you wish to install ACE (using "make install"), set the installation prefix in platform_macros.GNU.
    INSTALL_PREFIX = /usr/local
    Headers will be installed to $INSTALL_PREFIX/include, executables to $INSTALL_PREFIX/bin, documentation and build system files to $INSTALL_PREFIX/share and libraries to $INSTALL_PREFIX/lib. The library directory can be customized by setting INSTALL_LIB (for example, INSTALL_LIB=lib64). With INSTALL_PREFIX set, RPATH will be enabled for all executables and shared libraries. To disable RPATH (for example, if $INSTALL_PREFIX/$INSTALL_LIB is already a system-known location for shared libraries such as those listed in /etc/ld.so.conf), set the make macro install_rpath to 0 by adding install_rpath=0 to platform_macros.GNU.
  6. Note that because ACE builds shared libraries, you'll need to set LD_LIBRARY_PATH (or equivalent for your platform) to the directory where binary version of the ACE library is built into. For example, you probably want to do something like the following:
    % setenv LD_LIBRARY_PATH $ACE_ROOT/lib:$LD_LIBRARY_PATH
  7. When all this is done, hopefully all you'll need to do is type:
    % make
    at the ACE_ROOT directory. This will build the ACE library, tests, the examples, and the sample applications. Building the entire ACE release can take a long time and consume lots of disk space, however. Therefore, you might consider cd'ing into the $ACE_ROOT/ace directory and running make there to build just the ACE library. As a sanity check, you might also want to build and run the automated "one-button" tests in $ACE_ROOT/tests. Finally, if you're also planning on building TAO, you should build the gperf perfect hash function generator application in $ACE_ROOT/apps/gperf.
  8. If you've set the INSTALL_PREFIX before building, now run
    % make install
  9. If you need to regenerate the ace/Svc_Conf_y.cpp file, you'll need to get GNU Bison. However, you should rarely, if ever, need to do this.

Building and Installing ACE on Windows

This section contains instructions for building ACE on Microsoft Windows with a variety of compilers and development environments.

First, if you are upgrading from an older release, the recommended practice is to start with a clean directory. Unpacking the newer release over an older one will not clean up any old files, and trying to use the environment's "Clean" command will probably not account for all existing files.

Building and Installing ACE on Windows with Microsoft Visual Studio

ACE contains project files for Microsoft Visual Studio .NET 2005 (VC8) , Visual Studio 2009 (VC9), and Visual Studio 2010 (VC10). Visual Studio 2005 supports building for desktop/server Windows as well as for Windows CE and Windows Mobile. Since not all users will be interested in the CE/Mobile capability, these platforms have separate solution and project files from the desktop/server Windows. Furthermore, VC7.1, VC8, VC9, and 10 use different file formats but the same file suffixes (.sln and .vcproj). To support both environments, ACE supplies files with different names for the different development and target platforms. The platform/name mapping is shown below. All solution files have a .sln suffix and all project files have a .vcproj suffix.

The free Visual C++ 2008 Express Edition will work in place of the traditional Visual Studio editions. All the other notes in this document that are for VC8 / VC9 also apply to the express edition. MFC, 64-bit, and CE/mobile options are not available with the express edition. 64-bit binaries can be built with the compiler and linker included in the Windows SDK, using nmake as the build system (generate nmake makefiles with mwc.pl -type nmake).

Mapping of Platform to Solution/Project File Name
Platform File Name
VC7.1 name_vc71
VC8 for desktop/server name_vc8
VC8 for Windows CE/Mobile name_WinCE
VC9 for desktop/server name_vc9
VC10 for desktop/server name_vc10

The VC++ compiler and linker can now be invoked from GNU make just like most UNIX builds. Follow the instructions in the ACE/GNU Configuration sections and see the additional information in the comments of platform_win32_msvc.GNU.

If you happen to open a VC7.1 file from within VC8, it will offer to convert the file to the newer format for you. With the stock VC8, do not do this; Visual Studio will crash while attempting to convert the large solution and project files to build ACE. Simply refuse the conversion and open the file with the correct format. Note that Microsoft has fixed this problem. See https://msdn.microsoft.com/visualc/downloads/default.aspx for information.

  1. Uncompress the ACE distribution into a directory, where it will create a ACE_wrappers directory containing the distribution. The ACE_wrappers directory will be referred to as ACE_ROOT in the following steps -- so ACE_ROOT\ace would be C:\ACE_wrappers\ace if you uncompressed into the root directory.

  2. Create a file called config.h in the ACE_ROOT\ace directory that contains:

    #include "ace/config-win32.h"

  3. The static, DLL and MFC library builds are kept in different workspaces. Files with names *_Static contain project files for static builds. Workspaces for static and DLL builds will be available through the stock release at DOC group's website. The workspaces for MFC are not available and have to be generated using MPC. Please see MPC's README for details.

  4. Now load the solution file for ACE (ACE_ROOT/ACE.sln).

  5. Make sure you are building the configuration (i.e, Debug/Release) the one you'll use (for example, the debug tests need the debug version of ACE, and so on). All these different configurations are provided for your convenience. You can either adopt the scheme to build your applications with different configurations, or use ace/config.h to tweak with the default settings on NT.
    Note: If you use the dynamic libraries, make sure you include ACE_ROOT\lib in your PATH whenever you run programs that uses ACE. Otherwise you may experience problems finding ace.dll or aced.dll.

  6. To use ACE with MFC libraries, also add the following to your config.h file. Notice that if you want to spawn a new thread with CWinThread, make sure you spawn the thread with THR_USE_AFX flag set.

    #define ACE_HAS_MFC 1

    By default, all of the ACE projects use the DLL versions of the MSVC run-time libraries. You can still choose use the static (LIB) versions of ACE libraries regardless of run-time libraries. The reason we chose to link only the dynamic run-time library is that almost every NT box has these library installed and to save disk space. If you prefer to link MFC as a static library into ACE, you can do this by defining ACE_USES_STATIC_MFC in your config.h file. However, if you would like to link everything (including the MSVC run-time libraries) statically, you'll need to modify the project files in ACE yourself.

  7. Static version of ACE libraries are built with ACE_AS_STATIC_LIBS
    defined. This macro should also be used in application projects that link to static ACE libraries

    Optionally you can also add the line

    #define ACE_NO_INLINE

    before the #include statement in ACE_ROOT\ace\config.h to disable inline function and reduce the size of static libraries (and your executables.)

  8. ACE DLL and LIB naming scheme:

    We use the following rules to name the DLL and LIB files in ACE when using MSVC.

    "Library/DLL name" + (Is static library ? "s" : "") + (Is Debugging enable ? "d" : "") + {".dll"|".lib"}

More information for ACE/TAO on MSVC can be found here. The doxygen version of this document is available under Related Topics in the ACE Library.

ACE TESTS

The tests are located in ACE_ROOT\tests. There is also a solution in that directory to build all the tests (tests.sln)

Once you build all the tests (Batch Build works well for this), you can run perl script run_test.pl in the tests directory to try all the tests.

BUILDING ACE ON A WIN32 MACHINE THAT LACKS A NETWORK CARD

You may want to run ACE on a non-networked machine. To do so, you must install TCP/IP and configure it to ignore the absence of a network card. This is one method:

  1. Run Control Panel
  2. Choose Network from Control Panel
  3. Add Adapter: MS Loopback Adapter
  4. Configure MS Loopback Adapter with 802.3 (default)
  5. Add Protocol: TCP/IP Protocol
  6. Configure TCP/IP Protocol with a valid IP address and subnet mask. Leave everything else at the default settings.
  7. Add Service: Workstation
  8. Exit and Restart System
  9. Run Control Panel again
  10. Choose Services from Control Panel
  11. The following services are not necessary and may be set to Disabled Startup:
    Alerter
    Computer Browser
    Net logon
    Messanger
  12. Choose Network from Control Panel
  13. Confirm the following setup. This is all you need to run ACE:
    Installed Software:
    Computer Browser
    MS Loopback Adapter Driver
    TCP/IP Protocol
    Workstation
    Installed Adapter Cards:
    MS Loopback Adapter

 

Building and Installing ACE on Windows with Embarcadero C++

The Embarcadero C++ port is not maintained anymore due to lack of funding.

If you are building for a machine without a network card, you may want to check here first.

  1. Uncompress the ACE distribution into a directory, where it will create an ACE_wrappers directory containing the source. The ACE_wrappers directory will be referred to as ACE_ROOT in the following steps -- so ACE_ROOT\ace would be C:\ACE_wrappers\ace if you uncompressed into the root directory.

  2. Create a file called config.h in the ACE_ROOT\ace directory that contains:

    #include "ace/config-win32.h"

  3. Open a Command Prompt (DOS Box).

  4. Set the ACE_ROOT environment variable to point to the ACE_wrappers directory. For example:

    set ACE_ROOT=C:\ACE_wrappers

  5. Add ACE_wrappers\lib and ACE_wrappers\bin to the PATH environment variable:

    set PATH=C:\ACE_wrappers\lib;C:\ACE_wrappers\bin;%PATH%

  6. Generate the bmake makefiles using MPC. Use the bmake project type for C++ Builder.

  7. Change to the ACE_ROOT\ace directory.

  8. Build release DLLs for ACE by going:

    make -f Makefile.bmak all

  9. You can build several different versions of ACE by setting environment variables before you run make:

    Set the environment variable below to build a debug version of ACE
    set DEBUG=1

    Set the environment variable below to build a unicode version of ACE
    set UNICODE=1

    Set the environment variable below to build a version of ACE with Codeguard support. Should only be used when DEBUG is also set
    set CODEGUARD=1

    Set the environment variable below to build a version of ACE optimized for a certain CPU. For this there are special compiler flags (-3/-4/-5/-6), see the Embarcadero help for more info.
    set CPU_FLAG=-6

    You can then start the build with the command
    make -f Makefile.bmak all

    You may also enable the options by passing them as command line options to make, for example:
    make -f Makefile.bmak -DDEBUG all

Note that when you run make in a sub directory you give make -f Makefile.bmak all. The all is needed to make sure the complete project is build.

The Borland/CodeGear/Embarcadero C++ Builder 4.0/5.0/6.0/2006/2007/2009/2010 port has been done by Jody Hagins, Christopher Kohlhoff and Johnny Willemsen.

ACE TESTS

Before you can build the tests you need to build the protocols directory. Change the directory to ACE_ROOT\protocols and start the build with:

make -f Makefile.bmak all

The tests are located in ACE_ROOT\tests, change to this directory. You build then the tests with the following command:

make -f Makefile.bmak all

Once you build all the tests, you can run the automated test script using:

perl run_test.pl

in the tests directory to try all the tests. You need to make sure the ACE bin and lib directory (in this case ACE_ROOT\bin and ACE_ROOT\lib) are on the path before you try to run the tests.

Building and Installing ACE on Win32 with MinGW/ MSYS

If you are building for a machine without a network card, you may want to check here first.

Building and installing ACE on MinGW uses a mix of a UNIX building process and Win32 configuration files. Also, as MinGW uses GNU g++, you may want to take a look at the Compiling ACE with GNU g++ section.

You will need the MinGW build tools and libraries, downloable from http://www.mingw.org.
For our build we require the packages MinGW and MSYS.

  1. Install the MinGW tools (including the MinGW Development toolkit) into a common directory, say c:/mingw.

  2. Install the MSYS tools into a common directory, say c:/msys.

  3. Open a MSYS shell. Set your PATH environment variable so your MinGW's bin directory is first: 
           % export PATH=/c/mingw/bin:$PATH
  4. Add an ACE_ROOT environment variable pointing to the root of your ACE wrappers source tree: 
           % export ACE_ROOT=/c/work/mingw/ACE_wrappers
    From now on, we will refer to the root directory of the ACE source tree as $ACE_ROOT.

  5. Create a file called config.h in the $ACE_ROOT/ace directory that contains: 
           #include "ace/config-win32.h"
  6. Create a file called platform_macros.GNU in the $ACE_ROOT/include/makeinclude directory containing: 
           include $(ACE_ROOT)/include/makeinclude/platform_mingw32.GNU
    In the above text, don't replace $(ACE_ROOT) with the actual directory, GNU make will take the value from the environment variable you defined previously.

    If you lack Winsock 2, add the line 

           winsock2 = 0
    before the previous one.

    If you want to install ACE (using "make install") and want all the .pc files generated, set the installation prefix in platform_macros.GNU. 

          INSTALL_PREFIX=/c/ACE
    Headers will be installed to $INSTALL_PREFIX/include, documentation and build system files to $INSTALL_PREFIX/share and libraries to $INSTALL_PREFIX/lib. With INSTALL_PREFIX set, RPATH will be enabled. To disable RPATH (for example, if $INSTALL_PREFIX/$INSTALL_LIB is already a system-known location for shared libraries), set the make macro install_rpath to 0 by adding install_rpath=0 to platform_macros.GNU.

  7. In the MSYS shell, change to the $ACE_ROOT/ace directory and run make: 
           % cd $ACE_ROOT/ace
       % make

    This should create libACE.dll (the Win32 shared library) and libACE.dll.a (the Win32 import library for the DLL). Note that the name for the ACE DLL follows the MinGW convention, which itself resembles UNIX.

    If you want static libs also, you may run: 

           % make static_libs_only=1
  8. Run make install: 
           % make install

    This should create ACE.pc to use with pkg-config.

  9. The same rules for Win32 search of DLLs apply for MinGW. If you want to run some ACE programs from the MSYS shell, you may need to add the directory for libACE.dll to your PATH: 
           % export PATH=/c/work/mingw/ACE_wrappers/ace:$PATH
ACE TESTS

The tests are located in $ACE_ROOT/tests. After building the library, you can change to that directory and run make: 

       % cd $ACE_ROOT/tests
       % make

Once you build all the tests, you can run run_tests.pl in the tests directory to try all the tests: 

       % perl run_test.pl

If you are using ACE as a DLL, you will need to modify your PATH variable as explained above.

You may want to check $ACE_ROOT/tests/README for the status of the various tests on MinGW and the different Windows flavors.

Building and Installing ACE on Win32 with Cygwin

If you are building for a machine without a network card, you may want to check here first.

Building and installing ACE on Cygwin uses the UNIX building process. Also, as Cygwin uses GNU g++, you may want to take a look at the Compiling ACE with GNU g++ section.

You will need the Cygwin build tools and libraries, downloable from http://www.cygwin.com. For our build we require the following packages besides the packages the setup selects by default:

gcc (version 3.3.3), cygserver, make, perl, binutils.
  1. Install Cygwin (this can be easy downloading and running setup.exe from the Cygwin site). For working with ACE we recommend to select DOS as default text file type.

  2. Open a Cygwin shell. Set your PATH environment variable so your Cygwin bin directory is first: 
           % export PATH=//c/cygwin/bin:$PATH
    or 
           % export PATH=/cygdrive/c/cygwin/bin:$PATH

    Note Cygwin uses ``/'' as directory separator, and ``//X'' as a notation for Win32 drive X. Note also that you can't use ``c:/cygwin/bin'' because, for Cygwin, ``:'' is path separator character, as in UNIX.

  3. Add an ACE_ROOT environment variable pointing to the root of your ACE wrappers source tree: 
           % export ACE_ROOT=/cygdrive/c/work/cygwin/ACE_wrappers

    Note here you can't use the ``//X'' Cygwin notation as this is seen by Cygwin's compiler and it doesn't support that (it does support ``/'' as directory separator however).

    From now on, we will refer to the root directory of the ACE source tree as $ACE_ROOT.

  4. Create a file called config.h in the $ACE_ROOT/ace directory that contains: 
           #include "ace/config-cygwin32.h"
  5. Create a file called platform_macros.GNU in the $ACE_ROOT/include/makeinclude directory containing: 
           include $(ACE_ROOT)/include/makeinclude/platform_cygwin32.GNU
    In the above text, don't replace $(ACE_ROOT) with the actual directory, GNU make will take the value from the environment variable you defined previously.
  6. On the Cygwin shell, change to the $ACE_ROOT/ace directory and run make: 
           % cd $ACE_ROOT/ace
       % make

    This should create libACE.dll (the Win32 shared library) and libACE.dll.a (the Win32 import library for the DLL). Note the name for the ACE DLL on Cygwin follows the UNIX convention.

    If you want static libs also, you may run: 

           % make static_libs_only=1
  7. The same rules for Win32 search of DLLs apply for Cygwin. If you want to run some ACE programs from the Cygwin shell, you may need to add the directory for libACE.dll to your PATH: 
           # export PATH=//c/work/cygwin/ACE_wrappers/ace:$PATH
    If you are using MPC-generated Makefiles, then the DLLs have been placed in the lib directory instead of ace and thus your PATH addition would need to look like this: 
           # export PATH=//c/work/mingw/ACE_wrappers/lib:$PATH
ACE TESTS

The tests are located in $ACE_ROOT/tests. After building the library, you can change to that directory and run make: 

       % cd $ACE_ROOT/tests
       % make

Once you build all the tests, you can run run_tests.pl in the tests directory to try all the tests: 

       % perl run_test.pl

If you are using ACE as a DLL, you will need to modify your PATH variable as explained above.

You may want to check $ACE_ROOT/tests/README for the status of the various tests on Cygwin and the different Windows flavors.

Building and Installing ACE on Win32 with Interix

Interix comes with a BSD style make; you need GNU make. Make builds easily under Interix or there is a prebuilt package at:

http://www.interopsystems.com/tools/warehouse.htm

If you are building for a machine without a network card, you may want to check here first.

This port was built and tested under Interix 3.5. a.k.a. Windows Services for UNIX 3.5.

To build follow the Traditional ACE/GNU Make Configuration instructions replacing the following include directives:

#include "ace/config-win32-interix.h"

for the config.h header

and:

include $(ACE_ROOT)/include/makeinclude/platform_win32_interix.GNU

for your platform_macros.GNU file.

ACE should build fine with just 'make', the only other option tried thus far is 'make static_libs_only=1' which also works. Any other options may not work.

ACE TESTS

The tests are located in $ACE_ROOT/tests. After building the library, you can change to that directory and run make:

% cd $ACE_ROOT/tests
% make

Once you build all the tests, you can run run_test.pl in the tests directory to try all the tests:

% run_test.pl

If you are using ACE as a shared library, you will need to modify your LD_LIBRARY_PATH as explained inTraditional ACE/GNU Make Configuration.

Building and Installing ACE on VxWorks

For the most part, you should be able to follow the instructions above to build ACE and applications that use it. Start with the Unix instructions above to build ACE and the applications that use it. Please see below for more information on building ACE on NT hosts for VxWorks targets.

A few notes on VxWorks builds (thanks to Paul von Behren and Remedy IT for these notes):

You'll have to let ACE know the target type at compile time. There are several ways to do this; please see the $ACE_ROOT/include/makeinclude/platform_vxworks5.5.x.GNU platform file for detailed information.

The VxWorks platform_vxworks*.GNU files are set up so that shared libraries are not built on VxWorks, by default. Only static libraries, with .a extension, are built. Therefore, it's not necessary to set the LD_LIBRARY_PATH environment variable on your host system when building for VxWorks targets. Please note, however, if you use TAO on VxWorks that you will need to set your LD_LIBRARY_PATH to find the TAO IDL compiler libraries (installed in the ace directory) on the host.

These non-default VxWorks kernel configuration #defines are required with ACE:

#define INCLUDE_CPLUS           /* include C++ support */
#define INCLUDE_CPLUS_IOSTREAMS /* include iostreams classes */
#define INCLUDE_POSIX_ALL       /* include all available POSIX functions */
For completeness, here are the non-default #defines that we used for VxWorks 5.3.1/g++ 2.7.2: 
#define INCLUDE_CPLUS           /* include C++ support */
#define INCLUDE_CPLUS_IOSTREAMS /* include iostreams classes */
#define INCLUDE_CONFIGURATION_5_2 /* pre-tornado tools */
#define INCLUDE_DEBUG           /* pre-tornado debugging */
#define INCLUDE_LOADER          /* object module loading */
#define INCLUDE_NET_SYM_TBL     /* load symbol table from network */
#define INCLUDE_SYM_TBL_SYNC    /* synchronize host and target symbol tables */
#define INCLUDE_NFS             /* nfs package */
#define INCLUDE_PING            /* ping() utility */
#define INCLUDE_POSIX_ALL       /* include all available POSIX functions */
#define INCLUDE_RDB             /* remote debugging package */
#define INCLUDE_RLOGIN          /* remote login */
#define INCLUDE_RPC             /* rpc package */
#define INCLUDE_SECURITY        /* shell security for network access */
#define INCLUDE_SHELL           /* interactive c-expression interpreter */
#define INCLUDE_SHOW_ROUTINES   /* show routines for system facilities*/
#define INCLUDE_SPY             /* spyLib for task monitoring */
#define INCLUDE_STARTUP_SCRIPT  /* execute start-up script */
#define INCLUDE_STAT_SYM_TBL    /* create user-readable error status */
#define INCLUDE_SYM_TBL         /* symbol table package */
#define INCLUDE_UNLOADER        /* object module unloading */
#define INCLUDE_WINDVIEW        /* WindView command server */
Also, automatic construction/destruction of static objects should be enabled.

If you use TAO, it's also a good idea to increase the NUM_FILES parameter from its default of 50 to, say, 1000.

Please note that those VxWorks kernel configuration parameters are set in the VxWorks configAll.h file. You must rebuild your VxWorks kernel after modifying that file.

If you're first getting started with ACE and/or VxWorks, I recommend just building the ACE library and tests first. (Some of the ACE examples, in System_V_IPC, don't build on VxWorks yet.) Then try running the tests. Please see $ACE_ROOT/tests/README for the latest status of the ACE tests on VxWorks.

Please note that the main entry point is renamed to ace_main (configurable via ACE_MAIN) on VxWorks with g++, to comply with its restriction against using main. In addition, ACE_HAS_NONSTATIC_OBJECT_MANAGER is enabled by default to cleanly support construction and destruction of static objects. Please see the Non-static ACE_Object_Manager discussion for the important implication of this feature.

ACE threads (VxWorks tasks) can be named, for example, by supplying a non-null argument to the Thread_Manager spawn routines. However, names beginning with "==ace_t==" are forbidden because that prefix is used internally by ACE.

You can spawn a new task to run ace_main, using either VxWorks sp, or ACE'S spa. spa can be used from the VxWorks shell to pass arguments to ace_main. Its usage is: 


spa ace_main, "arg1" [, ...]
All arguments must be quoted, even numbers. You can start also ace_main without spawning another thread by using:


spaef ace_main, "arg1" [, ...]
ACE also provides the function vx_execae which is capable of running ace_main in a separate thread, wait for the task to finish and return the return code from ace_main: 

int vx_execae (FUNCPTR acemain,char* arguments, int prio = 0, int opt = 0, int stacksz = 0);

You could call this from the VxWorks shell like: 


my_rc = vx_execae ace_main, "-o server.ior -ORBDottedDecimalAddresses 1"

When prio, opt or stacksz are omitted or specified as 0 default values will be used. See the VxWorks shell documentation for the defaults for prio and opt. For stacksz the default is ACE_NEEDS_HUGE_THREAD_STACKSIZE. The arguments string will be parsed and passed on to ace_main as a regular argc and argv.

Be aware of the fact that when you execute ace_main directly from the VxWorks shell argc will be zero and argv* will also be zero. Using argv[0] will not return the program name, but will result in a crash.
The ACE helper functions spa, spaef and vx_execae prevent this problem by building a regular argc and argv which also contain a valid argv[0] element.

Building Shared Libraries for VxWorks.

NOTE: Since VxWorks support is currently being reworked with an initial focus on static builds the support for shared builds is momentarily broken. This will be remedied(!) as soon as possible.

ACE supports shared libraries for VxWorks, but only with the g++ compiler. To build shared libraries instead of the default static libraries, added shared_libs_only=1 to either your ACE_wrappers/include/makeinclude/platform_macros.GNU or your make invocation. Then, be sure to load the ACE (and any other) shared library before loading your executable(s).

A shared library for VxWorks uses the same code as for a static (non-shared) library. However, calls to static constructors/ destructors are added. The code in the shared library must be reentrant if you shared it between programs (tasks). The ACE library meets this requirement.

Shared libraries reduce build time, executable size, and load time of the executable. But, you must manually load the shared library before loading your executable(s) with a command such as: 


-> ld < libACE.so
Shared libraries can be unloaded the same way an executable (module) is unloaded.

NOTE: Shared libraries on VxWorks aren't the same as shared libraries on other operating systems. In particular, there is no support for creating copies of writeable global (static) data in the shared library. This includes the singleton ACE_Object_Manager instance pointer. If you share global data between separate programs, they may not work properly. See the discussion of shared code and reentrancy in the VxWorks' Programmers Guide.

Instead of trying to run separate programs onto a VxWorks target, we recommend creating just one program, and spawning a thread for each task. The TAO IDL_Cubit test collocation test is a good example.

Linking ACE and/or TAO Libraries into the VxWorks Kernel.

It's easy to link your ACE and/or TAO libraries into the VxWorks kernel. Just build shared versions, but disable the munch step. The easiest way to do that is to set the LD make variable to the name of your linker. For example, to build a libACE.so for PowerPC that can be linked into the kernel: 
% cd $ACE_ROOT/ace
% make LD=ldppc shared_libs_only=1
After building the shared lib, link it into the kernel by setting the MACH_EXTRA make variable in the kernel configuration Makefile. Then, build the kernel using make exe.

Using the one-button ACE tests with VxWorks.

It is possible to generate a script to execute all ACE tests. You can do this by executing 

% perl run_test.pl -v -o > run_test.vxworks
The ACE tests write their output files in a directory named log/, below the current (tests) directory.

To run the tests from the build directory on an NT host where you crossbuild your VxWorks ACE/TAO you can set up the Target Server File System (TSFS) in your Target Server configuration. If you f.i. set the root for the TSFS to the root directory of your builddisk you can set the default directory for the target by issueing the following command from a Host shell: '@cd "/tgtsvr/{path to ACE}/ACE_wrappers/tests"'. The '@' addition makes sure this command is executed for the target environment and not the local host shell environment. If you also issue the command 'cd {path to ACE}/ACE_wrappers/tests' you can execute the generated one button testscript like: '< run_test.vxworks'.

Running the ACE tests automatically from the ACE autobuild tool using Target Server and Host shell options is also supported.

If you don't have NFS included in your VxWorks kernel, you can use these steps, provided by Clarence M. Weaver, to run the tests and capture their output:

  1. What I did was create a log directory on the boot NT host of my VxWorks target.

  2. I copied all the test applications and the run_test.vxworks script to the parent of the log directory.

  3. Using the target shell not the host shell, I "cd" to the directory containing the script and test programs.

  4. Invoked the script using < run_test.vxworks from this target shell.

Kirk Davies provided this approach for running the ACE tests on Tornado II:

Building ACE on Tornado/NT hosts for VxWorks targets.

The following, very useful information was contributed by Chris Ryan and Paul von Behren. Please submit corrections, additions, or clarifications to the the ACE mailing list.

NOTE:The make (version 3.74) that is provided with Tornado 2.2 cannot be used to build ACE. A working version is available from the WindRiver support site, download the make3_80.gvk_patches and the make3_80.tor2_2.new_dependency_rules package and install them.

Using the Cygnus tools, this approach works:

A few additional Windows Notes, from Paul von Behren:

And Chris Ryan's instructions for building for VxWorks targets on Windows NT hosts:
  1. Path setting that seems to be working is:

          /tornado/host/x86-win32/bin:
      /tornado/host/x86-win32/lib/gcc-lib/i386-wrs-vxworks/cygnus-2.7.2-960126:
      /tornado/host/x86-win32/i386-wrs-vxworks/bin:
      /ace/ace_wrappers/bin:
      /gnuwin32/b18/H-i386-cygwin32/bin:
      /gnuwin32/b18/tcl/bin:
      /WINNT/system32:
      /WINNT:
      /WINNT/system32/nls/ENGLISH:
      /bin
    Other environment variables:

          WIND_BASE=/tornado
      SHELL=/bin/sh.exe
      TERM=pcbios
      TAO_ROOT=/ace/ACE_wrappers.vxworks/TAO
      CPP_LOCATION=/Program Files/DevStudio/VC/bin/CL.EXE
      GCC_EXEC_PREFIX=/tornado/host/x86-win32/lib/gcc-lib/
      WIND_HOST_TYPE=x86-win32
      ACE_ROOT=/ace/ACE_wrappers.vxworks
  2. /tornado is the root of the Tornado install ($WIND_BASE).
  3. /gnuwin32 is the root of a Cygnus GNU download and install.
  4. /bin content is:

          aced.dll
      cygwin.dll
      perl.exe
      rm.exe
      sh.exe
      true
    aced.dll is produced in an ACE NT source tree according to documented procedure for Windows VC++ ACE build. cygwin.dll is from the Cygnus GNU software download and install.
  5. Basically, follow documented procedure for ACE build/install on UNIX platform. Create a $ACE_ROOT/ace/config.h that looks like:

          #include "config-vxworks5.x.h"
    And create a $ACE_ROOT/include/makeinclude/platform_macros.GNU that looks like:

          WIND_BASE = /tornado
      WIND_HOST_TYPE = x86-win32
      CPU = I80486
      include $(ACE_ROOT)/include/makeinclude/platform_vxworks5.5.x.GNU
  6. When using cygnus windows GNUTools on WinNT you have to start make with "--unix" option, otherwise WinNT shell cmd.exe is responded and not sh.exe, i.e., 
     make --unix static_libs_only=1

TAO on NT Tornado host, VxWorks target.

  1. Build ACE and TAO_IDL in the NT tree as already documented. Be sure to build ACE's gperf on NT, in ACE_wrappers/apps/gperf/src.

  2. Build $TAO_ROOT/tao 
          CPP_LOCATION=/Program Files/DevStudio/VC/bin/CL.exe
      cd $TAO_ROOT/tao
      /gnuwin32/b18/H-i386-cygwin32/bin/make
  3. Build orbsvcs. 
          CPP_LOCATION=/Program Files/DevStudio/VC/bin/CL.exe
      cd $TAO_ROOT/orbsvcs/orbsvcs
      /gnuwin32/b18/H-i386-cygwin32/bin/make
  4. Build $TAO_ROOT/tests

Jaffar Shaikh's Notes for Building ACE and TAO for VxWorks on NT host

Scenario: I was building the ACE and TAO for VxWorks on NT. The target system was a PPC860 based chassis and another a NT host based card.

Host System:

NT 4.0 workstation with 128 M RAM, 266MHz Pentium.

Software Needed For Building TAO

1) Active State's ActivePerl from http://www.activestate.com/software/default.htm

2) Tornado 2.2.1 from Windriver.

3) Cygwin GNU to build TAO. It is available for NT as a freeware from the Cygwin site

The Cygwin Make (version 3.75) can only build the TAO not the Tornado II make (version 3.74)

Environment Variables:

On NT the environment Variables are set as follows, (from Control Panel-> System -> Environment)

I added following Environment variable entries to PATH

C:\Perl\bin\;

C:\tornado\host\x86-win32\bin;

C:\tornado\host\x86-win32\powerpc-wrs-vxworks\bin;

C:\tornado\host\x86-win32\lib\gcc-lib\powerpc-wrs-vxworks\cygnus-2.7.2-960126;

C:\Corba\Ace_wrappers\bin;

C:\Cygwin\bin;

C:\Cygwin\usr\bin;

C:\bin

Additional Environmental variables and the values,

CPU=PPC860

LD_LIBRARY_PATH=

SHELL=/bin/sh.exe

ACE_ROOT=/Corba/ACE_wrappers

WIND_BASE=/tornado

SHELL=/bin/sh.exe

TERM=pcbios

TAO_ROOT=/Corba/ACE_wrapper/Tao

CPP_LOCATION=/Program Files/Microsoft Visual Studio/VC98/Bin/CL.exe

GCC_EXEC_PREFIX=/tornado/host/x86-win32/lib/gcc-lib/

WIND_HOST_TYPE=x86-win32

PERL_PATH=/perl/bin/perl.exe

Directories of importance

C:\Corba <-- Ace_wrappers (uzipped)

C:\tornado <-- Tornado installed

C:\Perl <-- Perl installed

C:\Cygwin <-- Cygwin installed

C:\bin <-- Copy these files,

Ace.dll, <-- After you build Ace

gperf.exe <-- After you build gperf

Cygwin1.dll, <-- After you install Cygwin

perl.exe, <-- After you install Perl

rm.exe <-- After you install Cygwin

sh.exe <-- After you install Cygwin

true <-- After you install Cygwin

Create Files

1) C:\Corba\ACE_Wrappers\ace\config.h

with entry

#if defined (_MSC_VER) || (__BORLANDC__)

#include "ace/config-win32.h"

#else

#define ACE_HAS_IP_MULTICAST

#include "ace/config-vxworks5.x.h"

#endif

2) C:\Corba\ACE_wrappers\include\makeinclude\platform_macros.GNU

WIND_BASE = /tornado

WIND_HOST_TYPE = x86-win32

include $(ACE_ROOT)/include/makeinclude/platform_vxworks5.5.x.GNU

ACE_COMPONENTS=FOR_TAO (you may choose this option to build ACE library that supports TAO)

Steps to Build

1) Build Ace.dll under NT

In MS Visual C++ open C:\Corba\ACE_wrappers\ace.sln And build Ace DLL

Copy Ace.dll in C:\bin

2) Build gperf utility under NT

In MS Visual C++ open C:\Corba\ACE_wrappers\apps\gperf\src\gperf.sln. Build gperf.exe

Copy gperf.exe to C:\bin

3) Mount Directries in Cygwin

Click on Cygnus Solutions -> Cygwin Bash Shell

Mount following directories by using mount command.

create respective directories first then use mount command

e.g. Create /Corba directory then use $mount -s "C:\Corba" /Corba

C:\Corba mount to /Corba

C:\tornado mount to /tornado

C:\Perl mount to /perl

C:\Cygwin mount to /cygwin

C:\bin mount to /bin

C:\Program Files mount to /Program Files

4) Build ACE in Cygwin

$cd /Corba/ACE_wrappers/ace

$make static_libs_only=1

This will build your ace library libACE.a for VxWorks. If you use option shared_libs_only=1 then the build will be libACE.so. The other options are same as follows.

5) Build TAO in Cygwin

$cd $TAO_ROOT/tao

$make debug=0 optimize=1 static_libs_only=1 minimum_orb=1

for shared libs use shared_libs_only=1

The minimum Tao does not have following components,

Dynamic Skeleton Interface

Dynamic Invocation Interface

Dynamic Any

Interceptors

Interface Repository

Advanced POA features

CORBA/COM interworking

You may play around with above options to find suitable build for your needs. For example when you give option debug=1 all the debug symbols will be created and the build will huge in size. The debug symbols are necessary when you want to debug your code.

Building and Installing ACE on Android

ACE can be built for Android by using the Android Native Development Kit (NDK). This is different than the standard way of writing Android applications in Java which run the on the Android Runtime or the older Dalvik Virtual Machine. Applications and libraries built using the NDK are native Linux applications written in C or C++ specifically compiled to run on Android systems and libraries can be included in normal Android apps. In addition, applications and libraries built using the NDK have access to Android-specific APIs much like the ones available to Java-based Android applications.

Windows Users: These instructions are written for a Unix based platform like Linux, but can also be used on Windows. If you are using an virtualized Linux environment like Windows Subsystem for Linux (WSL), Docker, or a traditional VM, then you can use the Linux version of the NDK and ignore rest of this note and all the other Windows specific notes.

If that is not the case, you should also pay attention to the notes marked with "Windows Users:" in addition to the rest of the instructions. In addition to the Windows version of the Android NDK, you will also need MSYS2 for Unix utilities that ACE needs.

After downloading the NDK, you will have to decide on what target you want to build for, which is covered in the next section, then decide if you want to build directly using the NDK or using a generated standalone toolchain. Generating a toolchain is optional and only really makes sense if you're building for just one architecture/API level pair and don't need to keep the entire NDK around. Using the NDK directly requires Android NDK r19 or later.

Choosing the Target

To build ACE for Android you need to know the specific Android target you want. The specific target is defined by two things:

- The minimal API level to target.
A lower level means larger amount of potential users but also potentially less features. Android has many API levels to target. They roughly correspond to the versions of Android.
- The CPU architecture to target (Also called the Application Binary Interface or ABI by the NDK documentation).
In addition to ARM, Android also supports x86 and MIPS, although support for MIPS has been dropped from the NDK. This is the official documentation on the ABIs. These are the ABIs that ACE supports at the time of writing and must be passed to ACE as android_abi:
armeabi-v7a
32-bit ARM, The default ABI for both the NDK and ACE.
armeabi-v7a-with-neon
armeabi-v7a with NEON extensions enabled.
arm64-v8a
64-bit ARM, Sometimes referred to as aarch64.
x86
32-bit x86
x86_64
64-bit x86

It should be noted that starting in August 2019, the Google Play Store will require new apps to have 64-bit libraries if they have native libraries. 32-bit native libraries will still be supported but apps must also have 64-bit libraries. Look up any restrictions that may affect apps you want to publish on the Play Store, including targeted API level requirements.

Generating a Toolchain (Optional)

To generate a toolchain, one use must use build/tools/make_standalone_toolchain.py in the NDK. A destination must be chosen and is denoted here as $TOOLCHAIN. For example, to generate a toolchain targeting 32-bit ARM Android 7.0 "Nougat" (API Level 24) and later:

./make_standalone_toolchain.py --arch arm --api 24 --install-dir $TOOLCHAIN

$TOOLCHAIN/bin must be in your $PATH when building ACE and applications using ACE.

This table shows how the android_abi variable and the --arch argument correlate:

android_abi --arch
armeabi-v7a arm
armeabi-v7a-with-neon arm
arm64-v8a arm64
x86 x86
x86_64 x86_64

Windows Users: Android NDK includes Python in prebuilt\windows-x86_64\bin for 64-bit Windows NDKs. For the example above, assuming %NDK% is the location of the NDK and %TOOLCHAIN% is the desired location of the toolchain, run this command instead:

%NDK%\prebuilt\windows-x86_64\bin\python.exe %NDK%\build\tools\make_standalone_toolchain.py --arch arm --api 24 --install-dir %TOOLCHAIN%

For Windows %TOOLCHAIN%\bin and the location of the MSYS2 utilities must be in %PATH% when cross compiling ACE. The default location for these would be C:\msys64\usr\bin.

Using Older NDKs

Skip this section if using NDK r18 or later.

It is highly recommended to use the latest NDK available assuming that it works with ACE. It is possible to use NDKs older than r18, but these have caveats:

Building

Installing ACE on Android

Native applications using the ACE library can be installed onto devices by several different methods. The files can be include as assets of Java application and can be written by the Java application into it's executable program directory. The native application can be downloaded by a Java application and written into the Java applications executable program directory. The native application can also be uploaded using the Software Development Kit's ADB tool. This method requires uploading the native application to a directory that allows execution and having any output directed to a writable directory.

Logging

On Android, ACE_Log_Msg (and therefore ACE_DEBUG and ACE_ERROR) uses Android's logging system (aka Logcat) by default in addition to stderr because stdout and stderr are discarded under normal circumstances. To disable this at runtime, run: 

ACE_LOG_MSG->clr_flags (ACE_Log_Msg::SYSLOG);

To disable this at compile time include these lines in config.h:

#define ACE_DEFAULT_LOG_FLAGS ACE_Log_Msg::STDERR
#define ACE_DEFAULT_LOG_BACKEND_FLAGS 0

OpenSSL

Depending on the features of ACE, TAO, or other software desired, you might need OpenSSL. On Android, OpenSSL isn't part of the NDK Library and Android preloads the system SSL library (either OpenSSL or BoringSSL) for the Java Android API. This means OpenSSL MUST be statically linked to avoid conflicts with the almost certianly incompatible system SSL library. To build OpenSSL for Android, please read NOTES.ANDROID that comes with OpenSSL's source code. The static libraries will used if the shared libraries are not found. This can be accomplished by either disabling the generation of the shared libraries by passing no-shared to OpenSSL's Configure script or just deleting the so files after building OpenSSL.

Building and Installing ACE Network Services

The following explains how to build the ACE network services on UNIX and Win32.

Building and Installing ACE Network Services on UNIX

Building and installing ACE Network Services on UNIX is relatively simple (the process for Win32 is different). Here's what you need to do:

  1. Build and install ACE on UNIX as described earlier. If ACE is built at the root of the ACE source tree (and ACE has been ported to your platform, of course) the netsvcs static and shared object libraries should be built automatically. In addition, the server driver program (main) contained in $ACE_ROOT/netsvcs/servers/main.cpp should also be compiled and ready to run.

  2. Set your LD_LIBRARY_PATH environment variable to where the binary version of the ACE netsvcs library. For example, you probably want to do something like the following

    
      % setenv LD_LIBRARY_PATH $ACE_ROOT/ace:$ACE_ROOT/lib:$LD_LIBRARY_PATH

  3. By default, if the shared object library is built, the services are linked into the main driver program dynamically. To specify which services should be linked in and executed, edit the $ACE_ROOT/netsvcs/servers/svc.conf file. During your editing, you should update information (such as the default service port numbers) that affects the initialization of services in this file. Refer to the Service Configurator documentation to learn how the configuration file is parsed and how the services are dynamically linked and executed. In addition, refer to the Network Services documentation to learn more about how to configure each network service.

  4. If you only want to link the services statically, simply remove or rename the svc.conf file.

Building and Installing ACE Network Services on Win32

Once again, there are supplied project for Visual C++ 7.1 or later for the Network Services.

Building and Installing the ACE_SSL Library

The first step for all platforms is to build and install the OpenSSL distribution. The ACE_SSL library must then be built according to the instructions below.

Unix

  1. Make sure the OpenSSL header file directory is in your compiler's include path, and that OpenSSL libraries are in your library link/load path (e.g. LD_LIBRARY_PATH). If you installed OpenSSL into a set of directories unknown by the compiler, set the SSL_ROOT environment variable to point to the top level directory of your OpenSSL distribution, i.e. the one containing OpenSSL's include and lib directories.
  2. Build ACE as described above. When building ACE, add ssl=1 to your make command line invocation, or add it to your platform_macros.GNU file.
  3. Build the ACE_SSL library in the $ACE_ROOT/ace/SSL directory. The ACE_ROOT environment variable should be set prior to this point.

Microsoft Visual Studio

  1. Set the SSL_ROOT environment variable to the location of the directory containing the OpenSSL inc32 and out32dll directories.
  2. Add ssl=1 to your MPC $ACE_ROOT/bin/MakeProjectCreator/config/default.features or $ACE_ROOT/local.features file.
  3. At the moment you are using OpenSSL v1.1 or newer also add openssl11=1 to your MPC $ACE_ROOT/bin/MakeProjectCreator/config/default.features or $ACE_ROOT/local.features file.
  4. Re-run MPC to add support for building the ACE_SSL library to your MSVC++ workspaces and projects.
  5. Open the ACE.sln solution, and refer to the ACE build and installation instructions above for details on creating a config.h configuration header for this platform. Once the config.h file has been created, build the ACE_SSL project.

CodeGear C++

Support for building ACE's ACE_SSL library and TAO's SSLIOP pluggable protocol with CodeGear C++ does exist.

  1. Set the SSL_ROOT environment variable to the location of the directory containing the OpenSSL inc32 and out32 directories.
  2. Add ssl=1 to your MPC $ACE_ROOT/bin/MakeProjectCreator/config/default.features or $ACE_ROOT/local.features file, and re-run MPC to add support for building the ACE_SSL library to your CodeGear C++ makefiles.
  3. Build ACE and TAO.

Building and Using GUI Reactors Libraries

There is a general method for building and using ACE_Reactors for various GUI libraries.

Building GUI Reactor Library

  1. Try to generate build files using MPC. Inspect the output of MPC to find out which features are necessary to build given reactor. Add these features to ACE_wrappers/bin/MakeProjectCreator/*.features file, or pass them directly to MPC using -features command line option. For example, for FlReactor the procedure consists of five steps
    1. In the first pass one gets that x11 (X11 libraries) is missing.
      $ mwc.pl -type gnuace Skipping ACE_FlReactor (ace_flreactor.mpc), it requires x11.
      2. Ensure that X11 libraries are installed, then pass x11=1 feature to MPC.
    2. In the second pass one gets that gl (OpenGL library) is missing.
      $ mwc.pl -type gnuace -features x11=1 ace.mwc Skipping ACE_FlReactor (ace_flreactor.mpc), it requires gl.
      3. Ensure that OpenGL libraries are installed, then pass gl=1 feature to MPC.
    3. In the third pass one gets that fl (Fast Light Toolkit) is missing.
      $ mwc.pl -type gnuace -features x11=1,gl=1 ace.mwc Skipping ACE_FlReactor (ace_flreactor.mpc), it requires fl.
      4. Ensure that Fast Light Toolkit libraries are installed, then pass fl=1 feature to MPC.
    4. In the fourth pass one gets that ace_flreactor feature is missing
      $ mwc.pl -type gnuace -features x11=1,gl=1,fl=1 ace.mwc Skipping ACE_FlReactor (ace_flreactor.mpc), it requires ace_flreactor.
      5. Allow MPC to generate makefiles for FlReactor by setting ace_flreactor=1 feature.
    5. In the last pass one obtains files for building FlReactor.
      $ mwc.pl -type gnuace -features x11=1,gl=1,fl=1,ace_flreactor=1 ace.mwc
    Currently to simplify MPC generation some of features are turned on by default in ACE_wrappers/bin/MakeProjectCreator/global.features. For examples to generate files related with Fl one has to provide only fl=1 feature. To obtain a more fine grained controll over MPC generation process one may modify ACE_wrappers/bin/MakeProjectCreator/*.features files.
  2. Required build files are generated now, it is enough then to invoke build tool. For example for under MPC::gnuace one has to call make fl=1. For MPC::vc7 target all features are encoded in generated project files, thus it is enough to compile ACE using MSVC.
The build procedure leads to a specific GUI Reactor library. For example, for Qt and Linux one gets libQtReactor.so, while for Windows the results are shared QtReactor.dll and import QtReactor.lib libraries or their variants depending on build options. When compiling TAO also GUI related libraries are created like libTAO_QtResource.so.

Using GUI Reactor Library

Here one has at least three use cases:
  1. Applications with their own build system. To use ACE support for GUI one has to include specific GUI headers and link with specific ACE_[GUI]Reactor library. When using TAO support for GUI one has also to link with specific TAO_[GUI]Resource library.
  2. Applications with build system using MPC. In general, it is better to create specific base projects for using ACE GUI support in such application. Base projects provided by ACE ACE_wrappers/bin/MakeProjectCreator/[ace,tao]_[gui][reactor,resource].mpb may be an examples of how to do this.
  3. Internal ACE applications like tests or examples. MPC project for internal ACE application using GUI support should be derived from ace_[gui]reactor.mpb base projects. To employ TAO support for GUI one should derive the project from tao_[gui]resource.mpb These base projects ensure that all necessary libraries are linked to the application, specifies features necessary to build a project and moreover impose a build order consistant with ACE. For example, the application project using XtReactor should be derived from ace_xtreactor.mpb.

Notes on specific GUI Reactors

Installation Notes

Compiling ACE with GNU g++

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

What Do I Need to Build for TAO?

Toshio Hori <toshi@etl.go.jp> provided these suggestions on building just what's needed for (a subset of) TAO:

I usually make: 

    $ACE_ROOT/ace,
    $ACE_ROOT/apps/gperf,
    $TAO_ROOT/tao,
    $TAO_ROOT/TAO_IDL, and
    $TAO_ROOT/orbsvcs/orbsvcs
and the whole make takes less than an hour on my Solaris 7 for intel, Pentium-III/550MHz, 256MB memory, 512MB swap machine. (Top secret: I renice the 'make' process to the highest priority, -20... ;-) To save time and space, I set 
    TAO_ORBSVCS = Naming Time Trader ImplRepo
in $ACE_ROOT/include/makeinclude/platform_macros.GNU also. See TAO's orbsvcs library customization instructions for more information.

System Resource Requirements

The amount of system resources required to build ACE and TAO varies greatly. The required system resources are influenced by OS and compiler platform, build options, and component configurations. As a rough guide, the typical peak memory requirement can be well over 512 MB (notably, for TAO's orbsvcs). Depending on your OS and compiler configuration, an entire build of ACE and TAO can use well over 4 GB of disk space. It's usually not necessary to build all of ACE and TAO, though.

Much less disk space is required for just the libraries. For example, see the ACE library subset sizes.

If you run out of memory when building, you might consider trying some or all of these suggestions:

General MPC information

The Makefile Project Creator (MPC) is a tool that takes platform and building tool generic files (mpc files) as input, which describe basic information needed to generate a "project" file for various build tools, including Make, NMake, Visual C++ 6, Visual C++ 7, etc. Please see USAGE, README for documentation on MPC.

A common usage for creating a Windows workspace containing just the core ACE and TAO libraries and executables is the following: 


C:> cd %TAO_ROOT%
C:> %ACE_ROOT%\bin\mwc.pl -type vc71 TAO_ACE.mwc

Replace vc71 with whatever project type you want to use. On Linux and other UNIX platform use the gnuace type: 


% cd $TAO_ROOT
% $ACE_ROOT/bin/mwc.pl -type gnuace TAO_ACE.mwc

This creates the appropriate GNUmakefiles. Additional information on how to obtain, configuration, and build ACE+TAO using MPC appear at the OCI FAQ.

If you are attempting to generate project files using MPC, and you get the following error message: 

ERROR: Unable to find the MPC modules in /builds/ACE_wrappers/MPC.
You can set the MPC_ROOT environment variable to the location of MPC.

You need to do one of the following:

  1. If you have already obtained MPC, either move it underneath the ACE_wrappers directory or set your MPC_ROOT environment variable to point to the full path of MPC.
  2. Check out MPC from the DOC Group subversion repository and set your MPC_ROOT environment variable.

You can check out MPC from the doc_group subversion server using the following command. 

svn co svn://svn.dre.vanderbilt.edu/DOC/MPC/trunk MPC

The README and USAGE files in the MPC/docs directory are an up-to-date source of documentation, however it is not a complete set of documentation. The TAO Developer's Guide from OCI starting with the 1.3a version contains more information about MPC.

The MPC chapter from the TAO Developer's Guide is available at http://downloads.ociweb.com/MPC/. Some of MPC has changed since this version, but it is largely accurate. An updated version will be available as newer versions of the TAO Developer's Guide are released. In the meantime, please see the README and USAGE files in the MPC directory.

Working with ACE in Eclipse

The Eclipse CDT C++ development environment can be used to develop ACE applications. You can configure a new CDT project to build ACE using either a local source distribution or checking out ACE from CVS in Eclipse. These are the steps to create the CDT project to build ACE.

To create an Eclipse project for ACE starting from CVS:

  1. In the "CVS Repository Exploring" perspective, navigate to the module containing ACE.
  2. Checkout the module using "Check Out As" and select the "project configured using the New Project Wizard" option.
  3. Select "Standard Make C++ Project" for the project type.
  4. Follow the steps outlined above, up to the point of running make, for building ACE on your platform. Use "path_to_your_eclipse_workspace"/"project_name" as your $ACE_ROOT.
  5. If you had to regenerate the makefiles using MPC, select the root folder for your poject and use the import wizard to add them to your project.
  6. Select the root folder for the project and use the "Create Make Target" wizard to setup the appropriate make command and options.
  7. Select the root folder and run "Build Make Target." This will build ACE.

To create an Eclipse project for ACE from a local source distribution:

  1. Launch the "New Project Wizard" in Eclipse.
  2. Select "Standard Make C++ Project" for the project type.
  3. On the project name page, uncheck the "use default" location option and replace the default path with the path to your source distribution.
  4. Follow the steps, up to the point of running make, for building ACE on your platform.
  5. If you had to regenerate the makefiles using MPC, select the root folder for your poject and use the import wizard to add them to your project.
  6. Select the root folder for the project and use the "Create Make Target" wizard to setup the appropriate make command and options.
  7. Select the root folder and run "Build Make Target." This will build ACE.

Advanced Topics

Non-static ACE_Object_Manager

The ACE_Object_Manager can be instantiated as a static object, can be instantiated on the stack of the main program thread, or can be explicitly instantiated and destroyed by the application with ACE::init () and ACE::fini (). The comments in the header file, ace/Object_Manager.h, as well as Section 1.6.3 in The ACE Programmer's Guide provide more detail.

NOTE: Special requirements are imposed on applications if the ACE_Object_Manager is instantiated, by ACE, on the stack of the main thread. This behavior is selected by defining ACE_HAS_NONSTATIC_OBJECT_MANAGER in ace/config.h. Again, see the ACE Object_Manager header file, ace/Object_Manager.h for more information. One of these requirements is discussed here, because it is so important. Please note that ACE_HAS_NONSTATIC_OBJECT_MANAGER is defined in the distributed ACE config.h headers for VxWorks and Win32.

The important requirement is that the program must declare its main function with two arguments, even if they're not used, and with int return type: 


int
main (int, char *[])
If you don't declare main exactly that way, then you'll see a link error about ace_main_i being undefined.

Alternatively, this feature can be disabled by commenting out the #define ACE_HAS_NONSTATIC_OBJECT_MANAGER in the ace/config.h. But, that will make repeated testing more difficult on VxWorks. And, you'd either have to call static constructors and destructors manually or unload/load the program between runs. On Win32, disabling the feature can possibly lead to shutdown difficulties.

WARNING: ACE_HAS_NONSTATIC_OBJECT_MANAGER assumes that your main function is named main. Any violation of this assumption is at your peril. If you really need to call your entry point something other than main, you'll need to construct and destroy the ACE_Object_Manager. The best way to do that is to call ACE::init () and ACE::fini (). Or, see the #define of main (int, char *[]) in ace/OS_main.h to see how ACE does that for entry points named main.

Cloning the Source Tree

On UNIX platforms, we typically like to support multiple platform builds using the same ACE source tree. This idiom is supported by ACE using the $ACE_ROOT/bin/create_ace_build.pl script. To clone the source tree, create ./build and ./build/{your build name} subdirectories under the ACE_wrappers directory. Then invoke the create_ace_build.pl script to clone the source tree using soft links from your build directory back to the actual sources. Here is an example:

% cd ACE_wrappers
% mkdir build build/build-SunOS5
% perl bin/create_ace_build.pl -a -v build-SunOS5
% cd build/build-SunOS5
% setenv ACE_ROOT $cwd
% make

This will establish a complete tree of links. In addition, make sure you set your LD_LIBRARY_PATH to $ACE_ROOT/lib:$LD_LIBRARY_PATH on SVR4 UNIX platforms.

When you do a make in the $ACE_ROOT 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.

See the comments at the top of the create_ace_build.pl script for further usage information.

Additional Build Tips for MVS

For all intents and purpose, MVS OpenEdition (OE) is another flavor of UNIX, therefore, the instructions under Building and Installing ACE on Unix can be used along with the following additional tips:

You can get a copy of GNU make that has been ported to MVS OpenEdition from the IBM OpenEdition web site. ACE's make scheme generates compile commands that have options and operands interspersed. By default, the c89/cc/c++ compiler expects all options to precede all operands. To get around this, you must set a special compiler environment variable (_CXX_CCMODE) to 1 which tells the compiler to allow options and operands to be interspersed.

Note that the environment variable LD_LIBRARY_PATH is called LIBPATH on MVS.

Shared objects are built a little different on MVS than on other UNIX implementations. This has been accounted for in the makefiles that come with ACE When the linker (via the cxx command) builds the libACE.so file it will also create a file called libACE.x. This is a side-deck file and it must be included in subsequent link edits with application code. For more information on this see the C/C++ MVS Programming Guide. If you want to build your application statically, i.e., using libACE.a instead of libACE.so, you can set ACELIB to ACELIB_STATIC in platform_mvs.GNU.

When the libACE.so file is built (via the MVS pre-linker and binder), you will get a rc=4 from the pre-linker. This is ok. This is due to some warnings about unresolved references which should get resolved during the link step. Note, however, there shouldn't be any unresolved references from the binder (linkage editor). You can get pre-link and link maps by uncommenting the PMAP and LMAP lines in the platform_mvs.GNU file.

Makefile Flags

GNU make provides many options to customize its operation. See its documentation for more information. One example is that for multi-cpu UNIX machines you will be able to build faster if you use:


% make -j n

which allows parallel compilation. The number n should typically be the number of CPUs. It is likely that builds will be faster even on single-CPU UNIX machines with make -j 2.

ACE further supports the following flags. They can be enabled either on the command line, e.g., "make purify=1", or added to your platform_macros.GNU. To disable the option, set the flag to null, e.g., "make debug=". Some flags support setting to 0 disable, e.g., "make debug=0". debug=1 is enabled in the platform files that are released with ACE.

Please note that the effects of a flag may be platform specific. Also, combinations of certain flags may or may not be allowed on specific platforms, e.g., debug=1 opt=1 is supported by g++ but not all other C++ compilers.

If you use Purify or Quantify: purify or quantify must be on your PATH. By default, ACE puts the Purify/Quantify caches below /tmp. To override that, set the PURE_CACHE_BASE_DIR variable, either in your environment or on the make make command line, to the destination directory for your instrumented libraries.

Flag             Description
----             -----------
debug            Enable debugging; see DCFLAGS and DCCFLAGS.
exceptions       Enable exception handling (not supported by all platforms).
include_env      Support old-style ACE_TRY_ENV declarations in methods.
                 This switch is necessary for compiling TAO applications
                 in the native exception configuration that were written
                 for TAO versions before 1.2.2.
                 In TAO 1.2.2, new macros were introduced that supercede
                 the direct ACE_TRY_ENV declarations. These are the
                 ACE_ENV_ARG macros that are defined in ace/CORBA_macros.h
                 and are documented in docs/exceptions.html.
                 This switch only affects the exceptions=1 configuration.
                 It is for backward compatibility only.
                 There will be warnings about unused _ACE_environment_variable
                 parameters when using include_env=1.
                 If possible, do not use it, but instead change your TAO
                 applications to use the ACE_ENV_ARG macros.
fast             Enable -fast option, e.g., with Sun C++.
inline           Enable ACE inlining.  Some platforms enable inlining by
                   default, others do not.
optimize         Enable optimization; see OCFLAGS and OCCFLAGS.
pace             Enable PACE as the underpinnings of ACE_OS.
probe            Enable ACE_Timeprobes.
profile          Enable profiling; see PCFLAGS and PCCFLAGS.
purify           Purify all executables.
quantify         Quantify all executables.
repo             Use GNU template repository (g++ with repo patches only).
rtti             Enable run-time type identification.  On some platforms,
                   it is enabled by default, so this is ignored.
shared_libs      If migrating from prior version use shared_libs_only
static_libs      If migrating from prior version use static_libs_only
shared_libs_only Only build shared libraries.  Ignored if no SHLIBs are
                   specified by the Makefile, as in performance-tests/Misc.
static_libs_only Only build static libraries.
threads          Build with thread support.
xt               Build with Xt (X11 Toolkit) support.
fl               Build with FlTk (Fast Light Toolkit) support.
tk               Build with Tk (Tcl/Tk) support.
qt               Build with Qt (Trolltech Qt) support.
ssl              Build with OpenSSL support.
rapi             Build with RAPI
split            Build the library by first splitting up the ACE source
                   to several files, with one object code entity for each
                   source file. This allows an application that is linked
                   with ACE to extract _exactly_ what it needs from the
                   library, resulting in a smaller executable.  Setting this
                   to 1 overrides debug to 0.

Usually, users do not need to be concerned with make targets.
Just enter "make" on the command line to build.  A few notable
targets are listed below.

Target             Description
------             -----------
show_statics       Lists all static objects in object files built for
                     current directory.  Only supported for g++.
show_uninit        Lists all uninitialized in object files built for
                     current directory.  Only supported for g++.

Building from git

If users are building from our Git repository the GNUmakefiles, and project files for building on various platforms will not be available. Git users are expected to generate them using MPC before building ACE, TAO or CIAO. We point out some suggestions below to get bootstrapped quickly.

Back to the ACE home page.

Last modified: Wed Jul 5 17:26:22 EST 2006