行业应用

开发平台：
C/C++

ACE-INSTALL：源码内容
							
     _________________________________________________________________
  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 and [4]C++NPv2 books
   to  help  guide  you  after you've built and installed ACE. You should
   also  consult  the  [5]ACE  Frequently  Made  Mistakes  page.  If  you
   encounter  any  problems or would like to request an enhancement, then
   use  our  [6]bug tracking system to submit a report in accordance with
   our [7]bug report process.
    Document Index
     * [8]Supported Platforms and C++ Compilers
     * [9]Installation Notes
     * [10]Compiling ACE with GNU g++
     * [11]Compiling ACE with egcs
     * [12]Building and Installing ACE
     * [13]Building and Installing ACE Network Services
     * [14]Building and Installing The ACE_SSL Library
     * [15]What Do I Need to Build for TAO?
     * [16]System Resource Requirements
     * [17]Advanced Topics
     _________________________________________________________________
  Platforms, C++ Compilers, and Support
   ACE  has  been  ported  to a large number of [18]platforms, using many
   different  compilers  over the years. The [19]DOC group, [20]Riverace,
   [21]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/Win32 variation is a potential target platform for ACE.
   If  you have [22]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
   [23]ACE  Newsgroup or the [24]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 [25]TAO's install document.
   CAPTION: Groups Involved in ACE Development and Support
   
   Group Platforms For more information
   DOC  Group  [26]Tested  and  used daily by the DOC group: Solaris 2.5,
   2.6, 7 and 8 (many compilers excluding SunC++ 4.x)
   Windows NT 4.0 and Windows 2000 (MSVC++ 5.x, 6.x, and 7.x, and Borland
   C++ Builder 5.0)
   Linux/Intel  (many  compilers), Linux/IA64 (GCC). DOC sites at [27]UCI
   and [28]Washington University
   Riverace  Offers  support  services for many platforms including those
   above, HP-UX, and AIX. Riverace's [29]web site
   OCI Maintains ACE on certain platforms required for their TAO software
   and  service  offerings.  OCI's  [30]web  site and the TAO [31]install
   document
   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/CE using Borland C++ Builder
   4.0  and  later, IBM VisualAge C++, and GNU g++ on MinGW; 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  [32]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 [33]bug fixing policies
   followed  by  the  DOC  group are designed to strike a balance between
   their  many  [34]research projects and their commitment to the ACE+TAO
   [35]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
     * Win32 (Windows NT, Windows 2000 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). The entire
       release  now  compiles using the Microsoft Visual C++ 5.0, and 6.0
       compilers.  ACE  can  be  built as both a static (LIB) and dynamic
       (DLL)  library,  using  the  Win32  installation process described
       below.
       Please see the [36]Non-static ACE_Object_Manager discussion below.
       We've  also added some support for [37]GNU g++ with Mingw, Borland
       C++ Builder 4.0 and later, 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  ([38]CE-status.txt)  for up-to-date information
       about ACE on CE.
     * SunOS  4.x,  Solaris  2.x,  7 and 8 using Sun Sun C++ 4.2 and 5.x,
       Forte  6,  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.5.1, 2.6, 7, and 8 platforms using the Sun
       C++  compilers.  For  Sun  C++  4.2,  we recomend using this patch
       version at a minimum:
      CC: WorkShop Compilers 4.2 21 Apr 1997 C++ 4.2 patch 104631-02
       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:
       The home page for Sun technical patches is
       [39]http://access1.sun.com. Searching for 104631 will bring you to
       a  page  allowing  you to access the latest version of the C++ 4.2
       patches.
       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  [40]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 [41]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
       The  ACE  port  to AIX assumes that the user has installed the AIX
       patch  containing  the  dl*()  APIs.  To  use  these APIs, IBM has
       created  a  separate product (free to AIX licensees) called shared
       library  hookable  symbols  (or slhs/6000). If you don't have this
       patch,  the  sv*  commands  for  compiling and linking will not be
       present on the system.
       If  you are using AIX 4.2.1 or later, this patch isn't needed; the
       dynamic library APIs are included in the base operating system.
       However,  another  patch may be needed. Thanks to Susan Liebeskind
       <shl@janis.gtri.gatech.edu>  for  submitting  the following useful
       information:
       When  building on AIX 4.2.1, using the xlC V3.1 compilers, you may
       get the following error when building the ACE shared library.
