
     _________________________________________________________________

  Building and Installing ACE and Its Auxiliary Libraries and Services

    Synopsis

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

    Document Index

     * [9]Supported Platforms and C++ Compilers
     * [10]Installation Notes
     * [11]Compiling ACE with GNU g++
     * [12]Compiling ACE with egcs
     * [13]Building and Installing ACE
     * [14]Building and Installing ACE Network Services
     * [15]Building and Installing The ACE_SSL Library
     * [16]What Do I Need to Build for TAO?
     * [17]System Resource Requirements
     * [18]Advanced Topics
     _________________________________________________________________

  Platforms, C++ Compilers, and Support

   ACE  has  been  ported  to a large number of [19]platforms, using many
   different  compilers  over the years. The [20]DOC group, [21]Riverace,
   [22]OCI,  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 a potential target platform for
   ACE. If you have [23]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 to either the
   [24]ACE  Newsgroup or the [25]ACE mailing list and someone will try to
   help you fix the problems.

   The  responsibility  for  maintaining  ACE  across  this wide range of
   platforms  is  divided  among  a  few different groups: the DOC group,
   Riverace,  OCI,  and  the  ACE  user community itself. 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 [26]TAO's install document.

   CAPTION: Groups Involved in ACE Development and Support
   
   Group Platforms For more information
   DOC  Group  [27]Tested and used daily by the DOC group: Solaris 2.6, 7
   and  8  (many compilers excluding SunC++ 4.x) Windows NT 4.0, 2000, XP
   (MSVC++  6.x,  and 7.x, and Borland C++ Builder 5.0) Linux/Intel (many
   compilers),  Linux/IA64 (GCC). DOC sites at [28]UCI and [29]Washington
   University
   Riverace  Offers  support  services for many platforms including those
   above, HP-UX, AIX, and Windows CE. Riverace's [30]web site
   OCI Maintains ACE on certain platforms required for their TAO software
   and  service  offerings.  OCI's  [31]web  site and the TAO [32]install
   document
   Remedy  IT  Maintains  ACE on certain platforms required for their ACE
   and TAO service offerings. Remedy IT [33]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 Windows 95/98 using Borland C++ Builder
   4.0  and  later, and GNU g++ on MinGW and Cygwin; Digital UNIX (Compaq
   Tru64)  4.0  and  5.0; IRIX 6.x; UnixWare 7.1.0; SunOS 4.x and Solaris
   with  SunC++  4.x;  Linux  on  Alpha  and  PPC;  OpenMVS; Tandem; SCO;
   FreeBSD; NetBSD; OpenBSD; Chorus; OS/9; PharLap TNT Embedded ToolSuite
   9.1; QNX RTP and Neutrino 2.0; VxWorks; LynxOS; RTEMS

   Although  the  DOC group has provided outstanding, world-class 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  and  OCI offers 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  [34]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 [35]bug fixing policies
   followed  by  the  DOC  group are designed to strike a balance between
   their  many  [36]research projects and their commitment to the ACE+TAO
   [37]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, or OCI.
     _________________________________________________________________

  Installation Notes

     * Windows (Windows NT, 2000, XP, 2003, etc., and Windows '9x/ME) 
       All  of  ACE  has  been  ported  to  the Win32 API (which includes
       Windows  NT,  Windows  2000, and Windows '95/98/ME) and Win64. The
       entire  release  now  compiles using the Microsoft Visual C++ 6.0,
       and  7.1 (aka Visual C++ .NET 2003) compilers. ACE can be built as
       both  a  static  (LIB)  and dynamic (DLL) library, using the Win32
       installation process described below.
       Please see the [38]Non-static ACE_Object_Manager discussion below.
       We've  also added some support for [39]GNU g++ with MinGW, [40]GNU
       g++   with   Cygwin  [41]Borland  C++  5.5,  Borland  C++  Builder
       4.0/5.0/6.0  and  Borland  C++  BuilderX,  and IBM's VisualAge C++
       compiler.  Since  we  don't  have  these  compilers we rely on the
       ACE+TAO users community to maintain these ports. Therefore, please
       send email to the ACE mailing list if you run into problems.
     * Windows CE
       Take  a  look  at  ([42]CE-status.txt)  for up-to-date information
       about ACE on CE.
     * Solaris  2.6,  7,  8,  and  9  using  Sun  Sun 5.x, Forte 6 and 7,
       Centerline  C++  2.x,  GNU gcc 2.7.x and later (except 2.8.x), and
       KAI C++ 3.3/3.4.
       All  the  source  code  and tests should build and run without any
       problems  on  Solaris 2.6, 7, 8, and 9 platforms using the Sun C++
       compilers.  There  are  likely  to  be  build  problems with older
       versions or different patchlevels of Sun C++. Likewise, on Solaris
       with g++ you may need to use GNU as instead of /usr/ccs/bin/as, if
       you  want  -gstabs+  and -pipe support. Thanks to Susan Liebeskind
       <shl@janis.gtri.gatech.edu>  for  providing  the  following useful
       information:
       By  default, ACE uses both the Solaris and POSIX thread interface.
       To   disable   use   of   the   Solaris   thread   interface,  add
       -D_POSIX_PTHREAD_SEMANTICS     to     the     CFLAGS    in    your
       ACE_wrappers/include/makeinclude/platform_macros.GNU.    See   the
       Solaris Intro (3) man page for more information.
       To disable ACE thread support completely, build with the threads=0
       make  flag.  See  the  [43]Makefile  Flags  section below for more
       information on make flags.
       If  you use g++ or egcs on Solaris 7, you might need to rebuild it
       on  a  SunOS  5.7  (Solaris 7) host. Some versions of g++ and egcs
       provide  replacements for system header files. The replacements on
       older  SunOS  systems are not compatible with the SunOS 5.7 system
       headers. See [44]David Levine's Hints page for instructions on how
       to  build  egcs  on a SunOS 5.7 host, using a g++ or egcs that was
       built on an older SunOS host.
       The  Sun/C++ 5.0 compilers has several problems with templates, we
       have worked around most of them but this is not a compiler that we
       test very often. Hopefully as new patches for the compiler show up
       we will be able to make that our compiler of choice on Solaris.
     * 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
       $ACE_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   $ACE_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
       ACE  has  been  ported  to  AIX 4.3 and higher using the IBM C/C++
       Compiler 3.6.6, Visual Age C++ 5 and 6, and g++ 3.2.
       To  build  ACE  on  AIX  with Visual Age C++ 5 in incremental mode
       (i.e.  with  the IDE), use the $ACE_ROOT/ace/ace.icc configuration
       along  with  the  appropriate  version-specific  config file (e.g.
       config-aix-4.3.x.h).  All of the version-specific config files set
       the version number macros and include the general config-aix-4.x.h
       file  which  has  support for all of the OS versions and compilers
       supported on AIX. Using the general config file is the recommended
       practice  for  g++,  IBM  C/C++,  and  Visual  Age  C++ batch mode
       compilers.
       Visual  Age  C++  4  has also been supported on ACE 5.1, but is no
       longer supported. If you are still using this compiler, please use
       the  $ACE_ROOT/ace/ace-dll.icc  configuration file, along with the
       config-aix-4.3.x.h  ACE  config  file.  Beware,  however,  that it
       hasn't  been  tested.  BTW,  here's  a  technique  from Rob Jordan
       <[45]jordan@hursley.ibm.com>  that  can reduce the size of the ACE
       libraries  by  about  one  third,  and  can  also  be  applied  to
       applications.  It  works  by  optimising  the  sharing of template
       functions,  which  are  created  in an "unusual" way under AIX. It
       also speeds up compilation.
       Here's how to optimise the ACE library generation:
       Look  at  the  [46]Makefile in $ACE_ROOT/ace. Create a file called
       ACE_All_Src.cpp,  and  add  a  line to #include each of the source
       files  listed  under  FILES= in the Makefile. Create a file called
       ACE_All_Tmp.h  and  add  a  line  to #include each of the .h files
       listed  under  TEMPLATE_FILES=  in  the  Makefile.  Now update the
       Makefile so that FILES=ACE_All_Src and TEMPLATE_FILES=ACE_All_Tmp.
     * Linux
       ACE  has  been  ported  to  [47]Linux on Intel, Alpha, and PowerPC
       platforms.  If you use a RedHat 5.x distribution, it's best to use
       RedHat 5.1 or later. ACE works without any modifications on RedHat
       5.1  and  later,  and  on Debian 2.1 on both Intel and Alpha. Make
       [48]symbolic  links  to the include/makeinclude/platform_linux.GNU
       and  ace/config-linux.h  as  your platform_macros.GNU and config.h
       files,  respectively.  The same files can be used on PowerPC, with
       LinuxPPC 1999 (R5), with glibc 2.1.1.
       If  you  run  out  of  memory,  it's easy to add virtual memory on
       Linux. Please see the mkswap man page. You'll need at least 256 to
       300  Mb  of virtual memory (RAM + swap) to compile all of ACE+TAO.
       The  [49]System Resource Requirements section has some suggestions
       on how to reduce the memory requirement.
       The glibc 2.0 dynamic loader isn't thread safe. If you want to use
       the  Invocation  API  you'll  have to set LD_BIND_NOW=true. If you
       want to use dlopen, you should use RTLD_NOW. The dynamic loader in
       glibc 2.1 is thread safe.
       The  ACE  Tokens_Test  hangs  with  egcs  1.1b  on  Linux. It runs
       properly when built with egcs 1.0.2 and later. All other ACE tests
       run properly with these egcs 1.0.2 and later.
       NOTE:  The TAO NameService uses IP multicasting by default, though
       it is not required. IP multicast on Linux requires the following:
          + Enable IP multicast in the Linux kernel. It is enabled in the
            default  RedHat  5.1  kernel. In older distributions, you can
            enable  it by rebuilding your kernel with CONFIG_IP_MULTICAST
            enabled.
          + Enable  IP  multicast  in  ACE.  It  is enabled by default in
            ace/config-linux-common.h. If you don't use IP multicast, add
            #define  ACE_HAS_IP_MULTICAST  0  to your ace/config.h before
            building ACE.
          + There  must  be  a  network interface that is up and supports
            multicast. If you have linuxconf, it's easiest to use that to
            add  a network route for multicast (224.0.0.0) on one of your
            network  interfaces,  such  as eth0. If you don't have or use
            linuxconf,  try  adding a multicast routing table entry using
            something like this:
             # route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0

       With  RedHat  5.0,  you'll need some [50]updates and possibly some
       patches  to get ACE working with LinuxThreads. Some of the patches
       are  necessary  with  Alpha CPUs and with some older kernels. egcs
       1.0.1  can also be used, but it may need patches, described there,
       as well.
       NOTE:  Be  careful  when installing egcs on RedHat systems. If you
       don't  remove  your  old gcc and libg++ RPMs, it's best to install
       egcs  in  a different directory than /usr, such as /usr/local, and
       set your PATH and LD_LIBRARY_PATH accordingly.
       Some  of  the ACE tests fail on older, pre-glibc2 Linux platforms,
       such   as   RedHat   4.2.   The  problems  are  with  threads  and
       thread-specific storage.
     * SCO UNIX
       ACE  has been ported to SCO UNIX using the GNU g++ 2.7.2 compiler.
       Arturo  Montes  <[51]mitosys@colomsat.net.co> maintains this code.
       In addition, he also maintains a version of [52]FSU pthreads.
     * SGI IRIX 5.x and 6.x
       ACE used to build fine using the SGI C++ and GNU GCC compilers for
       IRIX 5.x. It has been ported to IRIX 6.x using the SGI MipsPro 7.1
       C++  compiler;  be  aware  that  in  IRIX 6.2 there is a number of
       patches  that  have  to be installed and exceptions appear to fail
       with the O32 ABI. Please check the config files for the details.
     * HP-UX 10.x and 11.x 
       HP sells 2 C++ compilers for HP-UX 10.x and 11.00:
          + HP  C++  -  this is CC, HP's cfront-based compiler. As of ACE
            4.4,  it  can  be  used,  but  some people have problems with
            templates.  Caveat emptor. It's been said that you should run
            version 10.24, if not later. ACE hasn't been tested with this
            compiler since the ACE 5.0 timeframe.
          + HP  aC++  -  this is aCC, HP's new, ANSI compiler. It handles
            ACE  very well. You should use version A.01.27 (or higher) on
            HP-UX 10.x and version A.03.37 (or higher) on HP-UX 11.
       On  HP-UX  10.20,  a  patch  is required to compile ACE. The exact
       patch  number  depends  on  the  platform  - check with HP's patch
       database  to locate the exact patch or its successor. For 9000 700
       series  machines  it  is  PHKL_8693 (s700 10.20 sys/time.h fix for
       select(2)/C++ defects).
       Also   see   further   notes   on   this  platform  at  Riverace's
       [53]Frequently Asked Questions page.
     * OSF/1 3.2 and 4.0 (a.k.a. Digital UNIX 4.0)
       The  Digital UNIX C++ 5.4 through 5.7 compilers have problems with
       ACE's  templates.  They  compile  the  lib  and  most  of the test
       programs, although they warn about template usage. Most tests run,
       some  dump  core.  If you use a 5.x version of cxx, be sure to set
       the CXX_VER variable to CXX_5, either on your make command line or
       in  an  environment  variable. The ACE Makefiles assume by default
       that the cxx version is 6.x or later.
       CXX  6.0  and  6.1 are much improved over 5.x: V6.0-020, V6.1-025,
       and  later  build  all  of  ACE  cleanly.  All  of  the  tests  in
       ACE_wrappers/tests  run  successfully  with  CXX  6.0 and CXX 6.1.
       Please note that problems have been reported with some versions of
       CXX  6.1,  notably  versions  -021  and  earlier. It's best to use
       V6.1-022 or later.
       NOTE:  if  you  use  Digital  UNIX  4.0f  or  later,  you must use
       ace/config-tru64.h      instead      of     ace/config-osf1-4.0.h.
       ace/config-tru64.h  can be used for all supported compilers on any
       version  of Digital UNIX after and include 4.0. And, with 4.0f and
       later     when     using     Digital    CXX,    you    must    use
       include/makeinclude/platform_tru64_cxx.GNU        instead       of
       include/makeinclude/platform_osf1_4.0.GNU.    GNU    gcc   2.7.2.1
       compiles without problems. All tests run (besides minor problems).
       Thanks  to  Thilo Kielmann <[54]kielmann@informatik.uni-siegen.de>
       and  David  Trumble  <[55]trumble@cvg.enet.dec.com>  for help with
       this port.
     * FreeBSD 
       FreeBSD is a fast evolving platform. However, it has the advantage
       of   having  standard  releases.  At  this  moment,  ACE  is  only
       perodically  tested  against  -stable  (3.1R) and we rely a lot on
       FreeBSD users' feedbacks.
       Notice  that  on  older FreeBSD, ld.so only looks for so libraries
       with  version  number  appended. ACE makefiles create symlinks for
       most   shared  libraries  if  versioned_so  is  defined  to  1  in
       $ACE_ROOT/ace with appropriate ACE version. However, this does not
       work  for  libACE.so  itself so you have to create it manually (If
       you figure out how to do this, please let us know) like this:
       ln -sf $ACE_ROOT/ace/libACE.so $ACE_ROOT/ace/libACE.so.4.5
       On newer FreeBSD (3.0 or later,) this is no longer necessary.
     * NetBSD
       Like  older  FreeBSD,  NetBSD's  ld.so also requires versioned .so
       files.
     * OpenBSD
       ACE has been ported to OpenBSD 3.1 and GNU g++ 2.95.3.
       As  with FreeBSD and NetBSD, OpenBSD requires versioned .so files.
       This  is  currently  handled  by the build files and no additional
       work is needed.
       ACE  has been ported to OpenBSD with and without pthreads enabled.
       When using pthreads, though, C++ exceptions must be disabled. This
       is  a  known  problem  with  the  current  release of OpenBSD (see
       www.openbsd.org, bug #1750). ACE emulated exceptions work fine.
       Compiling  TAO may require the user data segment size restrictions
       and  possibly  other  options  to  be  increased.  This is done by
       modifying the default user class in /etc/login.conf or by adding a
       new class and modifying the master passwer file accordingly.
     * UnixWare 
       Steve  Huston  <[56]shuston@riverace.com>  has  ported ACE to work
       with UnixWare 2.01 and g++.
       Ganesh  Pai  <[57]gpai@voicetek.com> subsequently did the port for
       version 2.1.2, also with g++.
       Phil  Mesnier  <[58]  mesnier_p@ociweb.com>  updated  the  port to
       support  UnixWare  7.1.0, with help from Michael Meissnitzer <[59]
       michael.meissnitzer@siemens.at>,       Christian      Klepp      <
       [60]christian.klepp@siemens.at   >  and  Engelbert  Staller  <[61]
       engelbert.staller@siemens.at>  Building  ACE (and TAO) on Unixware
       7.1.0   requires   a  very  specific  g++  build  environment.  In
       particular,  you  must  build  and  install g++ 2.95.2, along with
       binutils  2.9.1.  The order (and the declaration of configuration)
       is  extremely  important.  Using  the gcc compiler provided on the
       Skunkware  CD  on  a  pentium system, here is the recipe I used to
       build a working environment (as root):
  mkdir /usr/local/newgnu
< ftp and untar binutils-2.9.1 >
< ftp and untar gcc-2.95.2 >
  mkdir -p build/binutils build/gcc
  cd build/binutils
  ../../binutils-2.9.1/configure i386-sco-sysv4
  gmake  # takes a long time
  gmake install # this creates /usr/local/i386-sco-sysv4/...
  mkdir /usr/local/i486-pc-sysv5/bin
  cd /usr/local/i486-pc-sysv5/bin
  for a in /usr/local/i386-sco-sysv4/bin/*; do ln -s $a .; done
  #links all the newly installed utilities

  cd /usr/local/newgnu/build/gcc
  ../../gcc-2.95.2/configure --with-gnu-as --with-gnu-ld
  gmake bootstrap # takes a long time
  gmake install
  mkdir /usr/local/i586-UnixWare7.1.0-sysv5/bin
  for a in /usr/local/i386-sco-sysv4/bin/*; do ln -s $a .; done
       Once done, ACE and TAO will successfully build and link.
     * Chorus
       Wei Chiang <[62]chiang@tele.nokia.fi> has ported ACE to Chorus 3.1
       using GNU g++ 2.7.2.
     * LynxOS
       ACE builds and runs properly on LynxOS 3.0.0 for Intel and PowerPC
       targets.    ACE's   Naming_Test   fails;   it   is   disabled   in
       [63]ACE_wrappers/tests/run_tests.sh.
       If you run out of memory on LynxOS, these might help:
          + Increase  the  limits in /etc/starttab, then logout and login
            again. We use these limits:
# Data, stack, and core file limits (in Kbytes)
240000
80000
102400
          + Enable or expand virtual memory, with something like:
# mkcontig /swap 320
# prio 17 vmstart /swap
            See the mkcontig and vmstart man pages, and /bin/rc.
       Please  see  the  comments in the [64]ACE platform_lynxos.GNU file
       for  information  on,  and  an  example  of,  tailoring  for  your
       particular platform.
       We  actively maintain ACE on LynxOS 3.0.0. It should build and run
       on LynxOS 2.5, but we no longer test on that OS version.
       NOTE:  if  you  want to use IP multicast on LynxOS, be sure to add
       this line to your /net/rc.network, and reboot:
        /bin/route add "224.0.0.0" "$my_name"

       Dave Mayerhoefer <[65]davem@lynx.com> has ported ACE to LynxOS 2.5
       using  GNU  g++  2.7.2.  However,  you  may  need  to  apply  some
       [66]patches to LynxOS to get ACE working.
     * VxWorks
       [67]David  Levine  <[68]levine@cs.wustl.edu>  has  ported  ACE  to
       VxWorks  5.2/5.3/5.3.1/5.4 with the GreenHills 1.8.8/1.8.9 and g++
       compilers  that are distributed with VxWorks/Tornado. An anonymous
       contributor has also provided [69]notes for using ACE with VxWorks
       5.1..  It  is not possible to use VxWorks 5.4 and earlier with ACE
       anymore because the compilers delivered with 5.4 and earlier don't
       support the C++ features ACE needs.
       Tornado  2.2/VxWorks 5.5 support IP multicast. That is not enabled
       by  default  in  ACE  for  VxWorks, because it probably depends on
       kernel     configuration.    To    enable    it,    add    #define
       ACE_HAS_IP_MULTICAST to your ace/config.h.
       In  addition  to  all  of the other benefits of ACE, it helps work
       around  some  deficiencies  with  VxWorks 5.3/5.3.1. Some of these
       apply  only  with  g++,  at  least thru version 2.7.2. That is the
       version  that  is  shipped  with Tornado 1.0.1/ VxWorks 5.3.1. The
       problems are:
         1. The program entry point cannot be called "main" with g++. ACE
            renames  it  to  "ace_main"  (configurable  via  ACE_MAIN) on
            VxWorks.  While  this  may seem trivial, it is important with
            legacy code. ACE itself ran into this problem.
         2. argc/argv  isn't used with VxWorks entry points. ACE provides
            a  wrapper function that transparently converts shell command
            line arguments to argc/argv form. See [70]below for details.
         3. Unsigned long long support is not available with the g++ that
            is  distributed  with  Tornado  1.0.1/VxWorks  5.3.1, or with
            GreenHills 1.8.8. The documentation says that it is supported
            by  g++,  but  try  using it :-) Wind River technical support
            verified  that  it  doesn't work. ACE provides its own 64-bit
            unsigned  integer  type, ACE_hrtime_t, so you don't even have
            to worry about this problem if you use it.
         4. There  a  gory problem with munch that is severely aggravated
            by the presence of a static in the Wind River/g++ iostream.h.
            ACE  hides this and provides an easy-to-use workaround in the
            very  unlikely  situation  where it becomes a problem. Please
            see ace/config-vxworks5.x.h for more information.
       In  addition,  as  noted [71]below following the discussion of the
       g++  -fno-implicit-templates  option,  -fno-implicit-templates  is
       broken for x86 targets. And, -O2 is not supported on some targets.
       Please  note  that  ACE  uses  one of the spare fields in the Wind
       River  task  control  block, spare4, for thread- specific storage.
       This  field is specified in only one place, in ace/OS.i, so it can
       easily be changed to one of the other spare fields, if necessary.
       Versions   of  ACE  from  4.3.3  and  beyond  destroy  dynamically
       allocated  singletons  in  the  ACE  library.  But,  they  may not
       properly  destroy some static objects. If you have trouble running
       a  program  multiple  times,  it  may  be  necessary to unload the
       module, using unld, and reload it between runs. Alternatively, you
       could try calling cplusDtors and then cplusCtors between runs.
     * MVS OpenEdition
       All   of  ACE  has  been  ported  to  OpenEdition  by  Chuck  Gehr
       <[72]gehr@sweng.stortek.com>.  The  ACE library, all the tests and
       most  of  the  examples and apps build clean. There are still some
       problems that need to be ironed out:
       MVS  does  not  support the dynamic linking dl...() calls that the
       Service  Configurator  uses  to  dynamically  link services at run
       time.  As  a result, all the examples and apps that use a svc.conf
       file  (for  dynamically  configuring service objects) do not work,
       however, most of these apps can be built/run statically. Also, the
       Svc_Conf_l.cpp  and  Svc_Conf_y.cpp files are generated using flex
       and  yacc  on  a  ascii  (not ebcdic) machine and as a result they
       don't work very well with ebcdic svc.conf files. We should be able
       to  regenerate  these files on MVS but MVS doesn't have flex. This
       is something that needs to be done.
       Some  of the tests do not execute properly. This is a minority and
       over time the goal is to get to 100%.
       The  make scheme for some of the apps still doesn't work perfectly
       on MVS. This is mainly due to the way shared libraries are handled
       on MVS. See [73]additional build tips for MVS for more on this.
     * QNX Neutrino
       ACE  has been ported to [74]QNX Neutrino 2.0. We cross-compile for
       Neutrino   on   a   QNX4   host   using   g++   2.8.1,  using  the
       [75]ace/config-qnx-neutrino.h and
       [76]include/makeinclude/platform_qnx_neutrino.GNU    configuration
       files.  Many  of  the  ACE tests succeed, though some fail. As the
       porting effort progresses, we hope to eliminate these failures. If
       you know of fixes, please send them to us.
     * QNX RTP
       ACE  has been ported to [77]QNX RTP . We compile for QNX RTP using
       the   GCC  compiler  shipped  with  the  distribution,  using  the
       [78]ace/config-qnx-neutrino.h and
       [79]include/makeinclude/platform_qnx_neutrino.GNU    configuration
       files.  Many  of  the  ACE tests succeed, though some fail. As the
       porting effort progresses, we hope to eliminate these failures. If
       you know of fixes, please send them to us.
       WARNING:  Under  the  current  version  of  QNX  RTP  ACE fails if
       compiled with debug=1 (i.e. "-g" option in GCC).
     * PharLap TNT Embedded ToolSuite (ETS)
       ACE  has been ported to [80]PharLap's TNT Embedded ToolSuite (ETS)
       version 9.1. The port is being tested with Microsoft Visual C++ 6.
       To  build  for PharLap, use the ace/config-pharlap.h configuration
       file,  and  the instructions for building on Windows. Building the
       ACE  library  is the same as for regular Windows platforms, except
       you  choose  one of the PharLap ETS configurations to build within
       Visual  C++.  Only static library configurations are available for
       PharLap at this time. For an example of how to build binaries, see
       the  tests directory. The tests_pharlap_msvc.lnk file is a LinkLoc
       commands file that the ACE tests are built with. It is likely that
       local  sites  may  need  to  adjust  this  file  for  their target
       environment.
       If  you  have  any  fixes  or suggestions for improving this port,
       please contact [81]Steve Huston.
     * Mac OS X (10.2.x)
       ACE  builds  and  runs  on  Mac OS X 10.2.x, but the following are
       needed to build it:
       1. The latest version of the Apple Developer Tools (December 2002)
       2.   The   dlcompat  library  (obtained  either  through  Fink  or
       SourceForge)
       When creating $ACE_ROOT/ace/config.h for Mac OS X, you need to add
       the following if you obtained dlcompat via Fink:
       #define ACE_NEEDS_DL_UNDERSCORE
       You'll also need to do:
       setenv DYLD_LIBRARY_PATH $ACE_ROOT/ace:$ACE_ROOT/lib
       setenv MACOSX_DEPLOYMENT_TARGET 10.2
       Currently,  all  ACE  tests  pass  except  Process_Mutex_Test  and
       MEM_Stream_Test.  Also,  Mac  OS  X doesn't yet support *nix aio_*
       calls, and ACE does not know anything about Mach.
       The  work to port ACE to Mac OS X was done by several people, John
       Zorko <j.zorko@att.net
       > is only one of them.
     _________________________________________________________________

    Compiling ACE with GNU g++

   If you use the GNU GCC g++ compiler please note the following:
     * If  you  have  problems building shared libraries with egcs 1.1 or
       1.1.1 on SunOS 2.5 or 2.5.1 that look like this:
        /usr/ccs/lib/libgen.a(reg_compile.o): In function `_get_vars_storage':
        reg_compile.o(.text+0x30): relocation truncated to fit: R_SPARC_GOT13 f
ree

       the  suggested  workaround  is  to  comment  out the ACE_HAS_REGEX
       #define   in   ace/config-sunos5.5.h.   Or   better,   create   an
       ace/config.h that looks like:
      #ifndef ACE_CONFIG_H
      // ACE_CONFIG_H is defined by the following #included header.

      #include "ace/config-sunos5.5.h"

      #undef ACE_HAS_REGEX

      #endif /* ACE_CONFIG_H */

       We  don't know what causes the link problem, though the workaround
       solves it.
     * With  g++  2.8.0, an internal compiler error is raised when trying
       to  compile  ACE_Map_Manager  instantiations. One workaround is to
       disable optimization. The easiest way to do that is:
% make optimize=0
       Or, you can edit your include/makeinclude/platform_sunos5_g++.GNU,
       and comment out the OCFLAGS line.
     * ACE/TAO  don't seem to build well with g++ 2.8.1. We routinely use
       g++ 2.95.x and g++ 3.x, and recommend those versions or better.
     * Earlier  (prior to 2.95.2) versions of g++ may not compile certain
       parts of ACE correctly due to compiler bugs. Please upgrade to g++
       2.95.2 or greater.
     * Make  sure  to  update  your  gcc config.status file. This file is
       produced  when  installing  gcc; it specifies where to install the
       binary  files  that gcc uses. For example, it specifies whether to
       use  Solaris's  /usr/ccs/bin binary utils or GNU binary utils. The
       config.status file is an output of the gcc configure script; it is
       preferable  to  use  the  --prefix  option to configure instead of
       hacking its output.
     * If  you  are  getting  weird  link  errors when building libACE on
       Solaris  you  are probably using the GNU linker. Try using the Sun
       linker  (/usr/ccs/bin/ld)  instead.  Note that gcc first looks for
       the  GNU linker if it is installed along with gcc. The only way to
       not use the GNU linker is to delete it from the installation or to
       build  your  own  compiler with no linker. Be aware that you still
       need the libraries and includes of gcc.
       NOTE:  if  you do use the GNU linker, you might need to change the
       -G   flag   to   -shared   in   the  SOFLAGS  definition  in  your
       include/makeinclude/platform_macros.GNU.
     * Don't  get  too confused about contradictory statements in the gcc
       documentation. It was written by different people...
     * Make  sure  that  the  linker  invoked  by  gcc produces code that
       initializes  static  objects.  Please  see gcc's documentation for
       using collect2.
     * By  default,  gcc  (thru  version  2.7.2,  at least) uses implicit
       template instantiation. Besides wasting space, this breaks the use
       of  ACE_Singleton:  instead of one singleton instance, there could
       be  one  instance  per  object (.o) file that "sees" the template.
       Therefore,  we have overridden this default in ACE by enabling the
       -fno-implicit-templates     option     to     CCFLAGS    in    all
       include/makeinclude/platform_*.GNU files that set CXX to g++.
     * The  disadvantage  of  this approach is that you must add template
       specializations  for  all  templates that your application uses to
       your  own  code.  (The ACE libraries are self-contained: you don't
       need  to  add the templates that they use internally.) Examples of
       template  specializations occur in quite a few ACE .cpp files; see
       the end of [82]apps/Gateway/Gateway/Connection_Handler.cpp for one
       example.  An  easy  way to figure out what template instantiations
       are  need  is  to try to build your executable and pipe the output
       through c++filt. The linker will report the missing instantiations
       as  undefined symbols. Iteration may be necessary, if the template
       instantiations themselves reference other templates.
     * Alternatively,  you  could  use  the  -frepo option available with
       recent  egcs  versions  (2.90  and  later,  I  think)  instead  of
       -fno-implicit-templates.  (Patches  for earlier g++ versions might
       be  available  from  [83]Cygnus.) ACE readily supports this option
       for  application  code:  to enable it just add repo=1 to your make
       invocation, or to your include/makeinclude/platform_macros.GNU.
       The  size  of  the  ACE  library  is typically reduced by about 25
       percent    with    repo=1,    compared   to   the   default   with
       -fno-implicit-templates.    This    savings   results   from   not
       instantiating  unused  classes,  and from not instantiating unused
       member functions of those template classes which are instantiated.
       However,   repo=1   requires  care  if  your  application  creates
       libraries, in order to avoid multiple instantiations. We avoid the
       problem  in ACE (and TAO) by including all of the ACE object files
       into other ACE (and TAO) libraries. Please see the g++ FAQ and gcc
       manual for more information on the -frepo option.
       Furthermore,  it  appears that g++ may have problems instantiating
       all  templates  properly  with -frepo. We have worked around these
       problems    (by    using   explicit   instantiations   even   with
       ACE_HAS_GNU_REPO)  with  egcs  1.1.2.  A  quick  try with g++ 2.95
       showed  more  problems,  so  we don't support repo=1 with that g++
       version, yet.
     * The implementation of templates for g++ version 2.8 eliminates the
       restriction against static data members in template classes.
     * A  final  alternative  is  to  remove  the -fno-implicit-templates
       option from the CCFLAGS macro in your
       include/makeinclude/platform_macros.GNU,   and   thereby  use  the
       default g++ implicit template instantiation.
     * Thanks  to  Thilo Kielmann <[84]kielmann@informatik.uni-siegen.de>
       for  reporting  the  problem  with  ACE_Singleton  on g++, and for
       helping to find and implement these solutions.
     * On VxWorks only, g++ (thru version 2.9.6, distributed with Tornado
       2.2/VxWorks  5.5),  for  x86  targets,  -fno-implicit-templates is
       broken. In addition, -O2 is not supported on some targets.
     _________________________________________________________________

    Compiling ACE with egcs

     * ACE  transparently  supports  egcs,  for the most part. Please see
       [85]Compiling  ACE  with g++ in this document. And, please use the
       appropriate  g++ config and platform files for the OS on which you
       will use egcs.
     * WARNING:  The  default  behavior of the ACE Makefiles is to enable
       native  exception  support.  To  disable  exception  handling, add
       exceptions=0  to  your  make  command  line invocation, or to your
       $ACE_ROOT/include/makeinclude/platform_macros.GNU file.
     * egcs  may  have  trouble linking some executables, such as the ACE
       IOStream_Test,  if  its  static libraries are used. Though [86]Tim
       Rose  reports  that  egcs 1.1.1 static libraries work just fine on
       Solaris   2.6   with  patches:  105181-12,  105568-13,  105210-19,
       105591-05, 105395-04, and 105490-07.
       If  you  need or want to use egcs' shared libraries, build it with
       the --enable-shared egcs config option. The --enable-shared option
       is not an egcs run-time option. Build egcs in a way similar to the
       following example:
         $ ./configure --enable-shared
         $ make bootstrap

       Be  sure  to  set  your  LD_LIBRARY_PATH  environment variable, if
       necessary, to pick up those shared libraries.
     * On  DEC  Alpha,  egcs through version 1.03a, at least, may fail to
       build  ACE  if  debugging  (-g) is enabled. The fix is to edit the
       egcs  gcc/mips-file.c  file,  at line 976, and change PAGE_SIZE to
       8192.  Then  rebuild  ACE.  Thanks  to  [87]Ganesh  Pai  for  this
       information.
     * Sun  OS  5.6 using egcs1.1.2/egcs 2.95 with ld:Software Generation
       Utilities  -  Solaris/ELF  (3.0) as: WorkShop Compilers 4.X dev 18
       Sep 1996
       You  could  come  across  weird  external  symbol  linker  errors.
       Example:
      -I/opt/ace/SunOS-1.0 -DACE_HAS_EXCEPTIONS  -o Cached_Accept_Conn_Test
      .obj/Cached_Accept_Conn_Test.o  -L/opt/ace/SunOS-1.0/ace -L./  -lACE
      -lsocket -ldl -lgen -lnsl -lposix4 -lthread
      ld: warning: relocation error: R_SPARC_32: file
     .obj/Cached_Accept_Conn_Test.o: symbol
       __t21ACE_Cache_Map_Manager7Zt30ACE_Refcounted_Hash_Recyclable1Z13
       ACE_INET_AddrZP18Client_Svc_HandlerZt23ACE_Hash_Map_Manager_Ex5Zt
      30ACE_Refcounted_Hash_Recyclable1Z13ACE_INET_AddrZt8ACE_Pair2ZP18
      Client_Svc_HandlerZUiZt8ACE_Hash1Zt30...
       external   symbolic  relocation  against  non-allocatable  section
       .stab; cannot be processed at runtime: relocation ignored
       Solution:
       Install   the   "binutils"   package   from   GNU   (www.gnu.org);
       specifically, "as" and "ld".
       Conclusion:
       Perfect build stats:
       OS: Kernel version: SunOS 5.6 Generic 105181-03 December 1999.
       compiler: gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
       loader:   GNU   ld   version  2.9.1  (with  BFD  2.9.1)  Supported
       emulations: elf32_sparc
       assembler:  GNU  assembler  version  2.9.1 (sparc-sun-solaris2.6),
       using BFD version 2.9.1
       Thanks to [88]John Gathright for providing this information.
     * Compiling using the -fsquangle option helps to shorten long symbol
       names and is a boon to linkers and assemblers which cant grok long
       names. Thanks to [89]Skye Sweeney for trying it out and [90]Ossama
       Othman for discovering the option with egcs.
       Heres  a  note  on  how  to  go  about  this  (contributed by Skye
       Sweeney):
       1) -fsquangle the name is a combination of squash and mangle!
       2) -fsquangle compresses the mangled names.
       3)  All  libraries  must  be  compiles with the option. You cannot
       simply  compile  modules  that  have  large  names  with  it. This
       includes system libraries and vendor libraries like RogueWave.
       4)  The  "simple"  solution  is  not  to  add  the  option to each
       makefile,  but rather recompile the compiler to have the option on
       by  default.  This  is  done by editing the file `gcc/cp/decl2.c',
       setting `flag_do_squangling = 1', then rebuilding the compiler and
       libraries.
       5)  After many false starts and linking snafus, I can recompile my
       ACE/TAO/RogueWave/Lex/Yacc 100 Meg application.
     _________________________________________________________________

  Building and Installing ACE

   The following explains how to build ACE on [91]UNIX and [92]Windows.

    General Rules

     * Many  features  in  ACE can be modified by defining some macros in
       $ACE_ROOT/ace/config.h.  These  macros should always appear before
       including your platform specific config file.
     * However,  if  you  want to undefine/redefine macros defined in the
       platform  specific config file, these #undef should come after the
       config file.
     * If  you're  planning  to  build ACE on multiple platforms, you may
       want to consider [93]cloning the source tree before you start.
   ___________________________________

    Building and Installing ACE on UNIX

   As  of  ACE 5.4, you can choose between two methods of building ACE on
   UNIX:
    1. [94]GNU Autoconf
    2. [95]Traditional ACE/GNU Make Configuration

   The  [96]build  process for Windows is different from both of the UNIX
   methods.

      Building ACE with GNU Autoconf

   GNU  Autoconf  support  has  been partially present in a number of ACE
   versions.  However, ACE 5.4 was the first version that supported it in
   earnest.  There  are  still  a  few  problems with this method, so you
   should be careful to test the resulting ACE library before using it in
   your  applications. The traditional configuration method is still more
   reliable. Any help you can lend to improve the ACE build process using
   GNU  Autoconf would be very much appreciated. Please send any fixes to
   the [97]ACE usersmailing list.

   The  ACE  kit  has been bootstrapped so you do not need to install the
   GNU  Autotools  (autoconf,  automake,  libtool)  unless  you  want  to
   participate  in testing and developing this process further. To simply
   configure and build ACE, do:
    1. cd to the top-level ACE_wrappers directory.
    2. Create a subdirectory to hold your build's configuration and built
       ACE version, and then change to the new directory:
       mkdir build
       cd build

       Note that you do not run the create_ace_build utility mentioned in
       the  [98]Cloning  the  Source  Tree  section. The configure script
       takes care of creating all files and links that are needed.
    3. Configure ACE for your platform by issuing the following command:
       ../configure [options]

       options can be a variable setting (such as setting CXX to your C++
       compiler  command)  any  standard GNU configure options, or any of
       the  following  ACE  configure  options  (default  values  are  in
       parentheses):
          + --enable-alloca (no): Enable alloca() support.
          + --enable-debug (yes): Build ACE with debugging support.
          + --enable-exceptions  (yes):  Build  ACE  with  C++  exception
            support compiled in.
          + --enable-fast  (no):  Use  the Sun C++ -fast option to build.
            Only used on Solaris.
          + --enable-inline (yes): Enable inline functions.
          + --enable-optimize (yes): Enable building optimized.
          + --enable-prof (no): Enable profiling support.
          + --enable-purify  (no):  Build  with  support for IBM Rational
            Purify.
          + --enable-quantify  (no):  Build with support for IBM Rational
            Quantify.
          + --enable-repo  (no):  Enable  the GNU g++ -frepo option. Only
            useful for pre-3.0 g++ and egcs.
          + --enable-rtti   (yes):   Compile   with   C++  run-time  type
            information RTTI support.
          + --enable-stdcpplib (yes): Build with support for the standard
            C++ library, as opposed to the older iostreams library.
          + --enable-log-msg-prop   (yes):  Enable  ACE_Log_Msg  property
            propagation to ACE-created threads.
          + --enable-logging (yes): Enable the ACE logging macros.
          + --enable-malloc-stats  (no):  Compile  in additional code for
            collecting memory allocation statistics.
          + --enable-pi-pointers   (yes):   Enable   position-independent
            pointers for shared memory classes.
          + --enable-probe (no): Enable the ACE_Timeprobe class.
          + --enable-reentrant  (yes): Enable use of platform's reentrant
            functions.
          + --enable-static-obj-mgr   (yes):   Enable  use  of  a  static
            ACE_Object_Manager.
          + --enable-threads (yes): Enable threading support.
          + --enable-verb-not-sup (no): Enable verbose ENOTSUP reports at
            run time.
          + --enable-trace (no): Enable ACE execution tracing support.
          + --enable-xt-reactor    (no):    Enable    support   for   the
            ACE_XtReactor class.
          + --enable-fl-reactor    (no):    Enable    support   for   the
            ACE_FlReactor class.
          + --with-gperf  (yes):  Build  the implementation of gperf that
            comes with ACE.
          + --with-rmcast  (yes):  Include  the  ACE_RMCast  library when
            building ACE.
          + --with-qos  (no):  Include  the ACE_QoS library when building
            ACE.
          + --with-ssl  (yes):  Include the ACE_SSL library when building
            ACE.  Requires  the  SSL components to be available using the
            compiler's and linker's default search directories.
          + --with-tli-device  (/dev/tcp):  Specifies the device name for
            opening a TLI device at run time.
    4. Build ACE by typing make.
    5. (Optional) Install ACE by typing make install.

      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  [99]GNU  make 3.79.1 or greater on your system (available
       via  anonymous  ftp  from  prep.ai.mit.edu  in  the  pub/gnu/make/
       directory). You must use GNU make 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 instance,
       in my .login file for TSCH/CSH I have the following entry:
      % setenv ACE_ROOT /home/cs/faculty/schmidt/ACE_wrappers

       BTW,  if you're running BASH or Bourne Shell you'll need to do the
       following:
      % 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 (again assuming TCSH/CSH):
      % setenv ACE_ROOT $cwd

    3. Edit  the  $ACE_ROOT/ace/OS.h  file  to update things like default
       hostname   and  port  numbers  you'd  like  the  programs  in  the
       $ACE_ROOT/{apps,tests}   directories  to  use  by  default.  Note,
       however  that you can normally skip this step because the defaults
       are typically fine for most systems.
    4. 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-sunos5-sunc++-4.x.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 me email if you get it working so I
       can add it to the master ACE release.
    5. 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_sunos5_sunc++.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 paltform-specific configuration.
    6. Note  that because ACE builds shared libraries, you'll need to set
       LD_LIBRARY_PATH to whereever you put the binary version of the ACE
       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

    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 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  [100]$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  [101]"one-button"  tests  in
       [102]$ACE_ROOT/tests/.   Finally,   if  you're  also  planning  on
       building  [103]TAO,  you  should build the [104]gperf perfect hash
       function generator application in [105]$ACE_ROOT/apps/gperf/.
    8. If  you need to regenerate the Svc_Conf_y.cpp file, you'll need to
       get  [106]Berkeley YACC. However, you should rarely, if ever, need
       to do this.
   ___________________________________

    Building and Installing ACE on Windows

   Below  are instructions for building ACE with [107]Borland C++Builder,
   [108]Microsoft Visual C++, [109]Cygwin, and [110]MinGw.

   First, if you are upgrading from an older release, clean up everything
   and  rebuild  from  scratch  to  ensure  that  everything  is  rebuilt
   correctly.  You  might have to manually go through the ACE directories
   and delete all *.obj, *.dll, *.lib, *.ilk, *.pdb, *.idb, *.ncb, *.opt,
   and *.exp files in order to start over from scratch (the Clean command
   in MSVC may not do this).

   ACE  contains  project  files  for  Microsoft  Visual C++ 5.0 or later
   (*.dsw)  and  IBM's  VisualAge  C++  compiler  (*.icc). There are also
   Makefile.bor  files  to compile ACE, the ACE one-button tests, and TAO
   with Borland C++ Builder.
   ___________________________________

    Building and Installing ACE on Windows with Borland C++

   If you are building for a machine without a network card, you may want
   to check [111]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"
       If you are building for Windows NT 4, Windows 2000, or Windows XP,
       then  you  can start without any more changes. If you are building
       on Windows 9x/Me, then you should add the line
       #define ACE_HAS_WINNT4 0
       before the #include statement in ACE_ROOT\ace\config.h and it will
       turn off some WinNT/Win2K-specific code in ACE.
    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. Set  the  BCBVER  environment vairable to the main version of your
       Borland  C++  compiler.  Currently  4, 5, and 6 are supported. For
       example:
       set BCBVER=5
    6. Change to the ACE_ROOT\ace directory.
    7. Build release DLLs for ACE by going:
       make -f Makefile.bor
    8. 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 static version of
       ACE
       set STATIC=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 that
       is  build  against  the  VCL-compatible run-time library. This can
       only be used with BCB version 4
       set PASCAL=1
       Set the environment variable below to build a version of ACE using
       the C++BuilderX preview compiler. This compiler isn't supported at
       this  moment  but  by  setting  this  environment variable the new
       compiler is used and you can expirement with this compiler.
       set CBX=1
       You can then start the build with the command
       make -f Makefile.bor
       You  may  also  enable the options by passing them as command line
       options to make, for example:
       make -f Makefile.bor -DDEBUG -DPASCAL
    9. Optionally install the ACE header files, libraries and executables
       for  use  in  your  applications. Here we are installing them into
       C:\ACETAO:
       make -f Makefile.bor -DINSTALL_DIR=C:\ACETAO install

   These  instructions  do  not  cover all possible build configurations.
   Please  see  [112]http://www.tenermerx.com/tao_bcb/index.html for more
   detailed  information  on  building and using ACE+TAO with Borland C++
   Builder.

   If  you  are  using  C++Builder  4, then the libraries built using the
   above  instructions  are  intended  for  use  with  generic console or
   windows  applications  and  they  link  against  the corresponding C++
   runtime library. VCL applications created using BCB4's RAD environment
   must  link  against  the VCL-compatible (ie pascal-compatible) runtime
   library.   To   tell   the  difference  between  these  libraries  the
   VCL-compatible  ones  have a 'p' in the suffix (i.e., 'p' for pascal).
   To build VCL compatible libraries try

