mangos-mirror/server
0
0
Fork 0
mirror of https://github.com/mangosfour/server.git synced 2025-12-12 19:37:03 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
server/dep/ACE_wrappers/ACE-INSTALL.html
zerg b8d773091a [10874] Update ACE to v5.8.3 
(based on zergtmn's repo commit 3a8c259)
(based on zergtmn's repo commit 946c1a8)

Signed-off-by: VladimirMangos <vladimir@getmangos.com>
2010-12-14 17:37:42 +03:00

3048 lines
138 KiB
HTML
Raw Blame History

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head><!-- $Id: ACE-INSTALL.html 92151 2010-10-05 07:27:20Z johnnyw $ -->
<meta content="text/html; charset=ISO-8859-1" http-equiv="content-type"><title>Building and Installing ACE and Its Auxiliary Libraries and Services</title>
<link rev="made" href="mailto:d.schmidt@vanderbilt.edu"></head>
<body bgcolor="#ffffff" link="#000fff" text="#000000" vlink="#ff0f0f">
<hr>
<h1>Building and Installing ACE and Its Auxiliary Libraries and Services</h1>
<h2>Synopsis</h2>
The file explains how to build and install ACE, its Network Services,
test suite and examples on the various OS platforms and compilers that
it has been ported to. Please consult the <a href="NEWS">NEWS</a> and
<a href="ChangeLog">ChangeLog</a> files to see whether any recent changes
to the release will affect your code. In addition, you should check
out our <a
href="docs/ACE-development-process.html">development
process</a>. As you start working with ACE, we suggest you get copies
of the <a
href="http://www.cs.wustl.edu/%7Eschmidt/ACE/book1/">C++NPv1</a>, <a
href="http://www.cs.wustl.edu/%7Eschmidt/ACE/book2/">C++NPv2</a>, and
<a href="http://www.riverace.com/acebooks/">APG</a> books to help
guide you after you've built and installed ACE. You should also
consult the <a
href="docs/ACE-FMM.html">ACE
Frequently Made Mistakes page</a>. If you encounter any problems or
would like to request an enhancement, then use our <a
href="docs/usage-bugzilla.html">bug
tracking system</a> to submit a report in accordance with our <a
href="docs/ACE-bug-process.html">bug
report process</a>.<p>
</p><h2>Document Index</h2>
<ul>
<li><a href="#platforms">Platforms, C++ Compilers, and Support</a>
</li><li><a href="#installpre">Installation prerequisites</a>
</li><li><a href="#aceinstall">Building and Installing ACE</a>
</li><li><a href="#svcsinstall">Building and Installing ACE Network Services</a>
</li><li><a href="#sslinstall">Building and Installing The ACE_SSL Library</a>
</li><li><a href="#guireactor_install">Building and Using GUI Reactors Libraries</a>
</li><li><a href="#installnotes">Installation Notes</a>
</li><li><a href="#g++">Compiling ACE with GNU g++</a>
</li><li><a href="#minimum_build">What Do I Need to Build for TAO?</a>
</li><li><a href="#resource_requirements">System Resource Requirements</a>
</li><li><a href="#MPC">General MPC Information</a>
</li><li><a href="#eclipse">Working with ACE in Eclipse</a>
</li><li><a href="#advanced">Advanced Topics</a>
</li><li><a href="#power">Building from Subversion</a>
</li></ul>
<p></p><hr><p>
</p><h2><a name="platforms">Platforms, C++ Compilers, and Support</a></h2>
<p>ACE has been ported to a large number of platforms using many different
compilers over the years.
The <a href="http://www.dre.vanderbilt.edu/">DOC group</a>,
<a href="http://www.riverace.com/">Riverace</a>,
<a href="http://www.theaceorb.com/">OCI</a>,
<a href="http://www.theaceorb.nl/">Remedy IT</a>, and members of the ACE
user community have all contributed ports to make ACE the successful
and far-reaching toolkit it is today. Any UNIX/POSIX/Windows
variation is probably an easy target platform for ACE. If you have
<a href="docs/ACE-porting.html">porting questions</a> or have a problem
compiling the ACE source distribution, please contact one of the
commercial support companies, or send a copy of the
<a href="PROBLEM-REPORT-FORM">PROBLEM-REPORT-FORM</a>, located in the
ACE_wrappers directory, to either the <a href="news:comp.soft-sys.ace">ACE
Newsgroup</a> or the <a href="mailto:ace-users@cse.wustl.edu">ace-users
mailing list</a>.
The DOC groups at Washington University, UC Irvine, and Vanderbilt
University provide only "best effort" support for non-sponsors for the
latest release, as described in <a href="docs/ACE-bug-process.html">
docs/ACE-bug-process.html</a>.
Thus, if you need more "predictable" help, or help with earlier versions of
ACE, it's recommend that you check out the
<a href="http://www.cs.wustl.edu/~schmidt/commercial-support.html">list of
commercial support companies</a> for additional assistance.
</p>
<p>The responsibility for maintaining ACE across the wide range of
supported platforms is divided among a few different groups:
<ul>
<li>The DOC group maintains platforms used in the course of their research
and sponsored work</li>
<li>Companies that provide support (Riverace, OCI, and Remedy IT), maintain
platforms they support in the course of their various service offerings</li>
<li>The ACE user community maintains any other desired platforms.</li>
</ul>
The <a href="http://www.dre.vanderbilt.edu/scoreboard/" target="_blank">
build scoreboard</a>
records the current status of build and regression testing during
development by all of the above groups. It is available to all users wishing
to provide build results. Members of the ACE community that maintain ACE on
platforms not maintained by the DOC group, Riverace, OCI, or Remedy IT are
encouraged to provide build and regression test results for the scoreboard
to ensure that all in-use platforms are represented.
See the <a href="https://svn.dre.vanderbilt.edu/viewvc/autobuild/trunk/README?revision=HEAD" target="_blank">autobuild README</a> for more information about
how to set up a build; contact one of the above groups to inquire about how
to get your build results recorded on the scoreboard.</p>
<p>Because older
platforms that are not maintained tend to fall into a broken state and
clutter the ACE sources with code that is no longer used, the development
team reserves the right to remove ACE configuration files and source code
specific to inactive platform configurations that are not
listed on the scoreboard.</p>
<p>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 <a href="TAO/TAO-INSTALL.html">TAO's install
document</a>.</p><p>
<table border="1" width="75%">
<caption><b>Groups Involved in ACE Development and Support<br></b></caption>
<thead>
<tr valign="top">
<th>Group</th>
<th>Platforms</th>
<th>For more information</th>
</tr>
</thead><tbody>
<tr>
<th>DOC Group</th>
<td>Windows 2000, XP (MSVC++ 7.1, 8, 9, and 10);
many versions of Linux/Intel (many compilers).
</td>
<td>DOC sites at <a href="http://www.dre.vanderbilt.edu/">ISIS</a>,
<a href="http://doc.ece.uci.edu/">UCI</a> and
<a href="http://tao.doc.wustl.edu/">Washington University</a>
</td>
</tr>
<tr>
<th>Riverace</th>
<td>Offers ACE
<a href="http://www.riverace.com/training.htm">training</a>,
<a href="http://www.riverace.com/support.htm">support</a> and
<a href="http://www.riverace.com/consult.htm">consulting services</a>
for many platforms including AIX, HP-UX, Linux, Solaris, and Windows.
</td>
<td>Riverace's <a href="http://www.riverace.com/support.htm">ACE
Support page</a>.</td>
</tr>
<tr>
<th>OCI</th>
<td>Maintains ACE on certain platforms required for their TAO
software and service offerings.
</td>
<td>OCI's <a href="http://www.theaceorb.com/">web site</a> and
the TAO <a href="TAO/TAO-INSTALL.html">install document</a></td>
</tr>
<tr>
<th>Remedy IT</th>
<td>Maintains ACE on many platforms required for their ACE and
TAO service offerings. We support AIX,
CodeGear C++ Builder 2007/2009, CodeGear RAD Studio 2007, Embarcadero C++ Builder 2010,
CBuilderX 1.0, Windows CE, MinGW, Microsoft Visual C++ 7.1/8/9/10, GCC,
Cygwin, VxWorks 5.5.x - 6.x (kernel and rtp), OpenVMS 8.2-1 & 8.3 on Alpha and IA64,
BlueCAT Linux, RedHat Linux, Fedora, MacOSX, Solaris,
Tru64, SuSE Linux on Alpha/IA32/EM64T/IA64, RTEMS, QNX, LynxOS 4.0/4.2,
HPUX 11i v1/v2 32/64 bit on PA-RISC, and
HPUX 11i v2/v3 on IA64. The Intel C++ compiler is supported on
Windows 32/64bit, Linux IA32/EM64T/IA64, MacOSX.
</td>
<td>Remedy IT <a href="http://www.theaceorb.nl/">web site</a> and
the TAO <a href="TAO/TAO-INSTALL.html">install document</a>
</td>
</tr>
<tr>
<th>PrismTech</th>
<td>Maintains ACE on certain platforms required for their TAO
software and service offerings, including LynxOS.
</td>
<td>PrismTech's <a href="http://www.prismtech.com/">web site</a></td>
</tr>
<tr>
<th>ACE user community</th>
<td>Responsible for continued maintenance and testing of platforms
to which ACE has been ported, but aren't supported by the
above groups. These include
Digital UNIX (Compaq Tru64) 4.0 and 5.0;
IRIX 6.x; UnixWare 7.1.0;
Linux on PPC; OpenMVS;
Tandem; SCO; FreeBSD; NetBSD; OpenBSD;
Macintosh OS X; OS/9; PharLap ETS 13;
QNX RTP and Neutrino 2.0; Interix (Windows Services for Unix)
</td>
</tr><tr>
<th>Not maintained</th>
<td>The following platforms have been ported to in the past but are
no longer maintained and may be removed from ACE at any time.
If you want to have support for these environments contact one
of the commercial support organisations. The platforms include:
Chorus; DG/UX; HP-UX 9, 10 and 11.00; pSOS;
SunOS 4.x and Solaris with SunC++ 4.x; VxWorks 5.4 and earlier;
Microsoft Visual C++ 5, 6, and 7.0; Borland C++ Builder 4, 5, 6, and 2006.
For up-to-date listings on platform that are deprecated and pending
removal from ACE, please see the <a href="NEWS">NEWS file</a>.
</td>
</tr>
<tr><td></td>
</tr>
</tbody></table></p><p>
</p><p>Although the DOC group has provided outstanding support for ACE
over the years, ACE's success has greatly increased the amount of
effort required to keep up with its maintenance, answer users'
questions, and give design guidance. Riverace offers world-class
commercial services to support ACE users. OCI, PrismTech, and Remedy
offer similar services for TAO, allowing the DOC group's primary focus
to shift back to their main goal: <em>research</em>. The DOC group is
fundamentally focused on (and <a
href="http://www.cs.wustl.edu/%7Eschmidt/resume-grants.html">funded
by</a>) advanced R&amp;D projects. The group continues to be
intimately involved in ACE+TAO development and maintenance, but with
revised priorities for maintenance. The <a
href="docs/ACE-bug-process.html">bug
fixing policies</a> followed by the DOC group are designed to strike a
balance between their many <a
href="http://www.cs.wustl.edu/%7Eschmidt/research.html">research
projects</a> and their commitment to the ACE+TAO <a
href="http://www.cs.wustl.edu/%7Eschmidt/ACE-users.html">user
community</a>. Naturally, we will be happy to accept well-tested
patches from the ACE+TAO user community for any platforms that aren't
supported by the DOC group, Riverace, OCI or Remedy IT. </p><p>
</p><p></p><hr><p>
</p><h2><a name="installpre">Installation prerequisites</a></h2>
<p> ACE (as well as TAO and CIAO) use <A
HREF="http://downloads.ociweb.com/MPC/docs/html/MakeProjectCreator.html">MPC</A>
(MakeProjectCreator) to generate files used by all supported build
tools (such as GNUmakefiles for UNIX based platforms, sln and vcproj
files for VC71/VC8 and Embarcadero makefiles) on various platforms. To
help new users to bootstrap quickly the release bundles of ACE (as
well as TAO and CIAO) include all needed files to use the build
instructions in this document.
</p>
<p>
If it is necessary to generate
files for build tools for other compilers, one must
run MPC to generate the
appropriate files. Please see <a href="MPC/docs/USAGE">USAGE</a>, <a
href="MPC/docs/README">README</a>, and <a
href="bin/MakeProjectCreator/README">README for ACE</a> files for
details. The options that have been used to generate the above build
files can be found in <a
href="bin/MakeProjectCreator/config/global.features">
global.features</a> file.
</p>
<hr>
<h1><a name="aceinstall">Building and Installing ACE</a></h1>
The following sections explain how to build ACE on:
<ul>
<li><a href="#unix">UNIX</a></li>
<li><a href="#win32">Windows (including MinGW and Cygwin)</a></li>
<li><a href="#vxworks">VxWorks</a></li>
<li><a href="#interix">Interix</a></li>
<li><a href="#rtems">RTEMS</a></li>
</ul>
<h2>General Rules</h2>
<ul>
<li><p>Many features in ACE can be modified by defining some macros in
<code>$ACE_ROOT/ace/config.h</code>. These macros should
<em><b>always</b></em> appear <em><b>before</b></em> including
your platform specific config file.</p>
</li><li><p>However, if you want to undefine/redefine macros defined in the
platform specific config file, these <code>#undef</code> should
come <em><b>after</b></em> the config file.</p>
</li><li> If you're planning to build ACE on multiple platforms, you may
want to consider <a href="#cloning">cloning the source tree</a>
before you start. <p>
</p></li></ul>
<hr align="left" width="50%">
<h2><a name="unix">Building and Installing ACE on UNIX</a></h2>
As of ACE 5.4, you can choose between two methods of building ACE on
UNIX:
<ol>
<li><a href="#unix_autoconf">GNU Autoconf</a></li>
<li><a href="#unix_traditional">Traditional ACE/GNU Make Configuration</a></li>
</ol>
The <a href="#win32">build process for Windows</a> is different from both of
the UNIX methods.
<h3><a name="unix_autoconf">Building ACE with GNU Autoconf</a></h3>
<p>
GNU Autoconf support is available in the ACE and ACE+TAO distributions
in the DOC group website. Support for Autoconf is not included in
distributions that contain CIAO.
</p>
<p>
GNU Autoconf support has been partially present in a number of ACE
versions. However, ACE 5.4 was the first version that supported it in
earnest. The range of platforms on which GNU autoconf support is regularly
tested is not as broad as for the traditional configuration method, so you
should be careful to test the resulting ACE library before using it in
your applications. You can review the
<a href="http://www.dre.vanderbilt.edu/scoreboard/" target="_blank">
build scoreboard</a> to check the currently tested set of autoconfigured
platforms (look for autoconf in the platform name).
Any help you can lend to improve the ACE build process using GNU Autoconf
would be very much appreciated. Please send any fixes to the
<a href="mailto:ace-users@cse.wustl.edu">ACE users</a> mailing list
using the standard <a href="PROBLEM-REPORT-FORM">PROBLEM-REPORT-FORM</a>.
</p>
<p>
The kit has been bootstrapped so you do not need to install the GNU
Autotools (autoconf, automake, libtool) unless you want to participate
in <a href="#autoconf_development">testing and developing</a> this
process further or if you are working directly off of sources in the
ACE subversion repository. To simply configure and build ACE, do:
</p><ol>
<li><code>cd</code> to the top-level <code>ACE_wrappers</code> directory.</li>
<li>Create a subdirectory to hold your build's configuration and built
ACE version, and then change to the new directory:
<pre> mkdir build
cd build</pre>
Note that you do not run the <code>create_ace_build.pl</code> utility
mentioned in the <a href="#cloning">Cloning the Source Tree</a>
section. The configure script takes care of creating all files
and links that are needed.</li>
<li>Configure ACE for your platform by issuing the following command:
<pre> ../configure [options]</pre>
<code>options</code> can be a variable setting (such as setting
<code>CXX</code> to your C++ compiler command) any standard GNU
configure options, or any of the following ACE configure options
(default values are in parentheses):
<ul>
<li><code>--enable-alloca</code> (no): Enable <code>alloca()</code>
support.</li>
<li><code>--enable-debug</code> (yes): Build ACE with debugging
support.</li>
<li><code>--enable-exceptions</code> (yes): Build ACE with C++
exception support compiled in.</li>
<li><code>--enable-fast</code> (no): Use the Sun C++ <code>-fast</code>
option to build. Only used on Solaris.</li>
<li><code>--enable-ipv4-ipv6</code> (no): Enable IPv4/IPv6 migration support.</li>
<li><code>--enable-ipv6</code> (no): Enable IPv6 support.</li>
<li><code>--enable-inline</code> (yes): Enable inline functions.</li>
<li><code>--enable-optimize</code> (yes): Enable building optimized.</li>
<li><code>--enable-prof</code> (no): Enable profiling support.</li>
<li><code>--enable-purify</code> (no): Build with support for
IBM Rational Purify.</li>
<li><code>--enable-quantify</code> (no): Build with support for
IBM Rational Quantify.</li>
<li><code>--enable-repo</code> (no): Enable the GNU g++
<code>-frepo</code> option. Only useful for pre-3.0 g++.</li>
<li><code>--enable-stdcpplib</code> (yes): Build with support for the
standard C++ library, as opposed to the older iostreams library.</li>
<li><code>--enable-log-msg-prop</code> (yes): Enable
<code>ACE_Log_Msg</code> property propagation to ACE-created
threads.</li>
<li><code>--enable-logging</code> (yes): Enable the ACE logging
macros.</li>
<li><code>--enable-malloc-stats</code> (no): Compile in additional code
for collecting memory allocation statistics.</li>
<li><code>--enable-pi-pointers</code> (yes): Enable
position-independent pointers for shared memory classes.</li>
<li><code>--enable-probe</code> (no): Enable the
<code>ACE_Timeprobe</code> class.</li>
<li><code>--enable-reentrant</code> (yes): Enable use of platform's
reentrant functions.</li>
<li><code>--enable-static-obj-mgr</code> (yes): Enable use of a
static <code>ACE_Object_Manager</code>.</li>
<li><code>--enable-threads</code> (yes): Enable threading support.</li>
<li><code>--enable-verb-not-sup</code> (no): Enable verbose ENOTSUP
reports at run time.</li>
<li><code>--enable-trace</code> (no): Enable ACE execution tracing
support.</li>
<li><code>--enable-fl-reactor</code> (no): Enable support for the
<code>ACE_FlReactor</code> class.</li>
<li><code>--enable-qt-reactor</code> (no): Enable support for the
<code>ACE_QtReactor</code> class.</li>
<li><code>--enable-tk-reactor</code> (no): Enable support for the
<code>ACE_TkReactor</code> class.</li>
<li><code>--enable-xt-reactor</code> (no): Enable support for the
<code>ACE_XtReactor</code> class.</li>
<li><code>--enable-gperf</code> (yes): Build the implementation of
gperf that comes with ACE.</li>
<li><code>--enable-qos</code> (no): Include the ACE_QoS library when
building ACE.</li>
<li><code>--enable-ssl</code> (yes): Include the ACE_SSL library when
building ACE. Requires the SSL components to be available using the
compiler's and linker's default search directories.</li>
<li><code>--with-openssl</code>: Specifies the root directory of the
OpenSSL installation; expects the specified directory to have
<code>include</code> and <code>lib</code> subdirectories. To
specify other locations for the header and libraries, use one or
both of the following.</li>
<li><code>--with-openssl-include</code>: Specify the directory
containing the OpenSSL header files.</li>
<li><code>--with-openssl-libdir</code>: Specify the directory
containing the OpenSSL libraries.</li>
<li><code>--with-tli-device</code> (/dev/tcp): Specifies the device
name for opening a TLI device at run time.</li>
</ul>
</li>
<li>Build ACE by typing <code>make</code>.
</li><li>(Optional) Install ACE by typing <code>make install</code>.
</li></ol>
<h4><a name="autoconf_development">Testing and Developing GNU Autotool
Support in ACE</a></h4>
<p>
In order to test and develop the GNU Autotool support in ACE or
bootstrap autotool support into ACE when working directly off of ACE
sources in the subversion repository, you must have recent versions of GNU
Autoconf, Automake and Libtool installed on your host. Once
installed, autotool support may be bootstrapped into your workspace by
doing the following:
<blockquote>
<code>
cd ACE_wrappers<br>
./bin/bootstrap<br>
</code>
</blockquote>
After doing so, you will be able to run the <code>configure</code>
script.
<h3><a name="unix_traditional">Using the Traditional ACE/GNU Configuration</a></h3>
<p>
Here's what you need to do to build ACE using GNU Make and ACE's traditional
per-platform configuration method:</p>
<ol>
<li>Install <a href="http://ftp.gnu.org/pub/gnu/make/">GNU make</a>
3.79.1 or greater on your system (available via <code>http</code>
anonymous <code>ftp</code> from <code>ftp.gnu.org</code> in the
<code>pub/gnu/make/</code> directory).
You <em>must</em> use GNU make when using ACE's traditional
per-platform configuration method or ACE won't compile.
</li>
<li>Add an environment variable called ACE_ROOT that contains the
name of the root of the directory where you keep the ACE wrapper
source tree. The ACE recursive Makefile scheme needs this information.
There are several ways to set the ACE_ROOT variable. For example:
<blockquote>
TSCH/CSH:
<code>setenv ACE_ROOT /home/cs/faculty/schmidt/ACE_wrappers</code>
</blockquote>
<blockquote>
BASH or Bourne Shell:
<code>ACE_ROOT=/home/cs/faculty/schmidt/ACE_wrappers; export ACE_ROOT
</code>
</blockquote>
<p>
If you're building a number of versions of ACE, however, (e.g., for
different OS platforms or for different releases of ACE) you might use
the following approach (assuming TCSH/CSH):
</p><blockquote><code>setenv ACE_ROOT $cwd</code>
</blockquote>
</li>
<li>Create a configuration file, <code>$ACE_ROOT/ace/config.h</code>,
that includes the appropriate platform/compiler-specific
header configurations from the ACE source directory. For example:
<blockquote><code>
#include "ace/config-linux.h"
</code></blockquote>
The platform/compiler-specific configuration file
contains the #defines that are used throughout ACE to indicate
which features your system supports. See the
<code>$ACE_ROOT/ace/README</code> file for a description of these
macro settings. If you desire to add some site-specific or build-specific
changes, you can add them to your config.h file; place them
<strong>before</strong> the inclusion of the platform-specific
header file.
<p>
There are config files for most versions of UNIX. If there
isn't a version of this file that matches your
platform/compiler, you'll need to make one. Please send email
to the <a href="mailto:ace-users@cse.wustl.edu">ace-users</a> list
if you get it working so it can be added to the master ACE
release.</p>
</li>
<li>Create a build configuration file,
<code>$ACE_ROOT/include/makeinclude/platform_macros.GNU</code>,
that contains the appropriate platform/compiler-specific
Makefile configurations, e.g.,
<blockquote><code>
include $(ACE_ROOT)/include/makeinclude/platform_linux.GNU
</code></blockquote>
This file contains the compiler and Makefile directives that are
platform/compiler-specific. If you'd like to add make options, you
can add them before including the platform-specific configuration.<p>
NOTE! There really is not a # character before 'include' in the
platform_macros.GNU file. # is a comment character.
</li>
<li>If you wish to install ACE (using &quot;make install&quot;), set the
installation prefix in platform_macros.GNU.
<blockquote><code>
INSTALL_PREFIX = /usr/local
</code></blockquote>
Headers will be installed to $INSTALL_PREFIX/include, executables to
$INSTALL_PREFIX/bin, documentation and build system files to
$INSTALL_PREFIX/share and libraries to $INSTALL_PREFIX/lib. The library
directory can be customized by setting INSTALL_LIB (for example,
INSTALL_LIB=lib64). With INSTALL_PREFIX set, RPATH will be enabled for
all executables and shared libraries. To disable RPATH (for example,
if $INSTALL_PREFIX/$INSTALL_LIB is already a system-known location for
shared libraries such as those listed in /etc/ld.so.conf), set the make
macro install_rpath to 0 by adding install_rpath=0 to platform_macros.GNU.
</li>
<li>Note that because ACE builds shared libraries, you'll need to set
LD_LIBRARY_PATH (or equivalent for your platform) to the directory
where binary version of the ACE library is built into. For example,
you probably want to do something like the following:
<blockquote>
<code>% setenv LD_LIBRARY_PATH $ACE_ROOT/lib:$LD_LIBRARY_PATH</code></blockquote>
</li>
<li>When all this is done, hopefully all you'll need to do is type:
<blockquote>
<code>% make</code></blockquote>
at the ACE_ROOT directory. This will build the ACE
library, tests, the examples, and the sample applications.
Building the entire ACE release can take a long time and consume
lots of disk space, however. Therefore, you might consider
cd'ing into the <code>$ACE_ROOT/ace</code> directory and
running <code>make</code> there to build just the ACE library.
As a sanity check, you might also want to build and run the
automated <a href="tests/README">"one-button" tests</a> in
<code>$ACE_ROOT/tests</code>. Finally, if you're also
planning on building <a href="http://www.cs.wustl.edu/%7Eschmidt/TAO.html">TAO</a>, you
should build the <a href="http://www.cs.wustl.edu/%7Eschmidt/PDF/gperf.pdf">gperf</a>
perfect hash function generator application in
<code>$ACE_ROOT/apps/gperf</code>.
</li>
<li>If you've set the INSTALL_PREFIX before building, now run
<blockquote><code>% make install</code></blockquote>
</li>
<li>If you need to regenerate the <code>ace/Svc_Conf_y.cpp</code> file,
you'll need to
get <a href="http://ftp.gnu.org/pub/gnu/bison/">GNU Bison</a>.
However, you should rarely, if ever, need to do this.
</li>
</ol>
<hr align="left" width="50%">
<h2><a name="win32">Building and Installing ACE on Windows</a></h2>
<p>This section contains instructions for building ACE on Microsoft
Windows with a variety of compilers and development environments.</p>
<p>First, if you are upgrading from an older release, the recommended practice
is to start with a clean directory. Unpacking the newer release over an older
one will not clean up any old files, and trying to use the environment's
"Clean" command will probably not account for all existing files.</p>
<ul>
<li><a href="#msvc">Microsoft Visual Studio</a></li>
<li><a href="#codegear">Embarcadero C++Builder</a></li>
<li><a href="#mingw">MinGW</a></li>
<li><a href="#cygwin">Cygwin</a></li>
</ul>
</p><p></p><hr align="left" width="50%"><p>
</p><h3><a name="msvc">Building and Installing ACE on Windows with
Microsoft Visual Studio</a></h3>
<p>ACE contains project files for Microsoft Visual Studio .NET 2005 (VC8)
, Visual Studio 2009 (VC9), and Visual Studio 2010 (VC10).
Visual Studio 2005 supports building for
desktop/server Windows as well as for Windows CE and Windows Mobile. Since
not all users will be interested in the CE/Mobile capability, these platforms
have separate solution and project files from the desktop/server Windows.
Furthermore, VC7.1, VC8, VC9, and 10 use different file formats but the same file
suffixes (<code>.sln</code> and <code>.vcproj</code>). To support both
environments, ACE supplies files with different names for the different
development and target platforms. The platform/name mapping is shown below.
All solution files have a <code>.sln</code> suffix and all project files have
a <code>.vcproj</code> suffix.</p>
<p>
The free Visual C++ 2008 Express Edition will work in place of the traditional
Visual Studio editions. All the other notes in this document
that are for VC8 / VC9 also apply to the express edition. MFC, 64-bit, and
CE/mobile options are not available with the express edition. 64-bit binaries
can be built with the compiler and linker included in the <a href="http://www.microsoft.com/downloads/details.aspx?FamilyID=E6E1C3DF-A74F-4207-8586-711EBE331CDC&displaylang=en">Windows SDK</a>, using nmake as the build system (generate nmake makefiles with mwc.pl -type nmake).</p>
<table border="1" width="400">
<caption><b>Mapping of Platform to Solution/Project File Name</b></caption>
<thead>
<tr valign="top">
<th>Platform</th>
<th>File Name</th>
</tr>
</thead><tbody>
<tr>
<th>VC7.1</th>
<td><i>name</i><code>_vc71</code>
</td>
</tr>
<tr>
<th>VC8 for desktop/server</th>
<td><i>name</i><code>_vc8</code>
</td>
</tr>
<tr>
<th>VC8 for Windows CE/Mobile</th>
<td><i>name</i><code>_WinCE</code>
</td>
</tr>
<tr>
<th>VC9 for desktop/server</th>
<td><i>name</i><code>_vc9</code>
</td>
</tr>
<tr>
<th>VC10 for desktop/server</th>
<td><i>name</i><code>_vc10</code>
</td>
</tr>
</tbody></table>
<p>The VC++ compiler and linker can now be invoked from GNU make just like
most UNIX builds. Follow the instructions in the <a href="#unix_traditional">
ACE/GNU Configuration</a> sections and see the additional information in the
comments of
<a href="include/makeinclude/platform_win32_msvc.GNU">platform_win32_msvc.GNU</a>.
</p>
<p>If you happen to open a VC7.1 file from within VC8, it will offer to convert
the file to the newer format for you. With the stock VC8, do not do this;
Visual Studio will crash while attempting to convert the large
solution and project files to build ACE. Simply refuse the conversion and
open the file with the correct format. Note that Microsoft has fixed this
problem. See
<a href="https://msdn.microsoft.com/visualc/downloads/default.aspx">
https://msdn.microsoft.com/visualc/downloads/default.aspx</a> for information.
</p>
<ol>
<li>Uncompress the ACE distribution into a directory, where it will
create a ACE_wrappers directory containing the distribution. The
ACE_wrappers directory will be referred to as ACE_ROOT in the
following steps -- so ACE_ROOT\ace would be C:\ACE_wrappers\ace if
you uncompressed into the root directory.<br>
<br>
</li><li>Create a file called <code>config.h</code> in the ACE_ROOT\ace
directory that contains: <br>
<br>
<code>#include "ace/config-win32.h"</code><br>
<br>
</li><li>The static, DLL and MFC library builds are kept in
different workspaces. Files with names *_Static contain project
files for static builds. Workspaces for static and DLL builds will be
available through the stock release at DOC group's website. The
workspaces for MFC are not available and have to be generated using
MPC. Please see <a href="MPC/docs/README">MPC's README</a> for
details.<br><br>
</li><li>Now load the solution file for ACE (ACE_ROOT/ACE.sln).<br>
<br>
</li><li>Make sure you are building the configuration (i.e, Debug/Release)
the one you'll use (for example, the debug tests need the debug
version of ACE, and so on). All these different configurations are
provided for your convenience. You can either adopt the scheme to
build your applications with different configurations, or use
<code>ace/config.h</code> to tweak with the default settings on
NT.<br> <strong>Note:</strong> If you use the dynamic libraries,
make sure you include ACE_ROOT\lib in your PATH whenever you run
programs that uses ACE. Otherwise you may experience problems
finding ace.dll or aced.dll.<br>
<br>
</li><li>To use ACE with MFC libraries, also add the following to
your <code>config.h</code> 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.<br>
<br>
<code>#define ACE_HAS_MFC 1</code><br>
<br>
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 <code>ACE_USES_STATIC_MFC</code> in your
<code>config.h</code> 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.<p>
</p></li><li>Static version of ACE libraries are built with
<code>ACE_AS_STATIC_LIBS</code><br> defined. This macro should
also be used in application projects that link to static ACE
libraries<br>
<br>
Optionally you can also add the line <br>
<br>
<code>#define ACE_NO_INLINE</code><br>
<br>
before the #include statement in ACE_ROOT\ace\config.h to disable
inline function and reduce the size of static libraries (and your
executables.)<br>
<br>
</li><li>ACE DLL and LIB naming scheme:<br>
<br>
We use the following rules to name the DLL and LIB files in ACE
when using MSVC.<br>
<br>
"Library/DLL name" + (Is static library ? "s" :
"") + (Is Debugging enable ? "d" : "")
+ {".dll"|".lib"}<br>
<br>
</li></ol>
<p>More information for ACE/TAO on MSVC can be found
<a href="docs/msvc_notes.txt">here</a>. The doxygen version of this
document is available under Related Topics in the ACE Library.</p>
<b>ACE TESTS</b><p>
The tests are located in ACE_ROOT\tests. There is also a solution in
that directory to build all the tests (tests.sln)</p><p>
Once you build all the tests (Batch Build works well for this), you
can run perl script <code>run_test.pl</code> in the
<code>tests</code> directory to try all the tests.</p><p>
<a name="win32nonic">
<b> BUILDING ACE ON A WIN32 MACHINE THAT LACKS A NETWORK CARD </b></a></p><p>
<a name="win32nonic">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:
</a></p><ol>
<a name="win32nonic"> <li>Run Control Panel
</li><li>Choose Network from Control Panel
</li><li>Add Adapter: MS Loopback Adapter
</li><li>Configure MS Loopback Adapter with 802.3 (default)
</li><li>Add Protocol: TCP/IP Protocol
</li><li>Configure TCP/IP Protocol with a valid IP address and subnet mask.
Leave everything else at the default settings.
</li><li>Add Service: Workstation
</li><li>Exit and Restart System
</li><li>Run Control Panel again
</li><li>Choose Services from Control Panel
</li><li>The following services are not necessary and may
be set to Disabled Startup: <br>
Alerter<br>
Computer Browser<br>
Net logon<br>
Messanger<br>
</li><li>Choose Network from Control Panel
</li><li>Confirm the following setup. This is all you need to run ACE:<br>
Installed Software:<br>
Computer Browser<br>
MS Loopback Adapter Driver<br>
TCP/IP Protocol<br>
Workstation<br>
Installed Adapter Cards:<br>
MS Loopback Adapter<p>
</p></li></a></ol>
<a name="win32nonic"><b>WIN32 ALPHA CONFIGURATIONS</b>
</a><p><a name="win32nonic">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:</a></p>
<ol>
<a name="win32nonic"> <li>Load the project on the Alpha machine.
</li><li>Go to the Build menu and then select Configurations.
</li><li>Select the project that you want to convert.
</li><li>Click on Add.
</li><li>Select the x86 configuration to "Copy settings from"
(either Debug or Release versions).
</li><li>Prepend "Alpha " to the beginning of the name under
"Configuration".
</li><li>Click OK.
</li><li>Close the "Configurations" window.
</li><li>Now go to the Project settings.
</li><li>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".
</li><li>For the C/C++ Settings, make sure that the Code Generation's runtime
library is set to "Multithreaded DLL" or "Debug Multithreaded
DLL".
</li></a></ol>
<p><a name="win32nonic"><b>Note:</b> 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.</a></p>
<hr align="left" width="50%"><p>&nbsp;</p>
<h3><a name="codegear">Building and Installing ACE on Windows with Embarcadero C++</a></h3>
If you are building for a machine without a network card, you may want
to check <a href="#win32nonic">here</a> first. <p>
</p><ol>
<li>Uncompress the ACE distribution into a directory, where it will
create an
ACE_wrappers directory containing the source. The ACE_wrappers
directory will be referred to as ACE_ROOT in the following steps -- so
ACE_ROOT\ace would be C:\ACE_wrappers\ace if you uncompressed into the
root directory.<br>
<br>
</li><li>Create a file called <code>config.h</code> in the ACE_ROOT\ace
directory that contains: <br>
<br>
<code>#include "ace/config-win32.h"</code><br>
<br>
</li><li>Open a Command Prompt (DOS Box).<br>
<br>
</li><li>Set the ACE_ROOT environment variable to point to the ACE_wrappers
directory. For example:<br>
<br>
<code>set ACE_ROOT=C:\ACE_wrappers</code><br>
<br>
</li><li>Add ACE_wrappers\lib and ACE_wrappers\bin to the PATH environment variable:<br>
<br>
<code>set PATH=C:\ACE_wrappers\lib;C:\ACE_wrappers\bin;%PATH%</code><br>
<br>
</li><li>Generate the bmake makefiles using <a href="#MPC">MPC</a>. Use the <code>bmake</code> project type for C++ Builder.
<br><br>
</li><li>Change to the ACE_ROOT\ace directory.<br>
<br>
</li><li>Build release DLLs for ACE by going:<br>
<br>
<code>make -f Makefile.bmak all</code><br>
<br>
</li><li>You can build several different versions of ACE by setting environment
variables before you run make:<br>
<br>
Set the environment variable below to build a debug version of ACE<br>
<code>set DEBUG=1</code><br>
<br>
Set the environment variable below to build a unicode version of ACE<br>
<code>set UNICODE=1</code><br>
<br>
Set the environment variable below to build a version of ACE with
Codeguard support. Should only be used when DEBUG is also set<br>
<code>set CODEGUARD=1</code><br>
<br>
Set the environment variable below to build a version of ACE optimized
for a certain CPU. For this there are special compiler flags
(-3/-4/-5/-6), see the Embarcadero help for more info.<br>
<code>set CPU_FLAG=-6</code><br>
<br>
You can then start the build with the command
<br><code>make -f Makefile.bmak all</code><br>
<br>
You may also enable the options by passing them as command line options to make, for example:<br>
<code>make -f Makefile.bmak -DDEBUG all</code><br>
<br>
</li></ol>
<p>
Note that when you run <code>make</code> in a sub directory you give <code>make -f Makefile.bmak all</code>. The <code>all</code> is needed to make sure the complete project is build.<p>
The Borland/CodeGear/Embarcadero C++ Builder 4.0/5.0/6.0/2006/2007/2009/2010 port has been done by Jody Hagins, <a href="mailto:chris@kohlhoff.com">Christopher Kohlhoff</a> and <a href="mailto:jwillemsen@remedy.nl">Johnny Willemsen</a>. </p><p>
<b>ACE TESTS</b></p><p>
Before you can build the tests you need to build the protocols directory.
Change the directory to ACE_ROOT\protocols and start the build with: </p><p>
</p><blockquote><code>
make -f Makefile.bmak all
</code></blockquote><p>
The tests are located in ACE_ROOT\tests, change to this directory.
You build then the tests with the following command:</p><p>
</p><blockquote><code>
make -f Makefile.bmak all
</code></blockquote><p>
Once you build all the tests, you can run the automated test script using:</p><p>
</p><blockquote><code>perl run_test.pl</code></blockquote><p> in the
<code>tests</code> directory to try all the tests. You need to make
sure the ACE bin and lib directory (in this case
<code>ACE_ROOT\bin</code> and <code>ACE_ROOT\lib</code>)
are on the path before you try to run the tests.</p><p>
<p></p><hr align="left" width="50%"><p>
</p><h3><a name="mingw">Building and Installing ACE on Win32 with MinGW/ MSYS</a></h3>
<p>
If you are building for a machine without a network card, you may want
to check <a href="#win32nonic">here</a> first.
</p><p>
Building and installing ACE on <a href="http://www.mingw.org/">MinGW</a>
uses a mix of a <a href="#unix">UNIX</a> building process and
<a href="#win32">Win32</a> configuration files.
Also, as MinGW uses GNU g++, you may want to take
a look at the <a href="#g++">Compiling ACE with GNU g++</a> section.
</p><p>
You will need the MinGW build tools and libraries, downloable from
<a href="http://www.mingw.org/"><tt>http://www.mingw.org</tt></a>.
<br>
For our build we require the packages
<b><tt>MinGW</tt></b> and <b><tt>MSYS</tt></b>.
</p><ol>
<li> Install the MinGW tools into a common directory, say c:/mingw.
<br><br>
</li><li> Install the MSYS tools into a common directory, say c:/msys.
<br><br>
</li><li> Open a MSYS shell. Set your <tt>PATH</tt> environment variable so
your MinGW's <tt>bin</tt> directory is first:
<blockquote><code></code><pre> % export PATH=/c/mingw/bin:$PATH
</pre></blockquote>
</li><li> Add an <tt>ACE_ROOT</tt> environment variable pointing to the
root of your ACE wrappers source tree:
<blockquote><code></code><pre> % export ACE_ROOT=/c/work/mingw/ACE_wrappers
</pre></blockquote>
From now on, we will refer to the root directory of the ACE
source tree as <tt>$ACE_ROOT</tt>.
<br><br>
</li><li> Create a file called <tt>config.h</tt> in the
<tt>$ACE_ROOT/ace</tt> directory that contains:
<blockquote><code></code><pre> #include "ace/config-win32.h"
</pre></blockquote>
</li><li> Create a file called <tt>platform_macros.GNU</tt> in the
<tt>$ACE_ROOT/include/makeinclude</tt> directory containing:
<blockquote><code></code><pre> include $(ACE_ROOT)/include/makeinclude/platform_mingw32.GNU
</pre></blockquote>
In the above text, don't replace <tt>$(ACE_ROOT)</tt> with the
actual directory, GNU make will take the value from the
environment variable you defined previously.
<p>
If you lack Winsock 2, add the line
</p><blockquote><code></code><pre> winsock2 = 0
</pre></blockquote>
before the previous one.
<br><br>
</li><li> In the MSYS shell, change to the $ACE_ROOT/ace directory and
run make:
<blockquote><code></code><pre> % cd $ACE_ROOT/ace
% make
</pre></blockquote>
<p>
This should create <tt>libACE.dll</tt> (the Win32 shared library) and
<tt>libACE.dll.a</tt> (the Win32 import library for the DLL).
Note that the name for the ACE DLL follows the MinGW convention, which itself
resembles UNIX.
</p><p>
If you want static libs also, you may run:
</p><blockquote><code></code><pre> % make static_libs=1
</pre></blockquote>
</li><li> <a name="mingwrunpath">
The same rules for Win32 search of DLLs apply for MinGW. If you
want to run some ACE programs from the MSYS shell, you may
need to add the directory for <tt>libACE.dll</tt> to your PATH:
</a><blockquote><code></code><pre><a name="mingwrunpath"> % export PATH=/c/work/mingw/ACE_wrappers/ace:$PATH
</a></pre></blockquote>
</li></ol>
<a name="mingwrunpath"><b>ACE TESTS</b></a><p>
<a name="mingwrunpath">The tests are located in <tt>$ACE_ROOT/tests</tt>.
After building the library, you can change to that directory and run
make:
</a></p><blockquote><code></code><pre><a name="mingwrunpath"> % cd $ACE_ROOT/tests
% make
</a></pre></blockquote>
<p>
<a name="mingwrunpath">Once you build all the tests, you can run
<code>run_tests.pl</code> in the
<code>tests</code> directory to try all the tests:
</a></p><blockquote><code></code><pre><a name="mingwrunpath"> % perl run_test.pl
</a></pre></blockquote>
<p>
<a name="mingwrunpath">If you are using ACE as a DLL, you will need to modify your PATH
variable as explained </a><a href="#mingwrunpath">above</a>.
</p><p>
You may want to check <tt>$ACE_ROOT/tests/README</tt> for the status
of the various tests on MinGW and the different Windows flavors.
</p><p></p><hr align="left" width="50%"><p>
</p><h3><a name="cygwin">Building and Installing ACE on Win32 with Cygwin</a></h3>
<p>
If you are building for a machine without a network card, you may want
to check <a href="#win32nonic">here</a> first.
</p><p>
Building and installing ACE on <a href="http://www.cygwin.com/">Cygwin</a>
uses the <a href="#unix">UNIX</a> building process.
Also, as Cygwin uses GNU g++, you may want to take
a look at the <a href="#g++">Compiling ACE with GNU g++</a> section.
</p><p>
You will need the Cygwin build tools and libraries, downloable from
<a href="http://www.cygwin.com/"><tt>http://www.cygwin.com</tt></a>.
For our build we require the following packages besides the packages the
setup selects by default:
<a name="cygwinpacks">
</a></p><blockquote>
<a name="cygwinpacks"><b><tt>gcc (version 3.3.3), cygserver, make, perl, binutils</tt></b>.
</a></blockquote>
<ol>
<a name="cygwinpacks"> <li> Install Cygwin (this can be easy downloading and running
<a href="http://cygwin.com/setup.exe"><tt>setup.exe</tt></a>
from the Cygwin site). For working with ACE we recommend
to select <code>DOS</code> as default text file type.
<br><br>
<li> Open a Cygwin shell. Set your <tt>PATH</tt> environment variable so
your Cygwin <tt>bin</tt> directory is first:
<blockquote><code></code><pre> % export PATH=//c/cygwin/bin:$PATH
</pre></blockquote>
or
<blockquote><code></code><pre> % export PATH=/cygdrive/c/cygwin/bin:$PATH
</pre></blockquote>
<p>
Note Cygwin uses ``<tt>/</tt>'' as directory separator,
and ``<tt>//X</tt>'' as a notation for Win32 drive <tt>X</tt>.
Note also that you <em>can't</em> use ``<tt>c:/cygwin/bin</tt>''
because, for Cygwin,
``<tt>:</tt>'' is path separator character, as in UNIX.
<br><br>
</p></li><li> Add an <tt>ACE_ROOT</tt> environment variable pointing to the
root of your ACE wrappers source tree:
<blockquote><code></code><pre> % export ACE_ROOT=c:/work/cygwin/ACE_wrappers
</pre></blockquote>
<p>
Note here you <em>can't</em> use the ``<tt>//X</tt>'' Cygwin
notation as this is seen by Cygwin's compiler and it doesn't
support that (it <em>does</em> support ``<tt>/</tt>'' as directory
separator however).
</p><p>
From now on, we will refer to the root directory of the ACE
source tree as <tt>$ACE_ROOT</tt>.
<br><br>
</p></li><li> Create a file called <tt>config.h</tt> in the
<tt>$ACE_ROOT/ace</tt> directory that contains:
<blockquote><code></code><pre> #include "ace/config-cygwin32.h"
</pre></blockquote>
</li><li> Create a file called <tt>platform_macros.GNU</tt> in the
<tt>$ACE_ROOT/include/makeinclude</tt> directory containing:
<blockquote><code></code><pre> include $(ACE_ROOT)/include/makeinclude/platform_cygwin32.GNU
</pre></blockquote>
In the above text, don't replace <tt>$(ACE_ROOT)</tt> with the
actual directory, GNU make will take the value from the
environment variable you defined previously.
</li><li> On the Cygwin shell, change to the $ACE_ROOT/ace directory and
run make:
<blockquote><code></code><pre> % cd $ACE_ROOT/ace
% make
</pre></blockquote>
<p>
This should create <tt>libACE.dll</tt> (the Win32 shared library) and
<tt>libACE.dll.a</tt> (the Win32 import library for the DLL).
Note the name for the ACE DLL on Cygwin follows the UNIX convention.
<br><br>
</p><p>
If you want static libs also, you may run:
</p><blockquote><code></code><pre> % make static_libs=1
</pre></blockquote>
</li><li> <a name="cygwinrunpath">
The same rules for Win32 search of DLLs apply for Cygwin. If you
want to run some ACE programs from the Cygwin shell, you may
need to add the directory for <tt>libACE.dll</tt> to your PATH:
</a><blockquote><code></code><pre><a name="cygwinrunpath"> # export PATH=//c/work/cygwin/ACE_wrappers/ace:$PATH
</a></pre></blockquote>
<a name="cygwinrunpath"> If you are using MPC-generated Makefiles, then the DLLs have been
placed in the lib directory instead of ace and thus your PATH
addition would need to look like this:
</a><blockquote><code></code><pre><a name="cygwinrunpath"> # export PATH=//c/work/mingw/ACE_wrappers/lib:$PATH
</a></pre></blockquote>
</li></ol>
<a name="cygwinrunpath"><b>ACE TESTS</b></a><p>
<a name="cygwinrunpath">The tests are located in <tt>$ACE_ROOT/tests</tt>.
After building the library, you can change to that directory and run
make:
</a></p><blockquote><code></code><pre><a name="cygwinrunpath"> % cd $ACE_ROOT/tests
% make
</a></pre></blockquote>
<p>
<a name="cygwinrunpath">Once you build all the tests, you can run
<code>run_tests.pl</code> in the
<code>tests</code> directory to try all the tests:
</a></p><blockquote><code></code><pre><a name="cygwinrunpath"> % perl run_test.pl
</a></pre></blockquote>
<p>
<a name="cygwinrunpath">If you are using ACE as a DLL, you will need to modify your PATH
variable as explained </a><a href="#cygwinrunpath">above</a>.
</p><p>
You may want to check <tt>$ACE_ROOT/tests/README</tt> for the status
of the various tests on Cygwin and the different Windows flavors.
</p>
<p></P>
<hr align=left width="50%">
<p>
<H2><a name="interix">Building and Installing ACE on Win32 with Interix</H2>
<P>Interix comes with a BSD style make; you need GNU make.
Make builds easily under Interix or there is a prebuilt
package at: </P>
<P><A
href="http://www.interopsystems.com/tools/warehouse.htm">http://www.interopsystems.com/tools/warehouse.htm</A> </P>
<P>If you are building for a machine without a network
card, you may want to check <A href="#win32nonic" ><FONT color=#0000ff>here</FONT></A> first. </P>
<P>This port was built and tested under Interix 3.5. a.k.a.
<A href="http://www.microsoft.com/windows/sfu/">Windows
Services for UNIX 3.5.</A></P>
<P>To build follow the <A href="#unix_traditional" >Traditional ACE/GNU Make
Configuration</A> instructions replacing the following include directives:</P>
<P><TT>#include
"ace/config-win32-interix.h"</TT> </P>
<P>for the config.h header </P>
<P>and: </P>
<P><TT>include
$(ACE_ROOT)/include/makeinclude/platform_win32_interix.GNU</TT></P>
<P>for your platform_macros.GNU file.</P>
<P>ACE should build fine with just '<TT>make</TT>', the only other option tried thus far is
'<TT>make static_libs_only=1</TT>' which also works. Any
other options may not work.</P>
<P><b>ACE TESTS</B> </P>
<p>The tests are located in <TT>$ACE_ROOT/tests</TT>. After building the library, you can
change to that directory and run make: </P><code></CODE>
<P><TT>% cd $ACE_ROOT/tests </TT><BR><TT>% make </TT>
<p>Once you build all the tests, you can run <code>run_test.pl</CODE> in the <code>tests</CODE> directory to try all the tests: </P>
<P><TT>% run_test.pl </TT></P>
<p>If you are using ACE as a shared library, you will need
to modify your LD_LIBRARY_PATH as explained in<A href="#unix_traditional" ><FONT color=#800080>Traditional ACE/GNU Make Configuration</FONT></A>. </P>
<p></P>
<p></p><hr align="left" width="50%"><p>
</p><h2><a name="vxworks">Building and Installing ACE on VxWorks</a></h2>
For the most part, you should be able to follow the instructions above
to build ACE and applications that use it. Start with the
<a href="#unix">Unix instructions</a> above to build ACE and the
applications that use it. Please see below for more information on
<a href="#VxWorks/NT">building ACE on NT hosts for VxWorks targets</a>.<p>
A few notes on VxWorks builds (thanks to
<a href="mailto:Paul_von_Behren@stortek.com">Paul von Behren</a> and
<a href="http://www.theaceorb.nl">Remedy IT</a> for these notes):</p>
<p>
</p><ul>
<li>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.<p>
</p></li><li>C++ object modules must be post-processed by a VxWorks
utility called "munch" to set up calls to static constructors and destructors.
ACE integrates the makefile includes/rules files
distributed with VxWorks to achieve maximum compatibility and reuse the target
specifications and buildcommands defined by Windriver itself.
The original ACE support for VxWorks included a perl script called
<a href="bin/ace_ld">$ACE_ROOT/bin/ace_ld</a>,
which was called from the Makefiles, replacing
the traditional <code>ld</code> step. Although this script is currently still
available it is not used anymore.<BR>
You must have perl installed to use <code>ace_ld</code>. If perl is not on your path, you'll
have to set <code>PERL_PATH</code> to the full path (including
perl.exe), either in your
<code>$(ACE_ROOT)/include/makeinclude/platform_macros.GNU</code>
or in your environment.<p>
</p></li><li>Wind River provides GCC/G++ cross-compilers for the
supported target platforms. The executables are named cc&lt;target&gt;
and g++&lt;target&gt;; for example, ccppc and g++cpp for PowerPC
targets.<p>
</p></li></ul>
You'll have to let ACE know the target type at compile time. There
are several ways to do this; please see the
<code>$ACE_ROOT/include/makeinclude/platform_vxworks5.5.x.GNU</code>
platform file for detailed information.<p>
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.</p><p>
These non-default VxWorks kernel configuration <code>#defines</code>
are required with ACE:</p><p>
</p><pre>#define INCLUDE_CPLUS /* include C++ support */
#define INCLUDE_CPLUS_IOSTREAMS /* include iostreams classes */
#define INCLUDE_POSIX_ALL /* include all available POSIX functions */
</pre>
For completeness, here are the non-default <code>#defines</code> that
we used for VxWorks 5.3.1/g++ 2.7.2:
<pre>#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 */
</pre>
Also, automatic construction/destruction of static objects
should be enabled.<p>
If you use TAO, it's also a good idea to increase the
<code>NUM_FILES</code> parameter from its default of 50 to,
say, 1000.</p><p>
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.</p><p>
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.</p><p>
Please note that the <code>main</code> entry point is renamed to
<code>ace_main</code> (configurable via ACE_MAIN) on VxWorks with g++,
to comply with its restriction against using <code>main</code>.
In addition, ACE_HAS_NONSTATIC_OBJECT_MANAGER is enabled by default
to cleanly support construction and destruction of static objects.
Please see the <a href="#NonStaticObjectManager">Non-static
ACE_Object_Manager</a> discussion for the important implication
of this feature.</p><p>
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 <code>"==ace_t=="</code> are forbidden because
that prefix is used internally by ACE.</p><p>
You can spawn a new task to run <code>ace_main</code>, using either
VxWorks <code>sp</code>, or ACE'S <a name="spa"><code>spa</code></a>.
<code>spa</code> can be used from the VxWorks shell to pass arguments
to <code>ace_main</code>. Its usage is:
</p><pre><code>
spa ace_main, "arg1" [, ...]
</code></pre>
All arguments must be quoted, even numbers. You can start also ace_main
without spawning another thread by using:<p>
</p><pre><code>
spaef ace_main, "arg1" [, ...]
</code></pre>
ACE also provides the function <code>vx_execae</code> which is capable of running
<code>ace_main</code> in a separate thread, wait for the task to finish and return
the return code from <code>ace_main</code>:
<pre><code>
int vx_execae (FUNCPTR acemain,char* arguments, int prio = 0, int opt = 0, int stacksz = 0);
</code></pre>
<p>
You could call this from the VxWorks shell like:
</p>
<pre><code>
my_rc = vx_execae ace_main, "-o server.ior -ORBDottedDecimalAddresses 1"
</code></pre><p>
When <code>prio</code>, <code>opt</code> or <code>stacksz</code> are omitted or specified
as <code>0</code> default values will be used. See the VxWorks shell documentation for the
defaults for <code>prio</code> and <code>opt</code>. For <code>stacksz</code> the default is
<code>ACE_NEEDS_HUGE_THREAD_STACKSIZE</code>.
The <code>arguments</code> string will be parsed and passed on to <code>ace_main</code> as
a regular <code>argc</code> and <code>argv</code>.</p><p>
Be aware of the fact that when you execute <code>ace_main</code> directly from the VxWorks
shell argc will be zero and argv* will also be zero. Using <code>argv[0]</code> will not return
the program name, but will result in a crash.<br>
The ACE helper functions <code>spa</code>, <code>spaef</code> and <code>vx_execae</code> prevent
this problem by building a regular <code>argc</code> and <code>argv</code> which also contain a
valid <code>argv[0]</code> element.</p>
<h3><a name="VxWorks/SharedLibs">Building Shared Libraries for VxWorks</a>.</h3>
<strong>NOTE</strong>: Since VxWorks support is currently being reworked with
an initial focus on static builds the support for shared builds is momentarily
broken. This will be remedied(!) as soon as possible.<p>
ACE supports shared libraries for VxWorks, but only with the g++
compiler. To build shared libraries instead of the default static
libraries, added <code>shared_libs=1</code> (<strong>not</strong>
<code>shared_libs_only=1</code>) to either your
<code>ACE_wrappers/include/makeinclude/platform_macros.GNU</code> or
your <code>make</code> invocation. Then, be sure to load the ACE (and
any other) shared library before loading your executable(s).</p><p>
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 <strong>must</strong>
be reentrant if you shared it between programs (tasks). The
ACE library meets this requirement.</p><p>
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:
</p><pre><code>
-&gt; ld &lt; libACE.so
</code></pre>
Shared libraries can be unloaded the same way an executable
(module) is unloaded.<p>
<strong>NOTE</strong>: 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' <em>Programmers Guide</em>.</p><p>
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 <a href="TAO/performance-tests/Cubit/TAO/IDL_Cubit/collocation_test.cpp">collocation
test</a> is a good example.</p><p>
</p><h3><a name="VxWorks/LinkToKernel">Linking ACE and/or TAO Libraries into the VxWorks Kernel</a>.</h3>
It's easy to link your ACE and/or TAO libraries into the VxWorks kernel.
Just build <a href="#VxWorks/SharedLibs">shared versions</a>, but
disable the munch step. The easiest way to do that is to set the
<code>LD</code> make variable to the name of your linker. For
example, to build a libACE.so for PowerPC that can be linked into
the kernel:
<pre>% cd $ACE_ROOT/ace
% make LD=ldppc shared_libs=1
</pre>
After building the shared lib, link it into the kernel by setting
the <code>MACH_EXTRA</code> make variable in the kernel configuration
Makefile. Then, build the kernel using <code>make exe</code>.<p>
</p><h3><a name="VxWorksTestScript">Using the one-button ACE tests with VxWorks</a>.</h3>
It is possible to generate a script to execute all ACE tests. You can do this by executing
</a></p><blockquote><code></code><pre><a name="vxworksscript">% perl run_test.pl -v -o > run_test.vxworks
</a></pre></blockquote>
The ACE tests write their output files in a directory named
<code>log/</code>, below the current (<code>tests</code>) directory.<br/>
</p>
<p>
To run the tests from the build directory on an NT host where you crossbuild your
VxWorks ACE/TAO you can set up the Target Server File System (TSFS) in your Target Server
configuration. If you f.i. set the root for the TSFS to the root directory of your builddisk
you can set the default directory for the target by issueing the following command
from a Host shell: '@cd "/tgtsvr/{path to ACE}/ACE_wrappers/tests"'.
The '@' addition makes sure this command is executed for the target environment and not the
local host shell environment.
If you also issue the command 'cd {path to ACE}/ACE_wrappers/tests' you can execute the
generated one button testscript like: '&lt; run_test.vxworks'.
</p>
<p>
Running the ACE tests automatically from the ACE autobuild tool using Target Server and Host
shell options is also supported.
</p>
<p>
If you don't have NFS included in your VxWorks kernel, you can use these steps, provided by
<a href="mailto:clarence_m_weaver@md.northgrum.com">Clarence M. Weaver</a>,
to run the tests and capture their output:</p><p>
</p><ol>
<li>What I did was create a log directory on the boot NT host of my VxWorks
target.<p>
</p></li><li>I copied all the test applications and the run_test.vxworks script to
the parent of the log directory.<p>
</p></li><li>Using the target shell not the host shell, I "cd" to the directory
containing the script and test programs.<p>
</p></li><li>Invoked the script using <code>&lt; run_test.vxworks</code> from this target shell.<p>
</p></li></ol>
<a href="mailto:Kirk.Davies@pobox.com">Kirk Davies</a> provided this
approach for running the ACE tests on Tornado II:
<ul>
<li>Under Tornado II, I set up the Target Server File System (TSFS), and
the test logs get written to the log subdirectory under that.<p>
</p></li><li>You have to set an environment variable before running the tests:
<pre>putenv("ACE_TEST_DIR=/tgtsvr")
</pre><p>
</p></li></ul>
</p><h3><a name="VxWorks/NT">Building ACE on Tornado/NT hosts for VxWorks targets</a>.</h3>
The following, very useful information was contributed by
<a href="http://people.qualcomm.com/cryan">Chris Ryan</a>
and <a href="mailto:Paul_von_Behren@stortek.com">Paul von Behren</a>.
Please submit corrections, additions, or clarifications to the
the <a href="mailto:ace-users@cse.wustl.edu">ACE mailing list</a>.<p>
<strong>NOTE:</strong>The make (version 3.74) that is provided with
Tornado 2.2 cannot be used to build ACE. A working version is available
from the WindRiver support site, download the
<a href="https://secure.windriver.com/cgi-bin/windsurf/downloads/view_binary.cgi?binaryid=838">
make3_80.gvk_patches</a> and the
<a href="https://secure.windriver.com/cgi-bin/windsurf/downloads/view_binary.cgi?binaryid=100340">
make3_80.tor2_2.new_dependency_rules</a> package and install them.</p><p>
Using the Cygnus tools, this approach works:
</p><ul>
<li>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.<p>
</p></li><li>Set up your
<code>ACE_wrappers/include/makeinclude/platform_macros.GNU</code>
as usual for VxWorks. See
<a href="include/makeinclude/platform_vxworks5.5.x.GNU">the
g++/VxWorks platform file</a> for more information.<p>
</p></li><li>Create an <code>ACE_wrappers/ace/config.h</code> file that looks
something like the following.
<pre>#if defined (_MSC_VER) || defined (__BORLANDC__)
# include "ace/config-win32.h"
#else
# include "ace/config-vxworks5.x.h"
#endif
</pre><p>
</p></li><li>Set your <code>ACE_ROOT</code>, <code>CPP_LOCATION</code>,
<code>WIND_BASE</code>, and <code>WIND_HOST_TYPE</code> environment
variables.<p>
</p></li><li>Build for NT, then build for VxWorks.<p>
</p></li></ul>
A few additional Windows Notes, from Paul von Behren:<p>
</p><ul>
<li>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 <a href="http://www.cygnus.com/misc/gnu-win32/">http://www.cygnus.com/misc/gnu-win32/</a>
A related link is <a href="ftp://ftp.cygnus.com/pub/gnu-win32/latest/">ftp://ftp.cygnus.com/pub/gnu-win32/latest/</a><p>
</p></li><li>To set up the command-prompt build environment, run
<code>Tornado\host\x86-win32\bin\TorVars.bat</code>. This is done
implicitly within the Tornado IDE.<p>
</p></li><li>To run <code>ace_ld</code>, you still need perl installed -
see <a href="http://www.activestate.com/software/default.htm">http://www.activestate.com/software/default.htm</a>
for Windows perl.<p>
</p></li><li>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 <code>ACE_ROOT</code> defined
before starting Tornado, you can specify an ACE Makefile as a Tornado
target and Tornado will then call make from the menu.<p>
</p></li></ul>
And Chris Ryan's instructions for building for VxWorks targets
on Windows NT hosts:
<ol>
<li>Path setting that seems to be working is:<p>
</p><pre> /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
</pre>
Other environment variables:<p>
</p><pre> 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
</pre>
</li><li><code>/tornado</code> is the root of the Tornado install
(<code>$WIND_BASE</code>).
</li><li><code>/gnuwin32</code> is the root of a Cygnus GNU download and install.
</li><li><code>/bin</code> content is:<p>
</p><pre> aced.dll
cygwin.dll
perl.exe
rm.exe
sh.exe
true
</pre>
<code>aced.dll</code> is produced in an ACE NT source tree according to
documented procedure for Windows VC++ ACE build.
<code>cygwin.dll</code> is from the Cygnus GNU software download and install.
</li><li>Basically, follow documented procedure for ACE build/install on UNIX
platform. Create a <code>$ACE_ROOT/ace/config.h</code> that looks
like:<p>
</p><pre> #include "config-vxworks5.x.h"
</pre>
And create a
<code>$ACE_ROOT/include/makeinclude/platform_macros.GNU</code>
that looks like:<p>
</p><pre>
WIND_BASE = /tornado
WIND_HOST_TYPE = x86-win32
CPU = I80486
include $(ACE_ROOT)/include/makeinclude/platform_vxworks5.5.x.GNU
</pre>
</li><li>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.,
<pre> make --unix static_libs=1
</pre>
</li></ol>
<h3>TAO on NT Tornado host, VxWorks target.</h3>
<ol>
<li>Build ACE and TAO_IDL in the NT tree as already documented.
Be sure to build ACE's gperf on NT, in
<code>ACE_wrappers/apps/gperf/src</code>.<p>
</p></li><li>Build $TAO_ROOT/tao
<pre> CPP_LOCATION=/Program Files/DevStudio/VC/bin/CL.exe
cd $TAO_ROOT/tao
/gnuwin32/b18/H-i386-cygwin32/bin/make
</pre>
</li><li>Build orbsvcs.
<pre> CPP_LOCATION=/Program Files/DevStudio/VC/bin/CL.exe
cd $TAO_ROOT/orbsvcs/orbsvcs
/gnuwin32/b18/H-i386-cygwin32/bin/make
</pre>
</li><li>Build $TAO_ROOT/tests<p>
</p></li></ol>
<h3><a href="mailto:Jaffar_Shaikh@Mitel.COM">Jaffar Shaikh's</a>
Notes for Building ACE and TAO for VxWorks on NT host</h3>
<b></b><p><b>Scenario:</b> 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.</p>
<b><p>Host System:</p>
</b><p>NT 4.0 workstation with 128 M RAM, 266MHz Pentium.</p>
<b><p>Software Needed For Building TAO</p>
</b><p>1) Active State's ActivePerl from
<a href="http://www.activestate.com/software/default.htm">http://www.activestate.com/software/default.htm</a>
</p>
<p>2) Tornado 2.2.1 from Windriver.</p>
<p>3) Cygwin GNU to build TAO. It is available for NT as a freeware
from the <a href="http://www.cygwin.com">Cygwin</a> site</p>
<p>The Cygwin Make (version 3.75) can only build the TAO not the
Tornado II make (version 3.74)</p>
<b><p>Environment Variables:</p>
</b><p>On NT the environment Variables are set as follows, (from
Control Panel-&gt; System -&gt; Environment)</p>
<p>I added following Environment variable entries to PATH </p>
<p>C:\Perl\bin\;</p>
<p>C:\tornado\host\x86-win32\bin;</p>
<p>C:\tornado\host\x86-win32\powerpc-wrs-vxworks\bin;</p>
<p>C:\tornado\host\x86-win32\lib\gcc-lib\powerpc-wrs-vxworks\cygnus-2.7.2-960126;</p>
<p>C:\Corba\Ace_wrappers\bin;</p>
<p>C:\Cygwin\bin;</p>
<p>C:\Cygwin\usr\bin;</p>
<p>C:\bin</p>
<p>Additional Environmental variables and the values,</p>
<p>CPU=PPC860</p>
<p>LD_LIBRARY_PATH=</p>
<p>SHELL=/bin/sh.exe</p>
<p>ACE_ROOT=/Corba/ACE_wrappers</p>
<p>WIND_BASE=/tornado</p>
<p>SHELL=/bin/sh.exe</p>
<p>TERM=pcbios</p>
<p>TAO_ROOT=/Corba/ACE_wrapper/Tao</p>
<p>CPP_LOCATION=/Program Files/Microsoft Visual Studio/VC98/Bin/CL.exe</p>
<p>GCC_EXEC_PREFIX=/tornado/host/x86-win32/lib/gcc-lib/</p>
<p>WIND_HOST_TYPE=x86-win32</p>
<p>PERL_PATH=/perl/bin/perl.exe</p>
<b><p>Directories of importance</p>
</b><p>C:\Corba &lt;-- Ace_wrappers (uzipped)</p>
<p>C:\tornado &lt;-- Tornado installed</p>
<p>C:\Perl &lt;-- Perl installed</p>
<p>C:\Cygwin &lt;-- Cygwin installed</p>
<p>C:\bin &lt;-- Copy these files,</p>
<p> Ace.dll, &lt;-- After you build Ace</p>
<p> gperf.exe &lt;-- After you build gperf</p>
<p> Cygwin1.dll, &lt;-- After you install Cygwin</p>
<p> perl.exe, &lt;-- After you install Perl</p>
<p> rm.exe &lt;-- After you install Cygwin</p>
<p> sh.exe &lt;-- After you install Cygwin</p>
<p> true &lt;-- After you install Cygwin</p>
<b><p>Create Files</p>
</b><p>1) C:\Corba\ACE_Wrappers\ace\config.h</p>
<p>with entry</p>
<p>#if defined (_MSC_VER) || (__BORLANDC__)</p>
<p> #include "ace/config-win32.h"</p>
<p>#else</p>
<p> #define ACE_HAS_IP_MULTICAST </p>
<p> #include "ace/config-vxworks5.x.h"</p>
<p>#endif</p>
<p>2) C:\Corba\ACE_wrappers\include\makeinclude\platform_macros.GNU</p>
<p>WIND_BASE = /tornado</p>
<p>WIND_HOST_TYPE = x86-win32</p>
<p>include
$(ACE_ROOT)/include/makeinclude/platform_vxworks5.5.x.GNU</p>
<p>ACE_COMPONENTS=FOR_TAO (you may choose this option to build ACE
library that supports TAO)</p>
<p></p>
<b><p>Steps to Build</p>
</b><p>1) Build Ace.dll under NT</p>
<p>In MS Visual C++ open C:\Corba\ACE_wrappers\ace.sln And build Ace
DLL</p>
<p>Copy Ace.dll in C:\bin</p>
<p>2) Build gperf utility under NT</p>
<p>In MS Visual C++ open
C:\Corba\ACE_wrappers\apps\gperf\src\gperf.sln. Build gperf.exe</p>
<p>Copy gperf.exe to C:\bin</p>
<p>3) Mount Directries in Cygwin</p>
<p>Click on Cygnus Solutions -&gt; Cygwin Bash Shell</p>
<p>Mount following directories by using mount command.</p>
<p>create respective directories first then use mount command </p>
<p>e.g. Create /Corba directory then use $mount -s "C:\Corba"
/Corba</p>
<p>C:\Corba mount to /Corba</p>
<p>C:\tornado mount to /tornado</p>
<p>C:\Perl mount to /perl</p>
<p>C:\Cygwin mount to /cygwin</p>
<p>C:\bin mount to /bin</p>
<p>C:\Program Files mount to /Program Files </p>
<p>4) Build ACE in Cygwin</p>
<p>$cd /Corba/ACE_wrappers/ace </p>
<p>$make static_libs=1</p>
<p>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.</p>
<p>5) Build TAO in Cygwin</p>
<p>$cd $TAO_ROOT/tao</p>
<p>$make debug=0 optimize=1 static_libs_only=1 minimum_orb=1
</p>
<p>for shared libs use shared_libs=1</p>
<p>The minimum Tao does not have following components,</p>
<p>Dynamic Skeleton Interface</p>
<p>Dynamic Invocation Interface</p>
<p>Dynamic Any</p>
<p>Interceptors</p>
<p>Interface Repository</p>
<p>Advanced POA features</p>
<p>CORBA/COM interworking</p>
<p>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.</p>
<p></p><hr align="left" width="50%">
<hr>
<h1><a name="svcsinstall">Building and Installing ACE Network Services</a></h1>
The following explains how to build the ACE <a href="http://www.cs.wustl.edu/%7Eschmidt/ACE-netsvcs.html">network services</a> on <a href="#unixsvcs">UNIX</a> and <a href="#win32svcs">Win32</a>.
<p></p><hr align="left" width="50%"><p>
</p><h2><a name="unixsvcs">Building and Installing ACE Network Services on UNIX</a></h2>
Building and installing ACE Network Services on UNIX is relatively
simple (the <a href="#win32svcs">process</a> for Win32 is different).
Here's what you need to do:<p>
</p><ol>
<li>Build and install ACE on UNIX as described <a href="#unix">earlier</a>. 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
(<code>main</code>) contained in <a href="netsvcs/servers/main.cpp">$ACE_ROOT/netsvcs/servers/main.cpp</a>
should also be compiled and ready to run.<p>
</p></li><li>Set your <code>LD_LIBRARY_PATH</code> environment variable to
where the binary version of the ACE netsvcs library. For
example, you probably want to do something like the following<p>
</p><pre><code>
% setenv LD_LIBRARY_PATH $ACE_ROOT/ace:$ACE_ROOT/lib:$LD_LIBRARY_PATH
</code></pre><p>
</p></li><li>By default, if the shared object library is built, the services
are linked into the <code>main</code> driver program dynamically.
To specify which services should be linked in and executed, edit the
<a href="netsvcs/servers/svc.conf">$ACE_ROOT/netsvcs/servers/svc.conf</a>
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
<a href="http://www.cs.wustl.edu/%7Eschmidt/ACE_wrappers/ACE-papers.html#config">Service Configurator</a>
documentation to learn how the configuration file is parsed and
how the services are dynamically linked and executed. In
addition, refer to the <a href="http://www.cs.wustl.edu/%7Eschmidt/ACE-netsvcs.html">Network
Services</a> documentation to learn more about how to configure
each network service.<p>
</p></li><li>If you only want to link the services statically, simply remove
or rename the svc.conf file.<p>
</p></li></ol>
<p></p><hr align="left" width="50%"><p>
</p><h2><a name="win32svcs">Building and Installing ACE Network Services on Win32</a></h2>
Once again, there are supplied project for Visual C++ 7.1 or later for
the Network Services.<p>
</p><hr>
<h1><a name="sslinstall">Building and Installing the ACE_SSL Library</a></h1>
<p>The first step for all platforms is to build and install the
<a href="http://www.openssl.org/">OpenSSL</a> distribution. The
ACE_SSL library must then be built according to the instructions
below.</p>
<h2>Unix</h2>
<ol>
<li>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. <code>LD_LIBRARY_PATH</code>). If you
installed OpenSSL into a set of directories unknown by the compiler,
set the <code>SSL_ROOT</code> environment variable to point to the
top level directory of your OpenSSL distribution, i.e. the one
containing OpenSSL's <code>include</code> and <code>lib</code>
directories.</li>
<li>Build ACE as described above. When building ACE, add
<code>ssl=1</code>
to your <code>make</code>
command line invocation, or add it to your
<code>platform_macros.GNU</code> file.</li>
<li>Build the ACE_SSL library in the <tt>$ACE_ROOT/ace/SSL</tt>
directory. The <code>ACE_ROOT</code> environment variable should be set
prior to this point.</li>
</ol>
<h2>Microsoft Visual Studio</h2>
<ol>
<li>Set the <code>SSL_ROOT</code> environment variable to the location
of the directory containing the OpenSSL <code>inc32</code> and
<code>out32dll</code> directories.
<li>Add <code>ssl=1</code> to your MPC
<code>$ACE_ROOT/bin/MakeProjectCreator/config/default.features</code>
or <code>$ACE_ROOT/local.features</code> file, and re-run MPC to add
support for building the ACE_SSL library to your MSVC++
workspaces and projects.
<li>Open the <code>ACE.sln</code> solution, and refer to the ACE build
and installation instructions above for details on creating a
<code>config.h</code> configuration header for this platform. Once
the <code>config.h</code> file has been created, build the
<code>ACE_SSL</code> project.</li>
</ol>
<h2>CodeGear C++</h2>
<p>Support for building ACE's ACE_SSL library and TAO's SSLIOP
pluggable protocol with CodeGear C++ does exist.
<ol>
<li>Set the <code>SSL_ROOT</code> environment variable to the location
of the directory containing the OpenSSL <code>inc32</code> and
<code>out32</code> directories.
<li>Add <code>ssl=1</code> to your MPC
<code>$ACE_ROOT/bin/MakeProjectCreator/config/default.features</code>
or <code>$ACE_ROOT/local.features</code> file, and re-run MPC to add
support for building the ACE_SSL library to your CodeGear C++ makefiles.
<li>Build ACE and TAO.
</ol>
</p>
<hr><p>
</p><h1><a name="guireactor_install">Building and Using GUI Reactors Libraries</a></h1>
There is a general method for building and using <code>ACE_Reactors</code> for various GUI
libraries.
<h2> Building GUI Reactor Library </h2>
<ol>
<li>Try to generate build files using MPC. Inspect the output of MPC to find out which features are
necessary to build given reactor. Add these features to
<code>ACE_wrappers/bin/MakeProjectCreator/*.features</code> file, or pass them directly to MPC
using <code>-features</code> command line option. For example, for <code>FlReactor</code> the procedure
consists of five steps
<ol>
<li> In the first pass one gets that <code>x11</code> (X11 libraries) is missing.<br>
<code>$ mwc.pl -type gnuace
Skipping ACE_FlReactor (ace_flreactor.mpc), it requires x11.
</code></li>
Ensure that <code>X11</code> libraries are installed, then pass <code>x11=1</code> feature to MPC.
<li>In the second pass one gets that <code>gl</code> (OpenGL library) is missing.<br>
<code>$ mwc.pl -type gnuace -features x11=1 ace.mwc
Skipping ACE_FlReactor (ace_flreactor.mpc), it requires gl.
</code></li>
Ensure that <code>OpenGL</code> libraries are installed, then pass <code>gl=1</code> feature to MPC.
<li>In the third pass one gets that <code>fl</code> (Fast Light Toolkit) is missing.<br>
<code>$ mwc.pl -type gnuace -features x11=1,gl=1 ace.mwc
Skipping ACE_FlReactor (ace_flreactor.mpc), it requires fl.
</code></li>
Ensure that <code>Fast Light Toolkit</code> libraries are installed, then pass <code>fl=1</code>
feature to MPC.
<li>In the fourth pass one gets that <code>ace_flreactor</code> feature is missing<br>
<code>$ mwc.pl -type gnuace -features x11=1,gl=1,fl=1 ace.mwc
Skipping ACE_FlReactor (ace_flreactor.mpc), it requires ace_flreactor.
</code></li>
Allow MPC to generate makefiles for <code>FlReactor</code> by setting <code>ace_flreactor=1</code> feature.
<li>In the last pass one obtains files for building <code>FlReactor</code>.<br>
<code>$ mwc.pl -type gnuace -features x11=1,gl=1,fl=1,ace_flreactor=1 ace.mwc
</code></li>
</ol>
Currently to simplify MPC generation some of features are turned on by default in
<code>ACE_wrappers/bin/MakeProjectCreator/global.features</code>. For examples to generate
files related with Fl one has to provide only fl=1 feature. To obtain a more fine grained controll
over MPC generation process one may modify <code>ACE_wrappers/bin/MakeProjectCreator/*.features</code>
files.
</li>
<li> Required build files are generated now, it is enough then to invoke build tool.
For example for under <code>MPC::gnuace</code> one has to call
<code>make fl=1</code>. For <code>MPC::vc7</code> target all features are
encoded in generated project files, thus it is enough to compile ACE using MSVC.
</li>
</ol>
The build procedure leads to a specific GUI Reactor library. For example, for
<code>Qt</code> and <code>Linux </code> one gets <code>libQtReactor.so</code>, while for
<code>Windows</code> the results are shared <code>QtReactor.dll</code> and import
<code>QtReactor.lib</code> libraries or their variants depending on build options.
When compiling TAO also GUI related libraries are created like <code>libTAO_QtResource.so</code>.
<h2> Using GUI Reactor Library </h2>
Here one has at least three use cases:
<ol>
<li><b>Applications with their own build system.</b>
To use ACE support for GUI one has to include specific GUI headers and
link with specific <code>ACE_[GUI]Reactor</code> library. When using TAO support for GUI one has
also to link with specific <code>TAO_[GUI]Resource</code> library.</li>
<li><b>Applications with build system using MPC.</b>
In general, it is better to create specific base projects for using ACE GUI support in such application.
Base projects provided by ACE <code>ACE_wrappers/bin/MakeProjectCreator/[ace,tao]_[gui][reactor,resource].mpb</code>
may be an examples of how to do this.</li>
<li><b>Internal ACE applications like tests or examples.</b>
MPC project for internal ACE application using GUI support should be derived from
<code>ace_[gui]reactor.mpb</code> base projects. To employ TAO support for GUI one should derive
the project from <code>tao_[gui]resource.mpb</code> These base projects ensure that all necessary libraries
are linked to the application, specifies features necessary to build a project and moreover impose a
build order consistant with ACE. For example, the application project using <code>XtReactor</code> should be
derived from <code>ace_xtreactor.mpb</code>.</li>
</ol>
<h2>Notes on specific GUI Reactors</h2>
<ul>
<li> <code>QtReactor</code></li>
The build is controlled by <code>ace_qtreactor</code> [1 by default] feature.
To build this reactor one has to provide feature <code>qt</code> [0 by default] (Qt library). Moreover,
it is assumed that <code>Qt</code> was installed in a standard way
and <code>QTDIR</code> points to <code>Qt</code> installation folder. To build TAO
support for <code>Qt</code> one should use <code>tao_qtresource</code> [1 by default] feature.
<li> <code>XtReactor</code></li>
The build is controlled by <code>ace_xtreactor</code> [1 by default] feature.
To build this reactor one has to provide the following features: <code>x11</code> [1 by default]
(X11 libraries) and <code>xt</code> [1 by default] (X11 Toolkit).
Moreover, some examples and tests related with <code>XtReactor</code>
needs additionall features namely either <code>motif</code> [0 by default] (Motif/Lesstif libraries) or
<code>athena</code> [0 by default] (Athena widgets). To build TAO
support for <code>xt</code> one should use <code>tao_xtresource
</code> [1 by default] feature.
<li> <code>TkReactor</code></li>
The is controlled by <code>ace_tkreactor</code> [1 by default] feature. To build this reactor one has to provide
<code>tk</code> [0 by default] (Tcl libraries) feature. To build TAO
support for <code>Tk</code> one should use <code>tao_tkresource</code> [1 by default] feature.
<li> <code>FlReactor</code></li>
The build is controlled by <code>ace_flreactor</code> [1 by default] feature.
To build this reactor one has to provide the following features: <code>x11</code>
[1 by default] (X11 libraries),
<code>gl</code> [1 by default] (OpenGl) and <code>fl</code>
[0 by default] (Fast Light Toolkit). To build TAO
support for <code>Fl</code> one should use <code>tao_flresource</code> [1 by default] feature.
<strong>MS Windows:</strong> The paths to <code>fltkdll</code> and
<code>OpenGL32</code> libraries, as well as <code>fltk</code> header files
should be setup manually for succesfull compilation. Obviosuly,
<code>x11</code>switch is ignored for this platform.</li>
</ul>
<hr>
<h1><a name="installnotes">Installation Notes</a></h1>
<ul>
<li><b>Windows (Windows NT, 2000, XP, 2003, etc., and Windows '9x/ME) </b><p>
Please see the <a href="#NonStaticObjectManager">Non-static
ACE_Object_Manager</a> discussion below.</p><p>
</p></li><li><b>Windows CE</b><p>
Take a look at (<a href="docs/CE-status.txt">CE-status.txt</a>) for
up-to-date information about ACE on Windows CE and Windows Mobile.
</p></li><li><b> Solaris 7, 8, 9, and 10 using Sun ONE Studio 8 (C++ 5.5)
or higher, Centerline C++ 2.x, GNU gcc 2.95 and
later.</b><p>
All the source code and tests should build and run without any
problems on Solaris 7, 8, and 9 platforms using the above
Sun C++ compilers.
There are likely to be build problems with older versions or
different patchlevels of Sun C++. Likewise, on
Solaris with g++ you may need to use GNU as instead of
/usr/ccs/bin/as, if you want -gstabs+ and -pipe support.
Thanks to Susan Liebeskind &lt;shl@janis.gtri.gatech.edu&gt;
for providing the following useful information:</p><p>
By default, ACE uses both the Solaris and POSIX thread
interface. To disable use of the Solaris thread interface, add
<code>-D_POSIX_PTHREAD_SEMANTICS</code> to the
<code>CFLAGS</code> in your
<code>$(ACE_ROOT)/include/makeinclude/platform_macros.GNU</code>.
See the Solaris Intro (3) man page for more information.</p><p>
To disable ACE thread support completely, build with the
<code>threads=0</code> make flag. See the <a href="#flags">Makefile Flags</a> section below for more
information on make flags.</p><p>
If you use g++ on Solaris 7, you might need to rebuild
it on a SunOS 5.7 (Solaris 7) host. Some versions of g++
provide replacements for system header files. The
replacements on older SunOS systems are not compatible with the
SunOS 5.7 system headers. </P>
</li><li><b>AIX</b><p>
ACE is currently supported on AIX 5.2 and higher using IBM's
Visual Age C++ 6 and XL C++ 7 compilers as well as g++ 3.2.</p><p>
The <code>ace/config-aix-5.x.h</code> file is recommended for all
compilers on all AIX 5L versions. The Asynchronous I/O functionality
is disabled by default because its use requires the system administrator
to explicitly enable it in the kernel using SMIT. If this has been
done and you want to enable asynchronous I/O support in ACE, add:
<code>#define ACE_HAS_AIO_CALLS</code> to your <code>config.h</code>
file before including <code>ace/config-aix-5.x.h</code>.</p><p>
The Visual Age 6.0.0.3 and 6.0.0.4 do have some bugs that makes
them unusable for building TAO. TAO has been tested with 6.0.0.12 and
had no problems with that version.</p><p>
For your <code>platform_macros.GNU</code> file, you should use
<code>platform_aix_ibm.GNU</code> when building ACE with any of the
IBM compilers and <code>platform_aix_g++.GNU</code> when building ACE
with g++.</p><p>
BTW, here's a technique from Rob Jordan &lt;<a href="mailto:jordan@hursley.ibm.com">jordan@hursley.ibm.com</a>&gt;
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.</p><p>
Here's how to optimise the ACE library generation:</p><p>
Look at the <a href="ace/GNUmakefile.ACE">ace/GNUmakefile.ACE</a>
in <code>$ACE_ROOT/ace</code>. Create a file called
<code>ACE_All_Src.cpp</code>, and add a line to #include
each of the source files
listed under <code>FILES=</code> in the GNUmakefile. Create a
file called <code>ACE_All_Tmp.h</code>
and add a line to #include each of the .h files listed under
<code>TEMPLATE_FILES=</code> in the GNUmakefile. Now update the
GNUmakefile so that
<code>FILES=ACE_All_Src</code> and
<code>TEMPLATE_FILES=ACE_All_Tmp</code>.</p><p>
</p></li><li><b><a name="Linux">Linux</a></b><p>
ACE has been ported to <a href="http://www.cs.wustl.edu/%7Ecleeland/ace/">Linux</a> 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. Use the
<code>platform_linux.GNU</code> and <code>ace/config-linux.h</code>
in your <code>platform_macros.GNU</code> and
<code>config.h</code> files, respectively. The same
files can be used on PowerPC, with LinuxPPC
1999 (R5), with glibc 2.1.1.</p><p>
If you run out of memory, it's easy to add virtual memory on
Linux. Please see the <code>mkswap</code> man page. You'll
need at least 256 to 300 Mb of virtual memory (RAM + swap) to
compile all of ACE+TAO. The <a href="#resource_requirements">System
Resource Requirements section</a> has some suggestions on how
to reduce the memory requirement.</p><p>
The glibc 2.0 dynamic loader isn't thread safe. If you want to
use the Invocation API you'll have to set
<code>LD_BIND_NOW=true</code>. If you want to use
<code>dlopen</code>, you should use <code>RTLD_NOW</code>. The
dynamic loader in glibc 2.1 is thread safe.</p><p>
<strong>NOTE:</strong> The TAO NameService uses IP multicasting
by default, though it is not required. IP multicast on Linux
requires the following:</p><p>
</p><ul>
<li>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.<p>
</p></li><li>Enable IP multicast in ACE. It is enabled by default in
<code>ace/config-linux-common.h</code>. If you don't use
IP multicast, add <code>#define ACE_HAS_IP_MULTICAST 0</code>
to your <code>ace/config.h</code> before building ACE.<p>
</p></li><li>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 <code>eth0</code>. If
you don't have or use linuxconf, try adding a multicast
routing table entry using something like this:<p>
</p><pre> <code># route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0</code>
</pre><p>
</p></li></ul>
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.</p><p>
</p></li><li><b>SCO UNIX</b><p>
ACE has been ported to SCO UNIX using the GNU g++ 2.7.2
compiler. Arturo Montes &lt;<a href="mailto:mitosys@colomsat.net.co">mitosys@colomsat.net.co</a>&gt;
maintains this code. In addition, he also maintains a version
of <a href="http://www.cs.wustl.edu/%7Eschmidt/ACE_wrappers/FSU-threads.tar.gz">FSU pthreads</a>.</p><p>
</p></li><li><b>SGI IRIX 5.x and 6.x</b><p>
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.</p><p>
</p></li><li><b>OSF/1 3.2 and 4.0 (a.k.a. Digital UNIX 4.0)</b> <p>
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.</p><p>
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_ROOT)/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.</p><p>
NOTE: if you use Digital UNIX 4.0f or later, you <strong>must</strong>
use <code>ace/config-tru64.h</code> instead of
<code>ace/config-osf1-4.0.h</code>. <code>ace/config-tru64.h</code>
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 <strong>must</strong> use
<code>include/makeinclude/platform_tru64_cxx.GNU</code> instead of
<code>include/makeinclude/platform_osf1_4.0.GNU</code>.</p>
</li><li><b> FreeBSD </b><p>
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. </p><p>
Notice that on older FreeBSD, <code>ld.so</code> only looks for
so libraries with <b>version number</b> appended. ACE makefiles
create symlinks for most shared libraries if
<code>versioned_so</code> is defined to 1 in
<code>$ACE_ROOT/ace</code> 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: </p><p>
<code>ln -sf $ACE_ROOT/ace/libACE.so $ACE_ROOT/ace/libACE.so.4.5</code></p><p>
On newer FreeBSD (3.0 or later,) this is no longer necessary.</p><p>
</p></li><li><b>NetBSD</b><p>
Like older FreeBSD, NetBSD's <code>ld.so</code> also requires
versioned .so files.</p><p>
</p></li><li><b>OpenBSD</b><p>
ACE has been ported to OpenBSD 3.1 and GNU g++ 2.95.3.</p><p>
As with FreeBSD and NetBSD, OpenBSD requires versioned .so
files. This is currently handled by the build files and no
additional work is needed.</p><p>
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.</p><p>
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.</p><p>
</p></li><li><b> UnixWare </b> <p>
Steve Huston &lt;<a href="mailto:shuston@riverace.com">shuston@riverace.com</a>&gt;
has ported ACE to work with UnixWare 2.01 and g++.</p><p>
Ganesh Pai &lt;<a href="mailto:gpai@voicetek.com">gpai@voicetek.com</a>&gt;
subsequently did the port for version 2.1.2, also with g++.</p><p>
Phil Mesnier &lt;<a href="mailto:mesnier_p@ociweb.com">
mesnier_p@ociweb.com</a>&gt; updated the port to support
UnixWare 7.1.0, with help from Michael Meissnitzer
&lt;<a href="mailto:michael.meissnitzer@siemens.at">
michael.meissnitzer@siemens.at</a>&gt;, Christian Klepp &lt;
<a href="mailto:christian.klepp@siemens.at">christian.klepp@siemens.at
</a>&gt; and Engelbert Staller &lt;<a href="http://www.cs.wustl.edu/%7Eschmidt/ACE_wrappers/engelbert.staller@siemens.at">
engelbert.staller@siemens.at</a>&gt;
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):<br>
</p><pre> mkdir /usr/local/newgnu
&lt; ftp and untar binutils-2.9.1 &gt;
&lt; ftp and untar gcc-2.95.2 &gt;
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
</pre>
Once done, ACE and TAO will successfully build and link.<p>
</p></li><li><b><a name="LynxOS">LynxOS</a></b><p>
ACE builds and runs properly on LynxOS 4.0 for Intel
and PowerPC targets. LynxOS 2.x and 3.x are no longer supported.
If you run out of memory on LynxOS, these might help:</p><p>
</p><ul>
<li>Increase the limits in <code>/etc/starttab</code>,
then reboot system. We use these limits:
<pre># Data, stack, and core file limits (in Kbytes)
80000
16000
102400</pre><p>
</p></li><li>Enable or expand virtual memory, with something like:
<pre># mkcontig /swap 320
# prio 17 vmstart /swap</pre>
See the <code>mkcontig</code> and <code>vmstart</code>
man pages, and <code>/bin/rc</code>.<p>
</p></li></ul>
Please see the comments in the
<a href="include/makeinclude/platform_lynxos.GNU">ACE
platform_lynxos.GNU file</a> for information on, and an
example of, tailoring for your particular platform.<p>
NOTE: if you want to use IP multicast on LynxOS, be sure to add
this line to your <code>/net/rc.network</code>, and reboot:</p><p>
</p><pre><code>
/bin/route add "224.0.0.0" "$my_name"
</code></pre>
</li><li><strong>VxWorks</strong><p>
<a href="http://www.cs.wustl.edu/%7Elevine/">David Levine</a>
&lt;<a href="mailto:levine@cs.wustl.edu">levine@cs.wustl.edu</a>&gt; has
ported ACE to VxWorks 5.2/5.3/5.3.1/5.4 with the GreenHills
1.8.8/1.8.9, g++ and diab compilers that are distributed with
VxWorks/Tornado. It is not possible to use VxWorks 5.4
and earlier with ACE anymore because the compilers delivered with
5.4 and earlier don't support the C++ features ACE needs.</p><p>
At this moment <a href="http://www.theaceorb.nl">Remedy IT</a> is upgrading
and stabilizing ACE/TAO support for Tornado 2.2/VxWorks 5.5.1.
Since the existing support for previous VxWorks version has been unsupported
and broken for some time and most (potential) users seem to have upgraded to
VxWorks 5.5.1 no backporting effort is done. See also <a href="#vxworks">here</a>.
</p><p>
Tornado 2.2/VxWorks 5.5.1 support IP multicast. That is not enabled
by default in ACE for VxWorks, because it depends on your
kernel configuration. To enable it, add
<code>#define ACE_HAS_IP_MULTICAST</code> to your
<code>ace/config.h</code>.</p><p>
NOTE: In order for the ACE Broadcast and Multicast tests to work the VxWorks kernel
should receive the packages it sends out locally. By default this is not supported.
To enable this behaviour you need to include the IFF_SIMPLEX flag for your required
NIC driver. See the following Windriver <a href="https://secure.windriver.com/cgi-bin/windsurf/techtips/public/viewSum.cgi?4542">SPR 4542</a>
for more information.</p><p>
In addition to all of the other benefits of ACE, it helps work
around some deficiencies with VxWorks. The problems are:</p>
<p>
</p><ol>
<li>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.<p>
</p></li><li>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 <a href="#spa">below</a>
for details.<p>
</p></li></ol>
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_NS_Thread.inl, so it
can easily be changed to one of the other spare fields, if
necessary.</p><p>
ACE destroys 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 <code>cplusDtors</code> and
then <code>cplusCtors</code> between runs.</p><p>
</p></li><li><b>MVS OpenEdition</b> <p>
All of ACE has been ported to OpenEdition by Chuck Gehr &lt;<a href="mailto:gehr@sweng.stortek.com">gehr@sweng.stortek.com</a>&gt;.
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:</p><p>
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.</p><p>
Some of the tests do not execute properly. This is a minority
and over time the goal is to get to 100%.</p><p>
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 <a href="#mvs">additional
build tips for MVS</a> for more on this.</p><p>
</p></li><li><strong>QNX Neutrino</strong><p>
ACE has been ported to <a href="http://www.qnx.com/products/os/neutrino.html">QNX Neutrino
2.0</a>. We cross-compile for Neutrino on a QNX4 host using g++
2.8.1, using the <a href="ace/config-qnx-neutrino.h">ace/config-qnx-neutrino.h</a>
and <a href="include/makeinclude/platform_qnx_neutrino.GNU">include/makeinclude/platform_qnx_neutrino.GNU</a>
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.</p><p>
</p></li><li><strong>QNX RTP</strong><p>
ACE has been ported to <a href="http://get.qnx.com/">QNX RTP
</a>. We compile for QNX RTP using the GCC compiler shipped with the
distribution, using the <a href="ace/config-qnx-rtp.h">ace/config-qnx-rtp.h</a>
and <a href="include/makeinclude/platform_qnx_rtp_gcc.GNU">include/makeinclude/platform_qnx_rtp_gcc.GNU</a>
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.</p><p>
<strong><blink><font color="#ff0000">WARNING:</font></blink></strong>
Under the current version of QNX RTP ACE fails if compiled with
inline=0 . </p><p>
</p></li><li><strong><a name="rtems">RTEMS</a></strong><p>
The support for RTEMS has been reviVed from version x.5.4. This version
was the first version that build again out of the box on RTEMS. Compilation
and testing was done for RTEMS with and without networking support. The
ACE GNU makefiles do automatically detect whether networking support
is available or not.
Besides the standard config.h/platform_macros.GNU file you will need
to set <code>RTEMS_MAKEFILE_PATH</code> to point to the location
of your RTEMS installation, see below for an example.</p>
<p><code>export RTEMS_MAKEFILE_PATH=/opt/rtems/CPU-rtems/BSP</code></p>
<p>
When building without network support you will need the ace_for_tao
subsetting functionality enabled. For this add <code>ace_for_tao = 1</code>
to your <code>bin/MakeProjectCreator/config</code> file and regenerate the
GNU makefiles as described <a href="#power">here</a>.</p><p>
</p></li><li><strong>PharLap ETS</strong><p>
ACE has been ported to Ardence's
<a href="http://www.ardence.com/embedded/products.aspx?ID=71">PharLap ETS</a>
version 13. The port was originally done for Pharlap 9.1 and MSVC 6,
but has been updated to Pharlap ETS 13 with Visual Studio .NET 2003
(VC7.1).</p><p> To build for PharLap, you'll need to use MPC to
generate .sln/.vcproj files with the ETS configurations. For example:
<pre>
cd \ace\ACE_wrappers
perl bin/mwc.pl -type vc71 -relative ACE_ROOT=C:/ace/ACE_wrappers -relative TAO_ROOT=C:/ace/ACE_wrappers/TAO -value_template configurations='"ETS Debug"' -value_template configurations+='"ETS Release"' -name_modifier *_ETS TAO_ACE.mwc
</pre>
That command will generate the same .sln and .vproj files as for
regular Windows builds with VC7.1, but they'll have names with an
<code>_ETS</code> suffix and will include the "ETS Debug" and
"ETS Release" configurations.</p><p>
After generating the needed VC7.1 files, use the ace/config-pharlap.h
configuration file, and the instructions
for building on Windows. Building the ACE library is the same as
for regular Windows platforms, except you choose one of the PharLap
ETS configurations to build within Visual Studio.
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.
</p><p>
When executing programs on the target system, it is possible that not
all of the VC++ support DLLs are resident on the target. In particular,
the debug-supporting DLLs may not be present. If you require these, be
sure to add those needed. For example, on the standard LabVIEW RT 8.2
distribution using Pharlap ETS, the following DLLs must be copied to
the target before being able to run Debug programs:
<ul>
<li>msvcp71d.dll</li>
<li>msvcr71d.dll</li>
</ul>
</p><p>
<note>To build ACE for National Instruments' LabVIEW RT, use
the Pharlap ETS information above, but add the following line to your
config.h file:
<pre>
#define ACE_PHARLAP_LABVIEW_RT
</pre>
This setting makes the necessary adjustments for LabVIEW's implementation
of Pharlap ETS.</note>
<note>By default, the ACE tests log their output/results to the
system console on Pharlap ETS. To change this behavior and make the
test output log to a file in the <code>log</code> directory under the
current working directory while executing, add the following line to
your config.h file:
<pre>
#define ACE_PHARLAP_TESTLOG_TO_FILE
</pre>
This setting has no affect on TAO tests which always write test output
to stdout.
</note>
</p></li><li><strong>Mac OS X (10.2.x)</strong><p>
</p><p>ACE builds and runs on Mac OS X 10.2.x, but the following are
needed to build it:</p>
<p>1. The latest version of the Apple Developer Tools
(December 2002)</p>
<p>2. The dlcompat library (obtained either through Fink or
SourceForge)</p>
<p>When creating $ACE_ROOT/ace/config.h for Mac OS X, you need
to add the following if you obtained dlcompat via Fink:</p>
<p>#define ACE_NEEDS_DL_UNDERSCORE</p>
<p>You'll also need to do:</p>
<p>setenv DYLD_LIBRARY_PATH $ACE_ROOT/ace:$ACE_ROOT/lib</p>
<p>setenv MACOSX_DEPLOYMENT_TARGET 10.2</p>
<p>Currently, all ACE tests pass except Process_Mutex_Test and
MEM_Stream_Test. Also, Mac OS X doesn't yet support *nix
aio_* calls, and ACE does not know anything about Mach.</p>
<p>The work to port ACE to Mac OS X was done by several people,
John Zorko
&lt;<a href="mailto:j.zorko@att.net">j.zorko@att.net</a>&gt; is
only one of them.</p>
</p></li><li><strong>iPhone/iPod Touch/iPad</strong><p>
</p><p>ACE builds and runs on the iPhone/iPod Touch/iPad Hardware
and Simulator. Keep in mind that ACE/TAO needs to be built
statically since Apple does not allow third party dynamic libraries
to be deployed on the hardware. The following are needed to build ACE:</p>
<p>1. The iPhone SDK.</p>
<p>2. When creating $ACE_ROOT/ace/config.h, include
config-macosx-iphone-hardware.h if you want to deploy on the
hardware, include config-macosx-iphone-simulator.h if you want
to deploy on the simulator. Even though those includes are named
after the iPhone, the includes work for iPhone/iPod Touch, and iPad.</p>
<p>3. You need to define two environment variables. The first is
IPHONE_TARGET. Set IPHONE_TARGET to SIMULATOR if you want to deploy
on SIMULATOR. Set IPHONE_TARGET to HARDWARE if you want to deploy on
the hardware device.</p>
<p>4. When creating $ACE_ROOT/include/makeinclude/platform_macros.GNU,
include 'include $(ACE_ROOT)/include/makeinclude/platform_macosx_iphone.GNU'
in the file.</p>
</li></ul>
<hr>
<h2><a name="g++">Compiling ACE with GNU g++</a></h2>
If you use the GNU GCC g++ compiler please note the following:
<ul>
</p></li><li>ACE/TAO needs g++ 2.95.x or better. Older versions are not usable anymore<p>
</p></li><li>Make sure to update your gcc <code>config.status</code>
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 <code>/usr/ccs/bin</code>
binary utils or GNU binary utils. The
<code>config.status</code> file is an output of the gcc
<code>configure</code> script; it is preferable to use the
<code>--prefix</code> option to <code>configure</code> instead
of hacking its output.<p>
</p></li><li>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.<p>
NOTE: if you do use the GNU linker, you might need to change
the <code>-G</code> flag to <code>-shared</code> in
the <code>SOFLAGS</code> definition in your
<code>include/makeinclude/platform_macros.GNU</code>.</p><p>
</p></li><li>Don't get too confused about contradictory statements in
the gcc documentation. It was written by different
people...<p>
</p></li><li>Make sure that the linker invoked by gcc produces code
that initializes static objects. Please see gcc's
documentation for using <code>collect2</code>.<p>
</p></li></ul>
<hr><p>
</p><h2><a name="minimum_build">What Do I Need to Build for TAO?</a></h2>
Toshio Hori &lt;toshi@etl.go.jp&gt; provided these suggestions on building
just what's needed for (a subset of) TAO:<p>
I usually make:
</p><pre> $ACE_ROOT/ace,
$ACE_ROOT/apps/gperf,
$TAO_ROOT/tao,
$TAO_ROOT/TAO_IDL, and
$TAO_ROOT/orbsvcs/orbsvcs
</pre>
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
<pre> TAO_ORBSVCS = Naming Time Trader ImplRepo
</pre>
in <code>$ACE_ROOT/include/makeinclude/platform_macros.GNU</code> also. See
<a href="TAO/docs/configurations.html#orbsvcs">TAO's orbsvcs
library customization instructions</a> for more information.<p>
</p><hr><p> </p><h2><a name="resource_requirements">System Resource
Requirements</a></h2> The amount of system resources required to build
ACE and TAO varies greatly. The required system resources are
influenced by OS and compiler platform, build options, and component
configurations. As a rough guide, the typical peak memory requirement
can be well over 512 MB (notably, for TAO's orbsvcs). Depending on
your OS and compiler configuration, an <strong>entire</strong> build
of ACE and TAO can use well over 4 GB of disk space. It's usually not
necessary to build <strong>all</strong> of ACE and TAO, though.<p>
Much less disk space is required for just the libraries. For example,
see the <a href="docs/ACE-subsets.html#ACE%20Library%20Size%20Breakdown">ACE
library subset sizes</a>.</p><p>
If you run out of memory when building, you might consider trying
some or all of these suggestions:</p><p>
</p><ul>
<li>Enable or increase virtual memory. If you're on a <a href="#Linux">Linux</a> or <a href="#LynxOS">LynxOS</a> platform,
please see the appropriate sections above.<p>
</p></li><li>Disable/enable optimization and/or debugging. See the
<a href="#flags">Makefile Flags</a> discussion for information
on how to do that via ACE's Makefiles.<p>
</p></li><li>If you're using g++, try removing <code>-pipe</code> from
<code>CFLAGS</code> in your
<code>include/makeinclude/platform_macros.GNU</code> file.<p>
</p></li><li>Restrict the components that you build. For ACE and TAO, see the
discussion of <code>ACE_COMPONENTS</code> in the
<a href="docs/ACE-subsets.html">ACE subsets</a> page. For TAO's
orbsvcs, see the discussion of <code>TAO_ORBSVCS</code> in
<a href="TAO/docs/configurations.html#orbsvcs">orbsvcs Library configuration information</a>.<p>
If disk space is a problem, disabling debugging should greatly
reduce object code, and therefore, library size. This is especially
true with g++.</p><p>
Toshio Hori &lt;toshi@etl.go.jp&gt; provided these tips for reducing
disk space usage:</p><p>
To save space on a Unix machine, I usually run
'find . -name \*.sln -o -name \*.vcproj -o -name \*.bmak | xargs rm -f'
in $ACE_ROOT at first after I untar the distribution. They are
meaningless in my environment (Files named '*.sln' and '*.vcproj' are
used for MSVC++ and files named '*.bmak' are for CodeGear C++
Builder.)</p><p>
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'.</p><p>
</p></li></ul>
<p></p><hr><p>
</p><h1><a name="MPC">General MPC information</a></h1>
The <A HREF="
http://downloads.ociweb.com/MPC/docs/html/MakeProjectCreator.html</A>
Makefile Project Creator (MPC)</A> is a tool that takes platform and
building tool generic files (mpc files) as input, which describe basic
information needed to generate a "project" file for various build
tools, including Make, NMake, Visual C++ 6, Visual C++ 7, etc. Please
see <a href="MPC/docs/USAGE">USAGE</a>, <a
href="MPC/docs/README">README</a> for documentation on MPC.<P>
A common usage for creating a Windows workspace containing just the
core ACE and TAO libraries and executables is the following:
<pre><code>
C:> cd %TAO_ROOT%
C:> %ACE_ROOT%\bin\mwc.pl -type vc71 TAO_ACE.mwc
</pre></code>
Replace vc71 with whatever project type you want to use. On Linux and
other UNIX platform use the gnuace type: <P>
<pre><code>
% cd $TAO_ROOT
% $ACE_ROOT/bin/mwc.pl -type gnuace TAO_ACE.mwc
</pre></code>
this creates the appropriate GNUmakefiles. Additional information on
how to obtain, configuration, and build ACE+TAO using MPC appear at
the OCI <A
HREF="http://www.theaceorb.com/faq/index.html#HowToBuildACEandTAOonWindows">FAQ</A>.<P>
If you are attempting to generate project files using MPC, and you get
the following error message:<br>
<pre>ERROR: Unable to find the MPC modules in /builds/ACE_wrappers/MPC.
You can set the MPC_ROOT environment variable to the location of MPC.
</pre>
You need to do one of the following:
<ol>
<li>If you have already obtained MPC, either move it underneath the
ACE_wrappers directory or set your MPC_ROOT environment variable to point
to the full path of MPC.</li>
<li>Check out MPC from the DOC Group subversion repository
and set your MPC_ROOT environment variable.</li>
</ol>
You can check
out MPC from the doc_group subversion server using the following command.
<pre>svn co svn://svn.dre.vanderbilt.edu/DOC/MPC/trunk MPC
</pre>
The <A HREF="MPC/docs/README">README</A> and <A HREF="MPC/docs/USAGE">USAGE</A> files in the MPC/docs directory are an up-to-date
source of documentation, however it is not a complete set of
documentation. The TAO Developer's Guide from OCI starting with the
1.3a version contains more information about MPC.<p>
The MPC chapter from the TAO Developer's Guide is available at <a
href="http://downloads.ociweb.com/MPC/">
http://downloads.ociweb.com/MPC/</a>. Some of MPC has changed since
this version, but it is largely accurate. An updated version will be
available as newer versions of the TAO Developer's Guide are released.
In the meantime, please see the README and USAGE files in the MPC
directory.
</p>
<p>
</p><h1><a name="eclipse">Working with ACE in Eclipse</a></h1>
<p>
The Eclipse CDT C++ development environment can be used to develop ACE applications. You can configure a new CDT project to build ACE using either a local source distribution or checking out ACE from CVS in Eclipse. These are the steps to create the CDT project to build ACE.
</p>
<p>
<h2>To create an Eclipse project for ACE starting from CVS:</h2>
<ol>
<li>In the "CVS Repository Exploring" perspective, navigate to the module containing ACE.</li>
<li>Checkout the module using "Check Out As" and select the "project configured using the New Project Wizard" option.</li>
<li>Select "Standard Make C++ Project" for the project type.</li>
<li>Follow the steps outlined above, up to the point of running make, for building ACE on your platform. Use "path_to_your_eclipse_workspace"/"project_name" as your $ACE_ROOT.
<li>If you had to regenerate the makefiles using MPC, select the root folder for your poject and use the import wizard to add them to your project.</li>
<li>Select the root folder for the project and use the "Create Make Target" wizard to setup the appropriate make command and options.</li>
<li>Select the root folder and run "Build Make Target." This will build ACE.</li>
</ol>
</p>
<p>
<h2>To create an Eclipse project for ACE from a local source distribution:</h2>
<ol>
<li>Launch the "New Project Wizard" in Eclipse.</li>
<li>Select "Standard Make C++ Project" for the project type.</li>
<li>On the project name page, uncheck the "use default" location option and replace the default path with the path to your source distribution.</li>
<li>Follow the steps, up to the point of running make, for building ACE on your platform.
<li>If you had to regenerate the makefiles using MPC, select the root folder for your poject and use the import wizard to add them to your project.</li>
<li>Select the root folder for the project and use the "Create Make Target" wizard to setup the appropriate make command and options.</li>
<li>Select the root folder and run "Build Make Target." This will build ACE.</li>
</ol>
</p>
</p>
<hr><p>
</p><h1><a name="advanced">Advanced Topics</a></h1>
<ul>
<li><a href="docs/ACE-porting.html">Porting ACE and TAO to a New OS Platform</a>
</li><li><a href="#NonStaticObjectManager">Non-static ACE_Object_Manager</a>
</li><li><a href="#cloning">Cloning the Source Tree</a>
</li><li><a href="#mvs">Additional Build Tips for MVS</a>
</li><li><a href="#flags">Makefile Flags</a>
</li><li><a href="http://www.cs.wustl.edu/%7Elevine/CVS.html">Version Control</a>
</li><li><a href="docs/ACE-SSL.html">ACE SSL effort</a>
</li></ul>
<p></p><hr align="left" width="50%"><p>
</p><h2><a name="NonStaticObjectManager">Non-static
ACE_Object_Manager</a></h2> 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 <code>ACE::init ()</code> and <code>ACE::fini
()</code>. The comments in the header file,
<a href="ace/Object_Manager.h"><code>ace/Object_Manager.h</code></a>, as well as Section 1.6.3 in
<a href="http://www.riverace.com/docs">The ACE Programmer's Guide</a>
provide more detail.<p>
<strong><blink><font color="#ff0000">NOTE:</font></blink></strong>
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
<code>ACE_HAS_NONSTATIC_OBJECT_MANAGER</code> in
<code>ace/config.h</code>. Again, see the ACE Object_Manager header file,
<a href="ace/Object_Manager.h"><code>ace/Object_Manager.h</code></a> for more information. One of
these requirements is discussed here, because it is so important.
Please note that <code>ACE_HAS_NONSTATIC_OBJECT_MANAGER</code> is
defined in the distributed ACE <code>config.h</code> headers for
VxWorks and Win32.</p><p>
The important requirement is that the program <strong>must</strong>
declare its <code>main</code> function with two arguments, even if
they're not used, and with <code>int</code> return type:
</p><pre><code>
int
main (int, char *[])
</code></pre>
If you don't declare <code>main</code> <strong>exactly</strong> that
way, then you'll see a link error about <code>ace_main_i</code> being
undefined.<p>
Alternatively, this feature can be disabled by commenting out the
#define ACE_HAS_NONSTATIC_OBJECT_MANAGER in the
<code>ace/config.h</code>. 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.</p><p>
<strong><blink><font color="#ff0000">WARNING:</font></blink></strong>
<code>ACE_HAS_NONSTATIC_OBJECT_MANAGER</code> assumes that your
<code>main</code> function is named <code>main</code>. Any violation
of this assumption is at your peril. If you really need to call your
entry point something other than <code>main</code>, you'll need to
construct and destroy the ACE_Object_Manager. The best way to do that
is to call <code>ACE::init ()</code> and <code>ACE::fini ()</code>.
Or, see the <code>#define</code> of <code>main (int, char *[])</code>
in <a href="ace/OS_main.h"><code>ace/OS_main.h</code></a> to see how ACE does
that for entry points named <code>main</code>.
</p><p></p><hr align="left" width="50%"><p>
</p><h2><a name="cloning">Cloning the Source Tree</a></h2>
On UNIX platforms, we typically like to support multiple platform
builds using the same ACE source tree. This idiom is supported by ACE
using the $ACE_ROOT/bin/create_ace_build.pl script.
To clone the source tree, create ./build and ./build/{your build name}
subdirectories under the ACE_wrappers directory.
Then invoke the create_ace_build.pl script to clone the source tree using
soft links from your build directory back to the actual sources.
Here is an example:</p><p>
</p><pre>% cd ACE_wrappers
% mkdir build build/build-SunOS5
% perl bin/create_ace_build.pl -a -v build-SunOS5
% cd build/build-SunOS5
% setenv ACE_ROOT $cwd
% make
</pre><p>
This will establish a complete tree of links. In addition, make sure
you set your <code>LD_LIBRARY_PATH</code> to
<code>$ACE_ROOT/lib:$LD_LIBRARY_PATH</code> on SVR4 UNIX
platforms.</p><p>
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.</p><p>
See the comments at the top of the create_ace_build.pl script for
further usage information.
</p><p></p><hr align="left" width="50%"><p>
</p><h2><a name="mvs">Additional Build Tips for MVS</a></h2>
For all intents and purpose, MVS OpenEdition (OE) is another flavor of
UNIX, therefore, the instructions under <a href="#aceinstall">Building
and Installing ACE on Unix</a> can be used along with the following
additional tips:<p>
You can get a copy of GNU make that has been ported to MVS OpenEdition from
the <a href="http://www.s390.ibm.com/products/oe/index.html">IBM OpenEdition web site</a>.
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.</p><p>
Note that the environment variable <code>LD_LIBRARY_PATH</code> is
called <code>LIBPATH</code> on MVS.</p><p>
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.</p><p>
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.
</p><p></p><hr align="left" width="50%"><p>
</p><h2><a name="flags">Makefile Flags</a></h2>
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:<p>
</p><pre><code>
% make -j <em>n</em>
</code></pre><p>
which allows parallel compilation. The number <i>n</i> should
typically be the number of CPUs. It is likely that builds will be
faster even on single-CPU UNIX machines with <code>make -j
2</code>.</p><p>
ACE further supports the following flags. They can be enabled either
on the command line, e.g., "make purify=1", or added to your
<code>platform_macros.GNU</code>. 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.</p><p>
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.</p><p>
If you use Purify or Quantify: purify or quantify <strong>must</strong>
be on your <code>PATH</code>. By default, ACE puts the Purify/Quantify
caches below <code>/tmp</code>. To override that, set the
<code>PURE_CACHE_BASE_DIR</code> variable, either in your environment
or on the <code>make</code> make command line, to the destination
directory for your instrumented libraries.</p><p>
</p><pre>Flag Description
---- -----------
debug Enable debugging; see DCFLAGS and DCCFLAGS.
exceptions Enable exception handling (not supported by all platforms).
include_env Support old-style ACE_TRY_ENV declarations in methods.
This switch is necessary for compiling TAO applications
in the native exception configuration that were written
for TAO versions before 1.2.2.
In TAO 1.2.2, new macros were introduced that supercede
the direct ACE_TRY_ENV declarations. These are the
ACE_ENV_ARG macros that are defined in ace/CORBA_macros.h
and are documented in docs/exceptions.html.
This switch only affects the exceptions=1 configuration.
It is for backward compatibility only.
There will be warnings about unused _ACE_environment_variable
parameters when using include_env=1.
If possible, do not use it, but instead change your TAO
applications to use the ACE_ENV_ARG macros.
fast Enable -fast option, e.g., with Sun C++.
inline Enable ACE inlining. Some platforms enable inlining by
default, others do not.
optimize Enable optimization; see OCFLAGS and OCCFLAGS.
pace Enable PACE as the underpinnings of ACE_OS.
probe Enable ACE_Timeprobes.
profile Enable profiling; see PCFLAGS and PCCFLAGS.
purify Purify all executables.
quantify Quantify all executables.
repo Use GNU template repository (g++ with repo patches only).
rtti Enable run-time type identification. On some platforms,
it is enabled by default, so this is ignored.
shared_libs 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 Build with Xt (X11 Toolkit) support.
fl Build with FlTk (Fast Light Toolkit) support.
tk Build with Tk (Tcl/Tk) support.
qt Build with Qt (Trolltech Qt) support.
ssl Build with OpenSSL support.
rapi Build with RAPI
split Build the library by first splitting up the ACE source
to several files, with one object code entity for each
source file. This allows an application that is linked
with ACE to extract _exactly_ what it needs from the
library, resulting in a smaller executable. Setting this
to 1 overrides debug to 0.
Usually, users do not need to be concerned with make targets.
Just enter "make" on the command line to build. A few notable
targets are listed below.
Target Description
------ -----------
show_statics Lists all static objects in object files built for
current directory. Only supported for g++.
show_uninit Lists all uninitialized in object files built for
current directory. Only supported for g++.
</pre>
</p><hr><p>
</p><h2><a name="power">Building from Subversion (anonymous access)</a></h2>
If users are building from our <a href="https://svn.dre.vanderbilt.edu/viewvc/Middleware/trunk/">Subversion repository</a> the
GNUmakefiles, and project files for building on various platforms will
not be available. Subversion users are expected to <a href="#generate_using_mpc">generate them</a>
using <a href="https://svn.dre.vanderbilt.edu/viewvc/MPC/trunk/docs/README?revision=HEAD">MPC</a> before building ACE, TAO or
CIAO. We point out some suggestions below to get bootstrapped
quickly.
<ul>
<li>You can checkout different subsets from the Subversion repository.
<ul>
<li>To checkout ACE with MPC:<p>
<code>svn co svn://svn.dre.vanderbilt.edu/DOC/Middleware/sets-anon/ACE .</code>
</li>
<li>To checkout ACE+TAO with MPC:<p>
<code>svn co svn://svn.dre.vanderbilt.edu/DOC/Middleware/sets-anon/ACE+TAO .</code>
</li>
<li>To checkout ACE+TAO+CIAO with MPC:<p>
<code>svn co svn://svn.dre.vanderbilt.edu/DOC/Middleware/sets-anon/ACE+TAO+CIAO .</code>
</li>
</ul>
</p></li><li>Please make sure that you have <a href="http://www.perl.org/">
perl</a> installed, preferably perl
5.8 or higher. Users on Win32 based platforms are recommended to use
<a href="http://www.activestate.com/Products/ActivePerl/"> Active
State Perl</a>. We use active state perl without problems. We have
ran into problems trying to use the cygwin version of perl on Win32
based platforms. <p>
</p></li>
<a name="generate_using_mpc"></a>
<li>To build ACE and associated tests, examples,
and associated utility libraries with GNUmakefiles, you must
generate GNUmakefiles with MPC:<p>
<code> $ACE_ROOT/bin/mwc.pl -type gnuace ACE.mwc</code> </p>
<p>On Windows, with Visual C++ 8, you must generate solution and project files with MPC:<p>
<code> $ACE_ROOT/bin/mwc.pl -type vc8 ACE.mwc </code> </p><p>
On Windows, with Visual C++ 7, you must generate solution and project files with MPC:<p>
<code> $ACE_ROOT/bin/mwc.pl -type vc71 ACE.mwc </code> </p>
</li><li>If you want to build TAO+CIAO and its associated libraries
please see <a href="TAO/TAO-INSTALL.html">TAO-INSTALL</a><a> and
</a><a href="TAO/CIAO/CIAO-INSTALL.html">CIAO-INSTALL</a> for details.
</li></ul>
<hr><p>
Back to the <a href="http://www.cs.wustl.edu/%7Eschmidt/ACE.html">ACE</a>
home page.
</p><p>
<!--<EM>
Visitor #
from
<EM><br> -->
<!-- hhmts start -->
Last modified: Wed Jul 5 17:26:22 EST 2006
<!-- hhmts end -->
</p></body></html>
Reference in a new issue View git blame Copy permalink