makeC++SharedLib_r -p 0 -o libACE.so  -bI:/lib/pse.exp  -L/usr/local/src/ACE_wr
a
ppers/ace -L./ -ltli_r -ldl libACE.a
ld: 0711-317 ERROR: Undefined symbol: .__CurrentException
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
make: *** [libACE.so] Error 8
       To  fix this error, you need a patch to the supporting xlC related
       libraries.  To  obtain  this patch, go to the [42]IBM public patch
       website, and retrieve the patch PTF U453697, or its successor, for
       xlC.
       You  may  wish  to retrieve this patch with the fixdist tool, also
       available  at the website. Installation of this patch will install
       patched versions of the C++ libraries, which correctly define this
       symbol.
       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 egcs, C Set++, IBM C/C++, and Visual Age C++ 5 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
       <[43]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  [44]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  [45]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
       [46]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  [47]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 [48]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  <[49]mitosys@colomsat.net.co> maintains this code.
       In addition, he also maintains a version of [50]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 9.x, 10.x, and 11.00 
       HP  sells  2  C++  compilers  for HP-UX 10.x and 11.00. If you are
       using 9.x, there's only the first one.
          + 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.
          + 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.27 (or higher) on HP-UX 11.00.
       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
       [51]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 <[52]kielmann@informatik.uni-siegen.de>
       and  David  Trumble  <[53]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  <[54]shuston@riverace.com>  has  ported ACE to work
       with UnixWare 2.01 and g++.
       Ganesh  Pai  <[55]gpai@voicetek.com> subsequently did the port for
       version 2.1.2, also with g++.
       Phil  Mesnier  <[56]  mesnier_p@ociweb.com>  updated  the  port to
       support  UnixWare  7.1.0, with help from Michael Meissnitzer <[57]
       michael.meissnitzer@siemens.at>,       Christian      Klepp      <
       [58]christian.klepp@siemens.at   >  and  Engelbert  Staller  <[59]
       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 <[60]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
       [61]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 [62]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 <[63]davem@lynx.com> has ported ACE to LynxOS 2.5
       using  GNU  g++  2.7.2.  However,  you  may  need  to  apply  some
       [64]patches to LynxOS to get ACE working.
     * VxWorks
       [65]David  Levine  <[66]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 [67]notes for using ACE with VxWorks
       5.1.
       Tornado  II/VxWorks  5.4 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 [68]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.2-g++.h for more information.
       In  addition,  as  noted [69]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
       <[70]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 [71]additional build tips for MVS for more on this.
     * QNX Neutrino
       ACE  has been ported to [72]QNX Neutrino 2.0. We cross-compile for
       Neutrino   on   a   QNX4   host   using   g++   2.8.1,  using  the
       [73]ace/config-qnx-neutrino.h and
       [74]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 [75]QNX RTP . We compile for QNX RTP using
       the   GCC  compiler  shipped  with  the  distribution,  using  the
       [76]ace/config-qnx-neutrino.h and
       [77]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 [78]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 Win32. Building the ACE
       library  is  the  same  as for regular Win32 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 [79]Steve Huston.
     * Mac OS X (10.0.x, not public beta)
       The  Mac OS X port of ACE is very much a work in progress. Some of
       the  examples build and run, some of them don't yet. Reactors seem
       to  work,  while Proactors don't (Mac OS X doesn't use aio_* calls
       for  async  i/o, it uses the OS X Event Queue instead, and the ACE
       port  doesn't take this into account yet). Also, on OS X, you must
       set  the  DYLD_LIBRARY_PATH  environment variable to $ACE_ROOT/ace
       i.e.  setenv  DYLD_LIBRARY_PATH $ACE_ROOT/ace, or else none of the
       examples   will   be   able   to  find  libACE.dylib.  John  Zorko
       <[80]j.zorko@att.net>  began  this  port  for  a work project, and
       basically  only  ported  enough  of  ACE  to be able to do what we
       needed  to  with it on Mac OS X. If you would like to continue the
       port,  please  contact  John  since he as interested in seeing ACE
       run, lean, mean and fully supported, on Mac OS X.
     _________________________________________________________________
    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 [81]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  [82]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 <[83]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.7.2, distributed with Tornado
       1.0.1/VxWorks  5.3.1), 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
       [84]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 [85]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  [86]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 [87]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 [88]Skye Sweeney for trying it out and [89]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 [90]UNIX and [91]Win32.
    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 [92]cloning the source tree before you start.
   ___________________________________
    Building and Installing ACE on UNIX
   Building  and  installing  ACE  on  UNIX  is  relatively  simple  (the
   [93]process for Win32 is different). Here's what you need to do:
    1. Install  [94]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 I have the following entry:
      % setenv ACE_ROOT /home/cs/faculty/schmidt/ACE_wrappers
       However, if you're building a number of versions of ACE, e.g., for
       different OS platforms or for different releases of ACE, you might
       use the following approach:
      % 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  (via  ln  -s  or  cp)  a  $ACE_ROOT/ace/config.h file that
       contains   the   appropriate   platform/compiler-specific   header
       configurations, e.g.,