set PASCAL=1
make -f Makefile.bor

   The  Borland  C++  Builder 4.0/5.0/6.0 port has been done by [113]Jody
   Hagins, [114]Christopher Kohlhoff and [115]Johnny Willemsen.

   ACE TESTS

   The tests are located in ACE_ROOT\tests. You build the tests using the
   Makefile.bor file, that is:

     make -f Makefile.bor

   Once you build all the tests, you can run the perl script:

     run_test.pl -ExeSubDir Dynamic\Release

   in the tests directory to try all the tests. You need to make sure the
   ACE  bin  directory  (in this case ACE_ROOT\bin\Dynamic\Release) is on
   the path before you try to run the tests.
   ___________________________________

    Building and Installing ACE on Windows with Microsoft Visual C++

   Note  concerning MSVC 5.0 and Service Pack 3: There has been confusion
   regarding  MSVC  5 and its Service Pack 3. Some ACE users have, in the
   past,  had  problems  with SP3 that were not present in SP2. Thanks to
   the  diligent  efforts  of [116]Bill Fulton, the mystery appears to be
   solved.  The  key?  (Oh,  this  is a good one...) It would appear that
   there  are actually multiple versions of SP3 in existence. The earlier
   ones  have  the  bug, while later ones have it fixed. The service pack
   downloadable from Microsoft's web site as of June 16, 1998 works fine.
   The  CD  containing  SP3,  if it has part number X03-50158 on the disc
   (the  part  number  on  the  jacket is probably different), also works
   fine.  Note, however, that regardless of the version of SP3, there are
   some  STL  bugs  in  SP3  which  you  should get corrected. Please see
   [117]http://www.dinkumware.com/vc_fixes.html for details. Thank you to
   [118]Ben Eng for the pointer to the STL fixes.

   Right  now there is a SP4 (and hopefully only one of them) which fixes
   a deadlock problem in the STL.

   We  no  longer  actively support MSVC++ 5.x or earlier. ACE might work
   with these compilers but probably not without a bit of effort.

    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. Now load up the project file for ACE (ACE_ROOT\ace\ace.dsw).
    4. Each  project will contain several different configurations. These
       are  a  mixture  of Debug/Release, MFC/Non-MFC, and Static/Dynamic
       library  versions.  Make  sure you are building 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\bin in your PATH whenever you run programs that uses ACE.
       Otherwise you may experience problems finding ace.dll or aced.dll.
    5. If  you  are building for Windows NT 4 or later (Windows 2000, XP,
       etc.)  then you can start building without anymore changes. If you
       are building on Windows 9x/Me, then you should add the line
       #define ACE_HAS_WINNT4 0
       before the #include statement in ACE_ROOT\ace\config.h and it will
       turn off some WinNT/Win2K-specific code in ACE.
    6. If you want to use the standard C++ headers (iostream, cstdio, ...
       as defined by the C++ Standard Draft 2) that comes with MSVC, then
       add the line:
       #define ACE_HAS_STANDARD_CPP_LIBRARY 1
       before the #include statement in ACE_ROOT\ace\config.h.
    7. 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.
    8. Static version of ACE libraries are build 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.)
    9. 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 [119]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 workspace in
   that directory to build all the tests (tests.dsw)

   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

   WIN32 ALPHA CONFIGURATIONS

   The  project files for Visual C++ no longer contain any configurations
   targetted  to  Windows NT on the DEC Alpha. Below are the steps needed
   to recreate the Alpha configurations:
    1. Load the project on the Alpha machine.
    2. Go to the Build menu and then select Configurations.
    3. Select the project that you want to convert.
    4. Click on Add.
    5. Select the x86 configuration to "Copy settings from" (either Debug
       or Release versions).
    6. Prepend   "Alpha   "   to   the   beginning   of  the  name  under
       "Configuration".
    7. Click OK.
    8. Close the "Configurations" window.
    9. Now go to the Project settings.
   10. For  the  General  Settings,  change  the  output  directories  to
       standard  ACE  output  directories.  Intermediate  Directories are
       "Debug"  and  "Release"  in most cases. The Output Directories are
       blank,  except for Release versions of executables, in which it is
       also "Release".
   11. For  the  C/C++  Settings,  make  sure  that the Code Generation's
       runtime   library   is   set  to  "Multithreaded  DLL"  or  "Debug
       Multithreaded DLL".

   Note:  MSVC 6 has a bug where if a .dsp is converted from version 5 to
   6  on  x86,  the  Alpha configuration can get corrupted. This seems to
   happen  when  additional  include or library directories are specified
   using  backslashes  instead  of  forward  slashes. If this occurs, the
   easiest way to fix it is to recreate it.
   ___________________________________

    Building and Installing ACE on Win32 with MinGW

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

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

   You  will  need  the  MinGW build tools and libraries, downloable from
   [125]http://www.mingw.org.  For  our  build  we required the following
   packages:

     gcc, binutils, ld, libbfd, mingw-runtime, w32api.

   You  will  also need GNU make for Win32 and the set of UNIX tools that
   the ACE UNIX build system uses (this include but is not limited to sh,
   rm,  cp).  For  this purpose you can grab the [126]Cygwin distribution
   from [127]http://cygwin.com.

   Be  careful,  because Cygwin includes it's own version of the compiler
   and  build  tools,  you will need to have the MinGW build tools before
   the  Cygwin set on you PATH environment variable (more on this later).
   The steps we followed in the build are:
    1. Install   Cygwin   (this  can  be  easy  downloading  and  running
       [128]setup.exe from the Cygwin site).
    2. Install  the  MinGW  tools.  Download all the needed packages (see
       [129]above)  and  unpack  them  on  the  same  base directory, say
       c:/mingw32.  If  some  of  the packages are distributed on .tar.gz
       format, you may need to use the Cygwin version of the tar utility.
    3. Open  a  Cygwin  shell. Set your PATH environment variable so your
       MinGW's bin directory is first:

       % export PATH=//c/mingw32/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:/mingw32/bin''  because,  for  Cygwin, ``:'' is path separator
       character, as in UNIX.
    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


       Note  here  you  can't  use the ``//X'' Cygwin notation as this is
       seen  by  MinGW'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.
    5. Create  a file called config.h in the $ACE_ROOT/ace directory that
       contains:

       #include "ace/config-win32.h"


       If  you  are  building for Windows 9X/Me (ie, not WinNT or Win2K),
       you will need to add:

       #define ACE_HAS_WINNT4 0


       before the #include line. Also, if you don't have Winsock 2 (check
       the   SYSTEM   and/or   SYSTEM32  subdirectories  of  the  windows
       instalation directory for ws2_32.dll), you will need

       #define ACE_HAS_WINSOCK2 0


       before  the #include line. On NT 4, Windows 98 and later versions,
       you  surely have Winsock 2. In Windows 95, including OSR2, you may
       don't  have  it if it wasn't specially installed. You may download
       it  from  the [130]microsoft site. This is recommended as much ACE
       functionality  depends  on  Winsock  2,  and ACE without Winsock 2
       support is tested very infrequently.
    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.
    7. 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  MinGW  follows  the MinGW convention, that
       resembles UNIX.
       If you want static libs also, you may run:

       % make static_libs=1


    8. The  same  rules  for Win32 search of DLLs apply for MinGW. 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/mingw/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 [131]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 [132]here first.

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

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

     gcc (version 3.2.3), cygipc, make, perl.

    1. Install   Cygwin   (this  can  be  easy  downloading  and  running
       [137]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


       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=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  (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=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 [138]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 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 [139]Unix
   instructions  above  to  build  ACE  and the applications that use it.
   Please see below for more information on [140]building ACE on NT hosts
   for VxWorks targets.

   A  few  notes  on  VxWorks  builds (thanks to [141]Paul von Behren for
   these notes):

     * VxWorks  builds are done with a cross compiler, i.e., the compiles
       are  done  on  a  workstation  creating  object  modules which are
       downloaded and loaded into the VxWorks target system.
     * C++  object  modules  must  be post-processed by a VxWorks utility
       called    "munch."    ACE    includes   a   perl   script   called
       [142]$ACE_ROOT/bin/ace_ld,  which  is  called  from the Makefiles,
       replacing the traditional ld step. You must have perl installed to
       use  ace_ld.  If  perl  is  not  on  your path, you'll have to set
       PERL_PATH  to  the  full path (including perl.exe), either in your
       $(ACE_ROOT)/include/makeinclude/platform_macros.GNU   or  in  your
       environment.
     * Wind  River  provides  GCC/G++  cross-compilers  for the supported
       target   platforms.  The  executables  are  named  cc<target>  and
       g++<target>; for example, ccppc and g++cpp for PowerPC targets.

   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.x_g++.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.

   With  g++,  $ACE_ROOT/bin/ace_ld  is  used  to  munch object files and
   libraries  to  set  up  calls  to static constructors and destructors.
   bin/ace_ld requires perl on the host platform.

   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
   [143]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.

   The ACE [144]tests write their output files in a directory named log/,
   below the current (tests) directory. If you don't have NFS included in
   your   VxWorks   kernel,   you   can  use  these  steps,  provided  by
   [145]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_tests.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 < run_tests.vxworks from this target shell.

   [146]Kirk  Davies  provided this approach for running the ACE tests on
   Tornado II:
     * Under  Tornado  II, I set up the Target Server File System (TSFS),
       and the test logs get written to the log subdirectory under that.
     * You have to set an environment variable before running the tests:
putenv("ACE_TEST_DIR=/tgtsvr")

      Building Shared Libraries for VxWorks.

   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=1 (not 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 [147]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 [148]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=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.

      Building ACE on Tornado/NT hosts for VxWorks targets.

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

   NOTE:The  make  (version 3.74) that is provided with Tornado II cannot
   be used to build ACE. Use Cygnus' make (version 3.75) instead.)

   NOTE:Optimization is enabled be default in
   [152]platform_vxworks5.x_g++.GNU.   However,   the  compiler  that  is
   shipped  with Tornado II has trouble compiling some files with -O2. To
   disable  optimization  for  an individual file, just add optimize=0 to
   your make invocation when compiling that file.

   Using the Cygnus tools, this approach works:
     * You'll  build  both  your  NT  and VxWorks executables in the same
       workspace   (directory  hierarchy).  This  works  because  the  NT
       compiler  and  ACE's  Makefiles  put  their  output  in  different
       directories.
     * Set  up  your ACE_wrappers/include/makeinclude/platform_macros.GNU
       as  usual  for VxWorks. See [153]the g++/VxWorks platform file for
       more information.
     * Create an ACE_wrappers/ace/config.h file that looks something like
       the  following.  tao_idl  should  be  built  to not support native
       exception handling, because that's not available on VxWorks.
#if defined (_MSC_VER)  ||  defined (__BORLANDC__)
# include "ace/config-win32.h"
# undef ACE_HAS_EXCEPTIONS
#else
# include "ace/config-vxworks.h"
#endif
     * Set  your  ACE_ROOT,  CPP_LOCATION,  WIND_BASE, and WIND_HOST_TYPE
       environment variables.
     * Build for NT, then build for VxWorks.

   A few additional Windows Notes, from Paul von Behren:

     * Cygnus  has  created  a  Win32  API  which  is  compatible  with a
       "generic" Unix environment. Using this library, they have ported a
       large  collection  of  GNU tools to WinNT/95 - including a port of
       gcc/g++.  See [154]http://www.cygnus.com/misc/gnu-win32/ A related
       link is [155]ftp://ftp.cygnus.com/pub/gnu-win32/latest/
     * To    set   up   the   command-prompt   build   environemnt,   run
       Tornado\host\x86-win32\bin\TorVars.bat.  This  is  done implicitly
       within the Tornado IDE.
     * To   run   ace_ld,   you   still   need   perl   installed  -  see
       [156]http://www.activestate.com/software/default.htm  for  Windows
       perl.
     * The  Tornado  IDE will use a standard Makefile for project builds,
       but  does  not  have a GUI interface for managing the Makefile. By
       default,  it will use rules from Makefile in the current directory
       and  you  can  configure it to add certain Makefile targets to the
       project. If you have ACE_ROOT defined before starting Tornado, you
       can  specify  an ACE Makefile as a Tornado target and Tornado will
       then call make from the menu.

   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 NT VC++5.0 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.x_g++.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=1

      TAO on NT Tornado host, VxWorks target.

    1. Build  ACE  and  TAO_IDL  in the NT tree as already documented. As
       mentioned  above,  I  put aced.dll in /bin. 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

      [157]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)  PERL:  Active  State's  ActivePerl  5.6.0.618  for NT available as
   freeware from
   http://www.ActiveState.com/download/contrib/Microsoft/NT/InstMsi.exe

   2) Tornado II .Release V 9904 from Windriver.

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

   http://www.cygwin.com/

   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"

   #undef ACE_HAS_EXCEPTIONS

   #else

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

   #define ACE_HAS_IP_MULTICAST

   #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.x_g++.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.dsw 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.dsw.
   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=1

   This  will  build  your  ace  library libACE.a for VxWorks. If you use
   option  shared_libs=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=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 Network Services

   The  following  explains how to build the ACE [158]network services on
   [159]UNIX and [160]Win32.
   ___________________________________

    Building and Installing ACE Network Services on UNIX

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

    1. Build and install ACE on UNIX as described [162]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
       [163]$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
       [164]$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 [165]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
       [166]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 on RTEMS

export RTEMS_MAKEFILE_PATH=/opt/rtems/CPU-rtems/BSP
# setup the build structure
cd ACE_wrappers

# create the host (e.g. Linux in this case) build tree
./bin/create_ace_build Linux_g++
cd build/Linux_g++/ace
ln -s ../../../ace/config-linux.h config.h
cd ../include/makeinclude
ln -s ../../../../include/makeinclude/platform_linux.GNU platform_macros.GNU
cd ../../../..

# create the target build tree
./bin/create_ace_build rtems
cd build/rtems/TAO
/bin/rm -r TAO_IDL
ln -s ../../Linux_g++/TAO/TAO_IDL .
cd ../ace
ln -s ../../../ace/config-rtems.h config.h
cd ../include/makeinclude
ln -s ../../../../include/makeinclude/platform_rtems.x_g++.GNU platform_macros.
GNU
cd ../../../..

# build the host side of things
cd build/Linux_g++
export ACE_ROOT=`pwd`; export LD_LIBRARY_PATH=`pwd`/ace:`pwd`/lib:$LD_LIBRARY_P
ATH
cd ace
make

# optionally build the ACE tests
cd ../tests
make

cd ../TAO
make

# build the target side of things
cd ../rtems
export ACE_ROOT=`pwd`
cd ace
make
cd ../tests
# build rtems_init.o by hand
make -f  ../include/makeinclude/Makefile.rtems rtems_init.o
make
cd ../TAO
make
   ___________________________________

    Building and Installing ACE Network Services on Win32

   Once  again,  there are supplied project for MSVC 5.0 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
   [167]OpenSSL  distribution.  Then  the  ACE_SSL  library must 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, then set the
       following variables in your platform_macros.GNU file:

   PLATFORM_SSL_CPPFLAGS  Platform preprocessor options for OpenSSL (e.g.
   -I...)
   PLATFORM_SSL_LDFLAGS Platform linker options for OpenSSL (e.g. -L...)
   PLATFORM_SSL_LIBS Platform libraries required with OpenSSL (e.g. -lssl
   -lcrypto)
    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   OpenSSL   include/header   directory  path  under  the
       Directories  tab  -  Include  Files  setting in the Tools->Options
       dialog.    A    typical    value    would   be   something   like:
       openssl-0.9.6\inc32
    2. Set the OpenSSL library directory path under the Directories tab -
       Library  Files  setting  in  the  Tools->Options dialog. A typical
       value would be something like: openssl-0.9.6\out32dll
    3. Open  the  ACE.dsw  workspace,  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.

  Borland C++

   Support  for building TAO's SSLIOP pluggable protocol with Borland C++
   does  exist.  First  get  a  patch  for  the  Open  SSL  makefile from
   [168]http://www.tenermerx.com/tao_bcb/index.html.   Then   build   the
   OpenSSL  library.  When you use the DLL version of ACE+TAO you have to
   build  a  DLL  version  of  OpenSSL. Then you must set the environment
   variable  SSL_ROOT  to the location of your OpenSSL and then build ACE
   and TAO as normally.
     _________________________________________________________________

  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
   [169]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 256
   MB  (notably,  for  TAO's  orbsvcs). Depending on your OS and compiler
   configuration,  an  entire build of ACE and TAO can use well over 2 MB
   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 [170]ACE library subset sizes.

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

     * Enable  or  increase  virtual memory. If you're on a [171]Linux or
       [172]LynxOS platform, please see the appropriate sections above.
     * Disable/enable    optimization    and/or    debugging.   See   the
       [173]Makefile  Flags  discussion for information on how to do that
       via ACE's Makefiles.
     * If  you're  using  g++,  try  removing  -pipe  from CFLAGS in your
       include/makeinclude/platform_macros.GNU file.
     * Restrict  the  components that you build. For ACE and TAO, see the
       discussion  of  ACE_COMPONENTS  in  the [174]ACE subsets page. For
       TAO's  orbsvcs,  see the discussion of TAO_ORBSVCS in [175]orbsvcs
       Library configuration information.
       If  disk  space  is  a problem, disabling debugging should greatly
       reduce   object   code,  and  therefore,  library  size.  This  is
       especially true with g++.
       Toshio  Hori  <toshi@etl.go.jp>  provided  these tips for reducing
       disk space usage:
       To  save  space  on  a  Unix  machine, I usually run 'find . -name
       \*.dsw -o -name \*.dsp -o -name \*.bor | xargs rm -f' in $ACE_ROOT
       at  first  after I untar the distribution. They are meaningless in
       my  environment  (Files  named  '*.dsw'  and  '*.dsp' are used for
       MSVC++ and files named '*.bor' are for Borland C++ Builder.)
       Finally, to save space, may want to run 'make clean' after 'make'.
       It removes generated object files and leaves libraries/executables
       intact. If you want to remove any of the libraries/executables, as
       well, try 'make realclean'.
     _________________________________________________________________

  Advanced Topics

     * [176]Porting ACE and TAO to a New OS Platform
     * [177]Using GNU's Autoconf with ACE
          + This  support  is  currently a work-in-progress, and is hence
            disabled.  It  will  be  completed  and re-enabled as soon as
            someone funds the work to do so.
     * [178]Non-static ACE_Object_Manager
     * [179]Cloning the Source Tree
     * [180]Building CORBA Versions of ACE
     * [181]Additional Build Tips for MVS
     * [182]Makefile Flags
     * [183]Version Control
     * [184]ACE Makefile hints
     * [185]ACE SSL effort
   ___________________________________

    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 [186]header file,
   ace/Object_Manager.h 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   [187]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
   [188]ace/OS.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      script      or
   $ACE_ROOT/bin/clone.cpp  program.  To  use  build  and  use  the clone
   program,  first  make  sure  there's a file called platform_macros.GNU
   that contains the correct platform-specific Makefile configurations in
   the  $ACE_ROOT/include/makeinclude/  directory, as well as making sure
   there's  a  $ACE_ROOT/ace/config.h  file  that  includes  the  desired
   platform/compiler  specific  configuration  header.  Then  perform the
   following steps:

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

   Then  create  a ./build subdirectory someplace, e.g., under $ACE_ROOT.
   Once this is done, then invoke the top-level Makefile with the "clone"
   target, e.g.:

% cd $ACE_ROOT
% mkdir build-SunOS5
% cd build-SunOS5
% make -f ../Makefile clone
% 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/ace:$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.

   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.

   Alternatively,  the  perl script ACE_wrappers/bin/create_ace_build can
   be   used   to   create   build   trees.   It   creates   them   below
   ACE_wrappers/build. It filters out all but the necessary files, so the
   warning  above  does  not  apply.  See  the comments at the top of the
   script itself for usage information.
   ___________________________________

    Additional Build Tips for MVS

   For all intents and purpose, MVS OpenEdition (OE) is another flavor of
   UNIX,  therefore,  the instructions under [189]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  [190]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 and
                   egcs only).
rtti             Enable run-time type identification.  On some platforms,
                   it is enabled by default, so this is ignored.
shared_libs      Build shared libraries. Ignored if static_libs_only is set.
static_libs      Build shared libraries. Ignored if shared_libs_only is set.
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_reactor       Build the XtReactor.
fl_reactor       Build the FlReactor.
tk_reactor       Build the TkReactor.
qt_reactor       Build the QtReactor.
gtk_reactor      Build the GtkReactor.
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++.
     _________________________________________________________________

   Back to the [191]ACE home page.

References

   1. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ChangeLog
   2. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/docs/ACE-development-process.html
   3. http://www.cs.wustl.edu/~schmidt/ACE/book1/
   4. http://www.cs.wustl.edu/~schmidt/ACE/book2/
   5. http://www.amazon.com/exec/obidos/tg/detail/-/0201699710/qid=1066059513/sr=8-1/ref=sr_8_1/103-7740325-3955843?v=glance&s=books&n=507846
   6. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/docs/ACE-FMM.html
   7. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/docs/usage-bugzilla.html
   8. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/docs/ACE-bug-process.html
   9. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#platforms
  10. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#installnotes
  11. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#g++
  12. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#egcs
  13. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#aceinstall
  14. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#svcsinstall
  15. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#sslinstall
  16. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#minimum_build
  17. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#resource_requirements
  18. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#advanced
  19. http://www.cs.wustl.edu/~schmidt/ACE-versions-i.html
  20. http://www.cs.wustl.edu/~doc/
  21. http://www.riverace.com/
  22. http://www.theaceorb.com/
  23. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/docs/ACE-porting.html
  24. news:comp.soft-sys.ace
  25. mailto:ace-users@cs.wustl.edu
  26. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/TAO/TAO-INSTALL.html
  27. http://www.dre.vanderbilt.edu/scoreboard/
  28. http://doc.ece.uci.edu/
  29. http://tao.doc.wustl.edu/
  30. http://www.riverace.com/
  31. http://www.theaceorb.com/
  32. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/TAO/TAO-INSTALL.html
  33. http://www.theaceorb.nl/
  34. http://www.cs.wustl.edu/~schmidt/resume-grants.html
  35. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/docs/ACE-bug-process.html
  36. http://www.cs.wustl.edu/~schmidt/research.html
  37. http://www.cs.wustl.edu/~schmidt/ACE-users.html
  38. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#Non-static Object Manager
  39. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#mingw
  40. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#cygwin
  41. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#borland
  42. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/docs/CE-status.txt
  43. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#flags
  44. http://www.cs.wustl.edu/~levine/Hints.html
  45. mailto:jordan@hursley.ibm.com
  46. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ace/Makefile
  47. http://www.cs.wustl.edu/~cleeland/ace/
  48. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#unix
  49. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#resource_requirements
  50. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/os-patches/linux-patches.html
  51. mailto:mitosys@colomsat.net.co
  52. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/FSU-threads.tar.gz
  53. http://www.riverace.com/FAQ/faq.html
  54. mailto:kielmann@informatik.uni-siegen.de
  55. mailto:trumble@cvg.enet.dec.com
  56. mailto:shuston@riverace.com
  57. mailto:gpai@voicetek.com
  58. mailto:mesnier_p@ociweb.com
  59. mailto:michael.meissnitzer@siemens.at
  60. mailto:christian.klepp@siemens.at
  61. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/engelbert.staller@siemens.at
  62. mailto:chiang@tele.nokia.fi
  63. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/tests/run_tests.sh
  64. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/include/makeinclude/platform_lynxos.GNU
  65. mailto:davem@lynx.com
  66. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/os-patches/lynxos-patches.html
  67. http://www.cs.wustl.edu/~levine/
  68. mailto:levine@cs.wustl.edu
  69. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/os-patches/vxworks-5.1.txt
  70. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#spa
  71. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#g++
  72. mailto:gehr@sweng.stortek.com
  73. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#mvs
  74. http://www.qnx.com/products/os/neutrino.html
  75. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ace/config-qnx-neutrino.h
  76. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/include/makeinclude/platform_qnx_neutrino.GNU
  77. http://get.qnx.com/
  78. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ace/config-qnx-rtp.h
  79. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/include/makeinclude/platform_qnx_neutrino.GNU
  80. http://www.pharlap.com/
  81. mailto:shuston@riverace.com
  82. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/apps/Gateway/Gateway/Connection_Handler.cpp
  83. ftp://ftp.cygnus.com/pub/g++/
  84. mailto:kielmann@informatik.uni-siegen.de
  85. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#g++
  86. mailto:trose@bridgewatersys.com
  87. mailto:gpai@voicetek.com
  88. mailto:johng@keck.hawii.edu
  89. mailto:ssweeney@sanders.com
  90. mailto:ossama@uci.edu
  91. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#unix
  92. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#win32
  93. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#cloning
  94. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#unix_autoconf
  95. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#unix_traditional
  96. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#win32
  97. mailto:ace-users@cs.wustl.edu
  98. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#cloning
  99. ftp://prep.ai.mit.edu/pub/gnu/make/
 100. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ace
 101. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/tests/README
 102. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/tests/
 103. http://www.cs.wustl.edu/~schmidt/TAO.html
 104. http://www.cs.wustl.edu/~schmidt/PDF/gperf.pdf
 105. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/apps/gperf
 106. http://www.cs.wustl.edu/~schmidt/byacc.tar.gz
 107. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#borland
 108. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#msvc
 109. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#cygwin
 110. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#mingw
 111. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#win32nonic
 112. http://www.tenermerx.com/tao_bcb/index.html
 113. mailto:jody@atdesk.com
 114. mailto:chris@kohlhoff.com
 115. mailto:jwillemsen@remedy.nl
 116. mailto:fultonb@pcnet1.ascs.aro.allied.com
 117. http://www.dinkumware.com/vc_fixes.html
 118. mailto:ben@jetpen.com
 119. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/docs/msvc_notes.txt
 120. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#win32nonic
 121. http://www.mingw.org/
 122. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#unix
 123. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#win32
 124. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#g++
 125. http://www.mingw.org/
 126. http://cygwin.com/setup.exe
 127. http://cygwin.com/
 128. http://cygwin.com/setup.exe
 129. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#mingwpacks
 130. http://www.microsoft.com/
 131. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#mingwrunpath
 132. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#win32nonic
 133. http://www.cygwin.com/
 134. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#unix
 135. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#g++
 136. http://www.cygwin.com/
 137. http://cygwin.com/setup.exe
 138. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#cygwinrunpath
 139. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#unix
 140. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#VxWorks/NT
 141. mailto:Paul_von_Behren@stortek.com
 142. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/bin/ace_ld
 143. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#Non-static Object Manager
 144. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/tests/
 145. mailto:clarence_m_weaver@md.northgrum.com
 146. mailto:Kirk.Davies@pobox.com
 147. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/TAO/performance-tests/Cubit/TAO/IDL_Cubit/collocation_test.cpp
 148. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#VxWorks/SharedLibs
 149. http://people.qualcomm.com/cryan
 150. mailto:Paul_von_Behren@stortek.com
 151. mailto:ace-users@cs.wustl.edu
 152. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/include/makeinclude/platform_vxworks5.x_g++.GNU
 153. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/include/makeinclude/platform_vxworks5.x_g++.GNU
 154. http://www.cygnus.com/misc/gnu-win32/
 155. ftp://ftp.cygnus.com/pub/gnu-win32/latest/
 156. http://www.activestate.com/software/default.htm
 157. mailto:Jaffar_Shaikh@Mitel.COM
 158. http://www.cs.wustl.edu/~schmidt/ACE-netsvcs.html
 159. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#unixsvcs
 160. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#win32svcs
 161. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#win32svcs
 162. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#unix
 163. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/netsvcs/servers/main.cpp
 164. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/netsvcs/servers/svc.conf
 165. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-papers.html#config
 166. http://www.cs.wustl.edu/~schmidt/ACE-netsvcs.html
 167. http://www.openssl.org/
 168. http://www.tenermerx.com/tao_bcb/index.html
 169. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/TAO/docs/configurations.html#orbsvcs
 170. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/docs/ACE-subsets.html#ACE Library Size Breakdown
 171. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#Linux
 172. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#LynxOS
 173. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#flags
 174. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/docs/ACE-subsets.html
 175. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/TAO/docs/configurations.html#orbsvcs
 176. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/docs/ACE-porting.html
 177. http://www.cs.wustl.edu/~othman/aceconf
 178. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#Non-static Object Manager
 179. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#cloning
 180. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#corba
 181. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#mvs
 182. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#flags
 183. http://www.cs.wustl.edu/~levine/CVS.html
 184. http://www.cs.wustl.edu/~cleeland/ace/makefile-hints.html
 185. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/docs/ACE-SSL.html
 186. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ace/Object_Manager.h
 187. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ace/Object_Manager.h
 188. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ace/OS.h
 189. file://localhost/tmp/ACE_wrappers_stage-3806/ACE_wrappers/ACE-INSTALL.html#aceinstall
 190. http://www.s390.ibm.com/products/oe/index.html
 191. http://www.cs.wustl.edu/~schmidt/ACE.html