% ln -s config-sunos5-sunc++-4.x.h config.h
       This  file  contains  the #defines that are used throughout ACE to
       indicate   which   features   your   system   supports   (see  the
       $ACE_ROOT/ace/OS.h  file  for  many  examples of how the ACE build
       configuration  is affected by these macro settings). Make sure you
       settings  are placed 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 (via ln -s or cp) a
       $ACE_ROOT/include/makeinclude/platform_macros.GNU     file    that
       contains   the   appropriate  platform/compiler-specific  Makefile
       configurations, e.g.,
% ln -s platform_sunos5_sunc++.GNU platform_macros.GNU
       This  file  contains the compiler and Makefile directives that are
       platform/compiler-specific
    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:$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  [95]$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  [96]"one-button"  tests  in
       [97]$ACE_ROOT/tests/. Finally, if you're also planning on building
       [98]TAO,  you  should  build  the  [99]gperf perfect hash function
       generator application in [100]$ACE_ROOT/apps/gperf/.
    8. If  you need to regenerate the Svc_Conf_y.cpp file, you'll need to
       get  [101]Berkeley YACC. However, you should rarely, if ever, need
       to do this.
   ___________________________________
    Building and Installing ACE on Win32
   Below  are instructions for building ACE with [102]Borland C++Builder,
   [103]Microsoft Visual C++ and [104]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 Win32 with Borland C++Builder
   If you are building for a machine without a network card, you may want
   to check [105]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_ROOTace would be C:ACE_wrappersace if
       you uncompressed into the root directory.
    2. Create  a  file called config.h in the ACE_ROOTace directory that
       contains:
       #include "ace/config-win32.h"
       If  you  are  building  for  Windows NT or Windows 2K 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_ROOTaceconfig.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
       BCB compiler. Currently 4, 5, and 6 are supported. For example:
       set BCBVER=5
    6. Change to the ACE_ROOTace 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
       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  [106]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 port has been done by [107]Jody Hagins
   and [108]Christopher Kohlhoff.
   ACE TESTS
   The tests are located in ACE_ROOTtests. You build the tests using the
   Makefile.bor file, that is:
     make -f Makefile.bor
   Once you build all the tests, you can run a perl script:
     run_test.pl -ExeSubDir DynamicRelease
   or the the batch file:
     run_tests.bat bor
   in the tests directory to try all the tests. You need to make sure the
   ACE  bin  directory  (in this case ACE_ROOTbinDynamicRelease) is on
   the path before you try to run the tests.
   ___________________________________
    Building and Installing ACE on Win32 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 [109]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
   [110]http://www.dinkumware.com/vc_fixes.html for details. Thank you to
   [111]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 4.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_ROOTace would be C:ACE_wrappersace if
       you uncompressed into the root directory.
    2. Create  a  file called config.h in the ACE_ROOTace directory that
       contains:
       #include "ace/config-win32.h"
    3. Now load up the project file for ACE (ACE_ROOTaceace.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_ROOTbin 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 or Windows 2K 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_ROOTaceconfig.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_ROOTaceconfig.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_ROOTaceconfig.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 [112]here. The
   doxygen  version of this document is available under Related Topics in
   the ACE Library.
   ACE TESTS
   The  tests are located in ACE_ROOTtests. 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   or   the   the   batch  file
   [113]run_tests.bat 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 [114]here first.
   Building  and  installing  ACE on [115]Mingw uses a mix of a [116]UNIX
   building  process  and  [117]Win32 configuration files. Also, as Mingw
   uses  GNU  g++,  you may want to take a look at the [118]Compiling ACE
   with GNU g++ section.
   You  will  need  the  Mingw build tools and libraries, downloable from
   [119]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 [120]cygwin distribution
   from [121]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
       [122]setup.exe from the cygwin site).
    2. Install  the  Mingw  tools.  Download all the needed packages (see
       [123]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. Add a MINGW_BASE environment variable pointing to the root of your
       Mingw instalation. Following the above example, set:
       % export MINGW_BASE=c:/mingw32
       Again,  use  Mingw  syntax and not cygwin syntax for the directory
       specification.
    6. 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 [124]microsoft site. This is recommended as much ACE
       functionality  depends  on  Winsock  2,  and ACE without Winsock 2
       support is tested very infrequently.
    7. 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.
    8. 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
    9. 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
   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.sh in the tests
   directory to try all the tests:
       % run_tests.sh
   If  you  are  using  ACE  as  a DLL, you will need to modify your PATH
   variable as explained [125]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 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 [126]Unix
   instructions  above  to  build  ACE  and the applications that use it.
   Please see below for more information on [127]building ACE on NT hosts
   for VxWorks targets.
   A  few  notes  on  VxWorks  builds (thanks to [128]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
       [129]$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
   [130]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 [131]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
   [132]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.
   [133]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 [134]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 [135]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 [136]Chris
   Ryan  and  [137]Paul von Behren. Please submit corrections, additions,
   or clarifications to the the [138]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
   [139]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 [140]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 [141]http://www.cygnus.com/misc/gnu-win32/ A related
       link is [142]ftp://ftp.cygnus.com/pub/gnu-win32/latest/
     * To    set   up   the   command-prompt   build   environemnt,   run
       Tornadohostx86-win32binTorVars.bat.  This  is  done implicitly
       within the Tornado IDE.
     * To   run   ace_ld,   you   still   need   perl   installed  -  see
       [143]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
      [144]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://sources.redhat.com/cygwin/
   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:Perlbin;
   C:tornadohostx86-win32bin;
   C:tornadohostx86-win32powerpc-wrs-vxworksbin;
   C:tornadohostx86-win32libgcc-libpowerpc-wrs-vxworkscygnus-2.7.=
   2-960126;
   C:CorbaAce_wrappersbin;
   C:Cygwinbin;
   C:Cygwinusrbin;
   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:CorbaACE_Wrappersaceconfig.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:CorbaACE_wrappersincludemakeincludeplatform_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:CorbaACE_wrappersace.dsw And build Ace =
   DLL
   Copy Ace.dll in C:bin
   2) Build gperf utility under NT
   In MS Visual C++ open =
   C:CorbaACE_wrappersappsgperfsrcgperf.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 [145]network services on
   [146]UNIX and [147]Win32.
   ___________________________________
    Building and Installing ACE Network Services on UNIX
   Building  and  installing  ACE  Network Services on UNIX is relatively
   simple (the [148]process for Win32 is different). Here's what you need
   to do:
    1. Build and install ACE on UNIX as described [149]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
       [150]$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:$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
       [151]$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 [152]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
       [153]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:$LD_LIBRARY_PATH
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
   [154]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.6inc32
    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.6out32dll
    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.   E-mail  the  [155]ace-users  mailing  list  to  obtain
   instructions  that  detail  how  to  build it using Borland C++. These
   instructions will soon be integrated into this web page.
     _________________________________________________________________
  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
   [156]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 [157]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 [158]Linux or
       [159]LynxOS platform, please see the appropriate sections above.
     * Disable/enable    optimization    and/or    debugging.   See   the
       [160]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 [161]ACE subsets page. For
       TAO's  orbsvcs,  see the discussion of TAO_ORBSVCS in [162]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
     * [163]Porting ACE and TAO to a New OS Platform
     * [164]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.
     * [165]Non-static ACE_Object_Manager
     * [166]Cloning the Source Tree
     * [167]Building CORBA Versions of ACE
     * [168]Additional Build Tips for MVS
     * [169]Makefile Flags
     * [170]Version Control
     * [171]ACE Makefile hints
     * [172]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 [173]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   [174]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
   [175]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:$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 [176]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  [177]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 [178]ACE home page.
References
   1. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ChangeLog
   2. file://localhost/tmp/ACE_wrappers_stage-5397/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. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/docs/ACE-FMM.html
   6. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/docs/usage-bugzilla.html
   7. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/docs/ACE-bug-process.html
   8. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#platforms
   9. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#installnotes
  10. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#g++
  11. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#egcs
  12. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#aceinstall
  13. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#svcsinstall
  14. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#sslinstall
  15. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#minimum_build
  16. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#resource_requirements
  17. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#advanced
  18. http://www.cs.wustl.edu/~schmidt/ACE-versions-i.html
  19. http://www.cs.wustl.edu/~doc/
  20. http://www.riverace.com/
  21. http://www.theaceorb.com/
  22. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/docs/ACE-porting.html
  23. news:comp.soft-sys.ace
  24. mailto:ace-users@cs.wustl.edu
  25. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/TAO/TAO-INSTALL.html
  26. http://ringil.ece.uci.edu/scoreboard/
  27. http://doc.ece.uci.edu/
  28. http://tao.doc.wustl.edu/
  29. http://www.riverace.com/
  30. http://www.theaceorb.com/
  31. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/TAO/TAO-INSTALL.html
  32. http://www.cs.wustl.edu/~schmidt/resume-grants.html
  33. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/docs/ACE-bug-process.html
  34. http://www.cs.wustl.edu/~schmidt/research.html
  35. http://www.cs.wustl.edu/~schmidt/ACE-users.html
  36. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#Non-static Object Manager
  37. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#mingw
  38. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/docs/CE-status.txt
  39. http://access1.sun.com/
  40. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#flags
  41. http://www.cs.wustl.edu/~levine/Hints.html
  42. http://service.software.ibm.com/support/rs6000
  43. mailto:jordan@hursley.ibm.com
  44. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ace/Makefile
  45. http://www.cs.wustl.edu/~cleeland/ace/
  46. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#unix
  47. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#resource_requirements
  48. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/os-patches/linux-patches.html
  49. mailto:mitosys@colomsat.net.co
  50. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/FSU-threads.tar.gz
  51. http://www.riverace.com/FAQ/faq.html
  52. mailto:kielmann@informatik.uni-siegen.de
  53. mailto:trumble@cvg.enet.dec.com
  54. mailto:shuston@riverace.com
  55. mailto:gpai@voicetek.com
  56. mailto:mesnier_p@ociweb.com
  57. mailto:michael.meissnitzer@siemens.at
  58. mailto:christian.klepp@siemens.at
  59. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/engelbert.staller@siemens.at
  60. mailto:chiang@tele.nokia.fi
  61. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/tests/run_tests.sh
  62. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/include/makeinclude/platform_lynxos.GNU
  63. mailto:davem@lynx.com
  64. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/os-patches/lynxos-patches.html
  65. http://www.cs.wustl.edu/~levine/
  66. mailto:levine@cs.wustl.edu
  67. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/os-patches/vxworks-5.1.txt
  68. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#spa
  69. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#g++
  70. mailto:gehr@sweng.stortek.com
  71. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#mvs
  72. http://www.qnx.com/products/os/neutrino.html
  73. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ace/config-qnx-neutrino.h
  74. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/include/makeinclude/platform_qnx_neutrino.GNU
  75. http://get.qnx.com/
  76. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ace/config-qnx-rtp.h
  77. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/include/makeinclude/platform_qnx_neutrino.GNU
  78. http://www.pharlap.com/
  79. mailto:shuston@riverace.com
  80. mailto:j.zorko@att.net
  81. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/apps/Gateway/Gateway/Connection_Handler.cpp
  82. ftp://ftp.cygnus.com/pub/g++/
  83. mailto:kielmann@informatik.uni-siegen.de
  84. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#g++
  85. mailto:trose@bridgewatersys.com
  86. mailto:gpai@voicetek.com
  87. mailto:johng@keck.hawii.edu
  88. mailto:ssweeney@sanders.com
  89. mailto:ossama@uci.edu
  90. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#unix
  91. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#win32
  92. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#cloning
  93. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#win32
  94. ftp://prep.ai.mit.edu/pub/gnu/make/
  95. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ace
  96. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/tests/README
  97. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/tests/
  98. http://www.cs.wustl.edu/~schmidt/TAO.html
  99. http://www.cs.wustl.edu/~schmidt/PDF/gperf.pdf
 100. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/apps/gperf
 101. http://www.cs.wustl.edu/~schmidt/byacc.tar.gz
 102. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#borland
 103. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#msvc
 104. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#mingw
 105. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#win32nonic
 106. http://www.tenermerx.com/tao_bcb/index.html
 107. mailto:jody@atdesk.com
 108. mailto:chris@kohlhoff.com
 109. mailto:fultonb@pcnet1.ascs.aro.allied.com
 110. http://www.dinkumware.com/vc_fixes.html
 111. mailto:ben@jetpen.com
 112. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/docs/msvc_notes.txt
 113. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/tests/run_tests.bat
 114. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#win32nonic
 115. http://www.mingw.org/
 116. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#unix
 117. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#win32
 118. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#g++
 119. http://www.mingw.org/
 120. http://cygwin.com/setup.exe
 121. http://cygwin.com/
 122. http://cygwin.com/setup.exe
 123. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#mingwpacks
 124. http://www.microsoft.com/
 125. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#mingwrunpath
 126. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#unix
 127. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#VxWorks/NT
 128. mailto:Paul_von_Behren@stortek.com
 129. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/bin/ace_ld
 130. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#Non-static Object Manager
 131. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/tests/
 132. mailto:clarence_m_weaver@md.northgrum.com
 133. mailto:Kirk.Davies@pobox.com
 134. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/TAO/performance-tests/Cubit/TAO/IDL_Cubit/collocation_test.cpp
 135. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#VxWorks/SharedLibs
 136. http://people.qualcomm.com/cryan
 137. mailto:Paul_von_Behren@stortek.com
 138. mailto:ace-users@cs.wustl.edu
 139. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/include/makeinclude/platform_vxworks5.x_g++.GNU
 140. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/include/makeinclude/platform_vxworks5.x_g++.GNU
 141. http://www.cygnus.com/misc/gnu-win32/
 142. ftp://ftp.cygnus.com/pub/gnu-win32/latest/
 143. http://www.activestate.com/software/default.htm
 144. mailto:Jaffar_Shaikh@Mitel.COM
 145. http://www.cs.wustl.edu/~schmidt/ACE-netsvcs.html
 146. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#unixsvcs
 147. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#win32svcs
 148. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#win32svcs
 149. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#unix
 150. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/netsvcs/servers/main.cpp
 151. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/netsvcs/servers/svc.conf
 152. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-papers.html#config
 153. http://www.cs.wustl.edu/~schmidt/ACE-netsvcs.html
 154. http://www.openssl.org/
 155. mailto:ace-users@cs.wustl.edu
 156. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/TAO/docs/configurations.html#orbsvcs
 157. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/docs/ACE-subsets.html#ACE Library Size Breakdown
 158. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#Linux
 159. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#LynxOS
 160. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#flags
 161. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/docs/ACE-subsets.html
 162. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/TAO/docs/configurations.html#orbsvcs
 163. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/docs/ACE-porting.html
 164. http://www.cs.wustl.edu/~othman/aceconf
 165. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#Non-static Object Manager
 166. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#cloning
 167. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#corba
 168. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#mvs
 169. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#flags
 170. http://www.cs.wustl.edu/~levine/CVS.html
 171. http://www.cs.wustl.edu/~cleeland/ace/makefile-hints.html
 172. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/docs/ACE-SSL.html
 173. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ace/Object_Manager.h
 174. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ace/Object_Manager.h
 175. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ace/OS.h
 176. file://localhost/tmp/ACE_wrappers_stage-5397/ACE_wrappers/ACE-INSTALL.html#aceinstall
 177. http://www.s390.ibm.com/products/oe/index.html
 178. http://www.cs.wustl.edu/~schmidt/ACE.html

						