diff --git a/deps/acelite/ACE-INSTALL.html b/deps/acelite/ACE-INSTALL.html
new file mode 100644
index 000000000..c05056712
--- /dev/null
+++ b/deps/acelite/ACE-INSTALL.html
@@ -0,0 +1,3231 @@
+
+
+ Building and Installing ACE and Its Auxiliary Libraries and Services
+
+
+
+
+
+
+
+
+
+
Building and Installing ACE and Its Auxiliary Libraries and Services
+
+
Synopsis
+
+The file explains how to build and install ACE, its Network Services,
+test suite and examples on the various OS platforms and compilers that
+it has been ported to. Please consult the NEWS and
+ChangeLogs files to see whether any recent changes
+to the release will affect your code. In addition, you should check
+out our development
+process. As you start working with ACE, we suggest you get copies
+of the C++NPv1, C++NPv2, and
+APG books to help
+guide you after you've built and installed ACE. You should also
+consult the ACE
+Frequently Made Mistakes page. If you encounter any problems or
+would like to request an enhancement, then use github
+ to submit an issue in accordance with our bug
+report process.
ACE has been ported to a large number of platforms using many different
+compilers over the years.
+The DOC group,
+Riverace,
+OCI,
+Remedy IT, and members of the ACE
+user community have all contributed ports to make ACE the successful
+and far-reaching toolkit it is today. Any UNIX/POSIX/Windows
+variation is probably an easy target platform for ACE. If you have
+porting questions or have a problem
+compiling the ACE source distribution, please contact one of the
+commercial support companies, or send a copy of the
+PROBLEM-REPORT-FORM, located in the
+ACE_wrappers directory to ace-users
+mailing list or create a github issue.
+The DOC groups at Washington University, UC Irvine, and Vanderbilt
+University provide only "best effort" support for non-sponsors for the
+latest release, as described in
+docs/ACE-bug-process.html.
+Thus, if you need more "predictable" help, or help with earlier versions of
+ACE, it's recommend that you check out the
+list of
+commercial support companies for additional assistance.
+
+
The responsibility for maintaining ACE across the wide range of
+supported platforms is divided among a few different groups:
+
+
The DOC group maintains platforms used in the course of their research
+and sponsored work
+
Companies that provide support (Riverace, OCI, and Remedy IT), maintain
+platforms they support in the course of their various service offerings
+
The ACE user community maintains any other desired platforms.
+
+The
+build scoreboard
+records the current status of build and regression testing during
+development by all of the above groups. It is available to all users wishing
+to provide build results. Members of the ACE community that maintain ACE on
+platforms not maintained by the DOC group, Riverace, OCI, or Remedy IT are
+encouraged to provide build and regression test results for the scoreboard
+to ensure that all in-use platforms are represented.
+See the autobuild README for more information about
+how to set up a build; contact one of the above groups to inquire about how
+to get your build results recorded on the scoreboard.
+
Because older
+platforms that are not maintained tend to fall into a broken state and
+clutter the ACE sources with code that is no longer used, the development
+team reserves the right to remove ACE configuration files and source code
+specific to inactive platform configurations that are not
+listed on the scoreboard.
+
The table below summarizes each group's role and where you can get more
+detailed information. For information on TAO's platform coverage and
+support, please also see TAO's install
+document.
Maintains ACE on many platforms required for their ACE and
+ TAO service offerings. We support AIX,
+ Embarcadero C++ Builder,
+ Windows CE, MinGW, Microsoft Visual C++, GCC,
+ Cygwin, VxWorks 6.x (kernel and rtp), OpenVMS on IA64,
+ BlueCAT Linux, RedHat Linux, Fedora, MacOSX, Solaris,
+ Tru64, SuSE Linux on Alpha/IA32/EM64T/IA64, RTEMS, QNX, LynxOS,
+ HPUX on IA64, and Android.
+ The Intel C++ compiler is supported on
+ Windows 32/64bit, Linux IA32/EM64T/IA64, MacOSX.
+
Responsible for continued maintenance and testing of platforms
+ to which ACE has been ported, but aren't supported by the
+ above groups. These include
+ Digital UNIX (Compaq Tru64) 4.0 and 5.0;
+ IRIX 6.x; UnixWare 7.1.0;
+ Linux on PPC; OpenMVS;
+ Tandem; SCO; FreeBSD; NetBSD; OpenBSD;
+ Macintosh OS X; OS/9; PharLap ETS 13;
+ QNX RTP and Neutrino 2.0; Interix (Windows Services for Unix)
+
+
+
Not maintained
+
The following platforms have been ported to in the past but are
+ no longer maintained and may be removed from ACE at any time.
+ If you want to have support for these environments contact one
+ of the commercial support organisations. The platforms include:
+ Chorus; DG/UX; HP-UX 9, 10 and 11.00; pSOS;
+ SunOS 4.x and Solaris with SunC++ 4.x; VxWorks 5.4 and earlier;
+ Microsoft Visual C++ 5, 6, and 7.0; Borland C++ Builder 4, 5, 6, and 2006.
+ For up-to-date listings on platform that are deprecated and pending
+ removal from ACE, please see the NEWS file.
+
+
+
+
+
Although the DOC group has provided outstanding support for ACE
+over the years, ACE's success has greatly increased the amount of
+effort required to keep up with its maintenance, answer users'
+questions, and give design guidance. Riverace offers world-class
+commercial services to support ACE users. OCI, PrismTech, and Remedy
+offer similar services for ACE and TAO, allowing the DOC group's primary focus
+to shift back to their main goal: research. The DOC group is
+fundamentally focused on (and funded
+by) advanced R&D projects. The group continues to be
+intimately involved in ACE+TAO development and maintenance, but with
+revised priorities for maintenance. The bug
+fixing policies followed by the DOC group are designed to strike a
+balance between their many research
+projects and their commitment to the ACE+TAO user
+community. Naturally, we will be happy to accept well-tested
+patches from the ACE+TAO user community for any platforms that aren't
+supported by the DOC group, Riverace, OCI or Remedy IT.
ACE (as well as TAO and CIAO) use MPC
+(MakeProjectCreator) to generate files used by all supported build
+tools (such as GNUmakefiles for UNIX based platforms, sln and vcproj
+files for Visual Studio and Embarcadero makefiles) on various platforms. To
+help new users to bootstrap quickly the release bundles of ACE (as
+well as TAO) include all needed files to use the build
+instructions in this document.
+
+
+
+If it is necessary to generate
+files for build tools for other compilers, one must
+run MPC to generate the
+appropriate files. Please see USAGE, README, and README for ACE files for
+details. The options that have been used to generate the above build
+files can be found in
+global.features file.
+
Many features in ACE can be modified by defining some macros in
+ $ACE_ROOT/ace/config.h. These macros should
+ always appear before including
+ your platform specific config file.
+
However, if you want to undefine/redefine macros defined in the
+ platform specific config file, these #undef should
+ come after the config file.
+
If you're planning to build ACE on multiple platforms, you may
+ want to consider cloning the source tree
+ before you start.
+Here's what you need to do to build ACE using GNU Make and ACE's traditional
+per-platform configuration method:
+
+
+
Install GNU make
+ 3.79.1 or greater on your system (available via http
+ anonymous ftp from ftp.gnu.org in the
+ pub/gnu/make/ directory).
+ You must use GNU make when using ACE's traditional
+ per-platform configuration method or ACE won't compile.
+
+
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:
+
+ BASH or Bourne Shell:
+ export ACE_ROOT=/home/cs/faculty/schmidt/ACE_wrappers
+
+
+
+ If you're building a number of versions of ACE, however, (e.g., for
+ different OS platforms or for different releases of ACE) you might use
+ the following approach (assuming TCSH/CSH):
+
+ setenv ACE_ROOT $cwd
+
+
+
Create a configuration file, $ACE_ROOT/ace/config.h,
+ that includes the appropriate platform/compiler-specific
+ header configurations from the ACE source directory. For example:
+
+#include "ace/config-linux.h"
+
+ The platform/compiler-specific configuration file
+ contains the #defines that are used throughout ACE to indicate
+ which features your system supports. See the
+ $ACE_ROOT/ace/README file for a description of these
+ macro settings. If you desire to add some site-specific or build-specific
+ changes, you can add them to your config.h file; place them
+ before the inclusion of the platform-specific
+ header file.
+
+ There are config files for most versions of UNIX. If there
+ isn't a version of this file that matches your
+ platform/compiler, you'll need to make one. Please send email
+ to the ace-users list
+ if you get it working so it can be added to the master ACE
+ release.
+
+
+
Create a build configuration file,
+ $ACE_ROOT/include/makeinclude/platform_macros.GNU,
+ that contains the appropriate platform/compiler-specific
+ Makefile configurations, e.g.,
+
+ This file contains the compiler and Makefile directives that are
+ platform/compiler-specific. If you'd like to add make options, you
+ can add them before including the platform-specific configuration.
+ NOTE! There really is not a # character before 'include' in the
+ platform_macros.GNU file. # is a comment character.
+
+
If you wish to install ACE (using "make install"), set the
+ installation prefix in platform_macros.GNU.
+
+INSTALL_PREFIX = /usr/local
+
+ Headers will be installed to $INSTALL_PREFIX/include, executables to
+ $INSTALL_PREFIX/bin, documentation and build system files to
+ $INSTALL_PREFIX/share and libraries to $INSTALL_PREFIX/lib. The library
+ directory can be customized by setting INSTALL_LIB (for example,
+ INSTALL_LIB=lib64). With INSTALL_PREFIX set, RPATH will be enabled for
+ all executables and shared libraries. To disable RPATH (for example,
+ if $INSTALL_PREFIX/$INSTALL_LIB is already a system-known location for
+ shared libraries such as those listed in /etc/ld.so.conf), set the make
+ macro install_rpath to 0 by adding install_rpath=0 to platform_macros.GNU.
+
+
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:
+
When all this is done, hopefully all you'll need to do is type:
+
+ % make
+ at the ACE_ROOT directory. This will build the ACE
+ library, tests, the examples, and the sample applications.
+ Building the entire ACE release can take a long time and consume
+ lots of disk space, however. Therefore, you might consider
+ cd'ing into the $ACE_ROOT/ace directory and
+ running make there to build just the ACE library.
+ As a sanity check, you might also want to build and run the
+ automated "one-button" tests in
+ $ACE_ROOT/tests. Finally, if you're also
+ planning on building TAO, you
+ should build the gperf
+ perfect hash function generator application in
+ $ACE_ROOT/apps/gperf.
+
+
If you've set the INSTALL_PREFIX before building, now run
+
% make install
+
+
If you need to regenerate the ace/Svc_Conf_y.cpp file,
+ you'll need to
+ get GNU Bison.
+ However, you should rarely, if ever, need to do this.
+
This section contains instructions for building ACE on Microsoft
+Windows with a variety of compilers and development environments.
+
+
First, if you are upgrading from an older release, the recommended practice
+is to start with a clean directory. Unpacking the newer release over an older
+one will not clean up any old files, and trying to use the environment's
+"Clean" command will probably not account for all existing files.
ACE contains project files for
+Visual Studio 2015 (vc14), Visual Studio 2017 (vc141), and Visual Studio 2019 (vc142).
+Visual Studio 2015/2017/2019 use different file formats but the same file
+suffixes (.sln and .vcproj). To support both
+environments, ACE supplies files with different names for the different
+development and target platforms. The platform/name mapping is shown below.
+All solution files have a .sln suffix and all project files have
+a .vcproj suffix.
+
+
+
Mapping of Platform to Solution/Project File Name
+
+
+
Platform
+
File Name
+
+
+
+
Visual Studio 2015
+
name_vc14
+
+
+
+
Visual Studio 2017
+
name_vs2017
+
+
+
+
Visual Studio 2019
+
name_vs2019
+
+
+
+
+
The VC++ compiler and linker can now be invoked from GNU make just like
+most UNIX builds. Follow the instructions in the
+ACE/GNU Configuration sections and see the additional information in the
+comments of
+platform_win32_msvc.GNU.
+
+
+
If you happen to open an older file Visual Studio solution from a newer one, it will offer to convert
+the file to the newer format for you
+
+
+
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.
+
+
Create a file called config.h in the ACE_ROOT\ace
+ directory that contains:
+
+ #include "ace/config-win32.h"
+
+
+
The static, DLL and MFC library builds are kept in
+ different workspaces. Files with names *_Static contain project
+ files for static builds. Workspaces for static and DLL builds will be
+ available through the stock release at DOC group's website. The
+ workspaces for MFC are not available and have to be generated using
+ MPC. Please see MPC's README for
+ details.
+
Now load the solution file for ACE (ACE_ROOT/ACE.sln).
+
+
Make sure you are building the configuration (i.e, Debug/Release)
+ the one you'll use (for example, the debug tests need the debug
+ version of ACE, and so on). All these different configurations are
+ provided for your convenience. You can either adopt the scheme to
+ build your applications with different configurations, or use
+ ace/config.h to tweak with the default settings on
+ NT. Note: If you use the dynamic libraries,
+ make sure you include ACE_ROOT\lib in your PATH whenever you run
+ programs that uses ACE. Otherwise you may experience problems
+ finding ace.dll or aced.dll.
+
+
To use ACE with MFC libraries, also add the following to
+ your config.h file. Notice that if you want to
+ spawn a new thread with CWinThread, make sure you spawn the
+ thread with THR_USE_AFX flag set.
+
+ #define ACE_HAS_MFC 1
+
+ By default, all of the ACE projects use the DLL versions of the
+ MSVC run-time libraries. You can still choose use the static (LIB)
+ versions of ACE libraries regardless of run-time libraries. The
+ reason we chose to link only the dynamic run-time library is that
+ almost every NT box has these library installed and to save disk
+ space. If you prefer to link MFC as a static library into ACE, you
+ can do this by defining ACE_USES_STATIC_MFC in your
+ config.h file. However, if you would like to link
+ everything (including the MSVC run-time libraries) statically,
+ you'll need to modify the project files in ACE yourself.
+
Static version of ACE libraries are built with
+ ACE_AS_STATIC_LIBS defined. This macro should
+ also be used in application projects that link to static ACE
+ libraries
+
+ Optionally you can also add the line
+
+ #define ACE_NO_INLINE
+
+ before the #include statement in ACE_ROOT\ace\config.h to disable
+ inline function and reduce the size of static libraries (and your
+ executables.)
+
+
ACE DLL and LIB naming scheme:
+
+ We use the following rules to name the DLL and LIB files in ACE
+ when using MSVC.
+
+ "Library/DLL name" + (Is static library ? "s" :
+ "") + (Is Debugging enable ? "d" : "")
+ + {".dll"|".lib"}
+
+
+
+
More information for ACE/TAO on MSVC can be found
+here. The doxygen version of this
+document is available under Related Topics in the ACE Library.
+
+ACE TESTS
+
+The tests are located in ACE_ROOT\tests. There is also a solution in
+that directory to build all the tests (tests.sln)
+
+Once you build all the tests (Batch Build works well for this), you
+can run perl script run_test.pl in the
+tests directory to try all the tests.
+
+If you are building for a machine without a network card, you may want
+to check here first.
+
+
+
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 when you uncompressed into the
+ root directory.
+
+
Create a file called config.h in the ACE_ROOT\ace
+ directory that contains at least:
+
+ #include "ace/config-win32.h"
+
+
Open a RAD Studio Command Prompt.
+
+
Set the ACE_ROOT environment variable to point to the ACE_wrappers
+ directory. For example:
+
+ set ACE_ROOT=C:\ACE_wrappers
+
+
Add ACE_wrappers\lib and ACE_wrappers\bin to the PATH environment variable:
+
+ set PATH=%ACE_ROOT%\lib;%ACE_ROOT%\bin;%PATH%
+
+
Change to the ACE_ROOT\ace directory.
+
+ cd %ACE_ROOT%\ace
+
+
Generate the bmake makefiles using MPC. Use the bmake project type for C++ Builder:
+
+ %ACE_ROOT%\bin\mwc.pl -type bmake
+
+
You can build several different versions of ACE by setting the following optional environment
+ variables before you run make:
+
+ Set the environment variable below to build a debug version of ACE
+ set DEBUG=1
+
+ Set the environment variable below to build a unicode version of ACE
+ set UNICODE=1
+
+ Set the environment variable below to build a version of ACE with
+ Codeguard support. Should only be used when DEBUG is also set
+ set CODEGUARD=1
+
+ By default we are using the clang based compilers. At the moment you
+ want to compile using the old bcc32 compiler set the CLASIC environment variable
+ set CLASSIC=1
+
+ Set the environment variable below to build a version of ACE optimized
+ for a certain CPU. For this there are special compiler flags
+ (-3/-4/-5/-6), see the Embarcadero help for more info.
+ set CPU_FLAG=-6
+
+ You can then start the build with the command
+ make -f Makefile.bmak all
+
+ You may also enable the options by passing them as command line options to make, for example:
+ make -f Makefile.bmak -DDEBUG all
+
+
Build ACE by doing:
+
+ make -f Makefile.bmak all
+
+
+
+
+
+Note that when you run make in a sub directory you give make -f Makefile.bmak all. The all is needed to make sure the complete project is build.
+
+Before you can build the tests you need to build the protocols directory.
+Change the directory to ACE_ROOT\protocols and start:
+
+%ACE_ROOT%\bin\mwc.pl -type bmake
+make -f Makefile.bmak all
+
+
+The tests are located in ACE_ROOT\tests, change to this directory.
+You build then the tests with the following commands:
+
+%ACE_ROOT%\bin\mwc.pl -type bmake
+make -f Makefile.bmak all
+
+
+Once you build all the tests, you can run the automated test script using:
+
perl run_test.pl
in the
+tests directory to try all the tests. You need to make
+sure the ACE bin and lib directory (in this case
+%ACE_ROOT%\bin and %ACE_ROOT%\lib)
+are on the path before you try to run the tests. If your executables are
+compiled into a subdirectory, add -ExeSubDir subdirname to the
+command.
+If you are building for a machine without a network card, you may want
+to check here first.
+
+
+Building and installing ACE on MinGW
+uses a mix of a UNIX building process and
+Win32 configuration files.
+Also, as MinGW uses GNU g++, you may want to take
+a look at the Compiling ACE with GNU g++ section.
+
+
+You will need the MinGW build tools and libraries, downloable from
+http://www.mingw.org.
+
+
+For our build we require the packages
+MinGW and MSYS.
+
+
+
+
Install the MinGW tools (including the MinGW Development toolkit) into a common directory, say c:/mingw.
+
+
+
Install the MSYS tools into a common directory, say c:/msys.
+
+
+
Open a MSYS shell. Set your PATH environment variable so
+ your MinGW's bin directory is first:
+
+
% export PATH=/c/mingw/bin:$PATH
+
+
+
Add an ACE_ROOT environment variable pointing to the
+ root of your ACE wrappers source tree:
+
+
% export ACE_ROOT=/c/work/mingw/ACE_wrappers
+
+
+ From now on, we will refer to the root directory of the ACE
+ source tree as $ACE_ROOT.
+
+
+
Create a file called config.h in the
+ $ACE_ROOT/ace directory that contains:
+
+
#include "ace/config-win32.h"
+
+
+
Create a file called platform_macros.GNU in the
+ $ACE_ROOT/include/makeinclude directory containing:
+
+
include $(ACE_ROOT)/include/makeinclude/platform_mingw32.GNU
+
+
+ In the above text, don't replace $(ACE_ROOT) with the
+ actual directory, GNU make will take the value from the
+ environment variable you defined previously.
+
+
+ If you lack Winsock 2, add the line
+
+
winsock2 = 0
+
+
+ before the previous one.
+
+
+
+ If you want to install ACE (using "make install") and want all the .pc files generated,
+ set the installation prefix in platform_macros.GNU.
+
INSTALL_PREFIX=/c/ACE
+
+ Headers will be installed to $INSTALL_PREFIX/include, documentation and
+ build system files to $INSTALL_PREFIX/share and libraries to $INSTALL_PREFIX/lib. With INSTALL_PREFIX set, RPATH will be enabled.
+ To disable RPATH (for example, if $INSTALL_PREFIX/$INSTALL_LIB is already
+ a system-known location for shared libraries), set the make macro
+ install_rpath to 0 by adding install_rpath=0 to platform_macros.GNU.
+
+
+
+
In the MSYS shell, change to the $ACE_ROOT/ace directory and
+ run make:
+
+
% cd $ACE_ROOT/ace
+ % make
+
+
+
+ This should create libACE.dll (the Win32 shared library) and
+ libACE.dll.a (the Win32 import library for the DLL).
+ Note that the name for the ACE DLL follows the MinGW convention, which itself
+ resembles UNIX.
+
+
+ If you want static libs also, you may run:
+
+
% make static_libs_only=1
+
+
+
Run make install:
+
+
% make install
+
+
+ This should create ACE.pc to use with pkg-config.
+
+If you are building for a machine without a network card, you may want
+to check here first.
+
+
+Building and installing ACE on Cygwin
+uses the UNIX building process.
+Also, as Cygwin uses GNU g++, you may want to take
+a look at the Compiling ACE with GNU g++ section.
+
+
+You will need the Cygwin build tools and libraries, downloable from
+http://www.cygwin.com.
+For our build we require the following packages besides the packages the
+setup selects by default:
+
+
Open a Cygwin shell. Set your PATH environment variable so
+ your Cygwin bin directory is first:
+
+
% export PATH=//c/cygwin/bin:$PATH
+
+
+ or
+
+
% export PATH=/cygdrive/c/cygwin/bin:$PATH
+
+
+
+ Note Cygwin uses ``/'' as directory separator,
+ and ``//X'' as a notation for Win32 drive X.
+ Note also that you can't use ``c:/cygwin/bin''
+ because, for Cygwin,
+ ``:'' is path separator character, as in UNIX.
+
+
+
Add an ACE_ROOT environment variable pointing to the
+ root of your ACE wrappers source tree (in this example c:/work/cygwin/ACE_wrappers):
+
+
+ Note here you can't use the ``//X'' Cygwin
+ notation as this is seen by Cygwin's compiler and it doesn't
+ support that (it does support ``/'' as directory
+ separator however).
+
+
+ From now on, we will refer to the root directory of the ACE
+ source tree as $ACE_ROOT.
+
+
+
Create a file called config.h in the
+ $ACE_ROOT/ace directory that contains:
+
+
#include "ace/config-cygwin32.h"
+
+
+
Create a file called platform_macros.GNU in the
+ $ACE_ROOT/include/makeinclude directory containing:
+
+
include $(ACE_ROOT)/include/makeinclude/platform_cygwin32.GNU
+
+
+ In the above text, don't replace $(ACE_ROOT) with the
+ actual directory, GNU make will take the value from the
+ environment variable you defined previously.
+
+
On the Cygwin shell, change to the $ACE_ROOT/ace directory and
+ run make:
+
+
% cd $ACE_ROOT/ace
+ % make
+
+
+
+ This should create libACE.dll (the Win32 shared library) and
+ libACE.dll.a (the Win32 import library for the DLL).
+ Note the name for the ACE DLL on Cygwin follows the UNIX convention.
+
include
+$(ACE_ROOT)/include/makeinclude/platform_win32_interix.GNU
+
for your platform_macros.GNU file.
+
ACE should build fine with just 'make', the only other option tried thus far is
+'make static_libs_only=1' which also works. Any
+other options may not work.
+
ACE TESTS
+
The tests are located in $ACE_ROOT/tests. After building the library, you can
+change to that directory and run make:
+
% cd $ACE_ROOT/tests % make
+
Once you build all the tests, you can run run_test.pl in the tests directory to try all the tests:
+For the most part, you should be able to follow the instructions above
+to build ACE and applications that use it. Start with the
+Unix instructions above to build ACE and the
+applications that use it. Please see below for more information on
+building ACE on NT hosts for VxWorks targets.
VxWorks builds are done with a cross compiler, i.e., the compiles
+ are done on a workstation creating object modules which are
+ downloaded and loaded into the VxWorks target system.
+
C++ object modules must be post-processed by a VxWorks
+ utility called "munch" 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
+ $ACE_ROOT/bin/ace_ld,
+ which was called from the Makefiles, replacing
+ the traditional ld step. Although this script is currently still
+ available it is not used anymore.
+ You must have perl installed to use ace_ld. If perl is not on your path, you'll
+ have to set PERL_PATH to the full path (including
+ perl.exe), either in your
+ $(ACE_ROOT)/include/makeinclude/platform_macros.GNU
+ or in your environment.
+
Wind River provides GCC/G++ cross-compilers for the
+ supported target platforms. The executables are named cc<target>
+ and g++<target>; for example, ccppc and g++cpp for PowerPC
+ targets.
+
+
+You'll have to let ACE know the target type at compile time. There
+are several ways to do this; please see the
+$ACE_ROOT/include/makeinclude/platform_vxworks5.5.x.GNU
+platform file for detailed information.
+
+The VxWorks platform_vxworks*.GNU files are set up so that shared
+libraries are not built on VxWorks, by default. Only static
+libraries, with .a extension, are built. Therefore, it's not
+necessary to set the LD_LIBRARY_PATH environment variable on your host
+system when building for VxWorks targets. Please note, however, if
+you use TAO on VxWorks that you will need to set your LD_LIBRARY_PATH
+to find the TAO IDL compiler libraries (installed in the ace
+directory) on the host.
#define INCLUDE_CPLUS /* include C++ support */
+#define INCLUDE_CPLUS_IOSTREAMS /* include iostreams classes */
+#define INCLUDE_POSIX_ALL /* include all available POSIX functions */
+
+
+For completeness, here are the non-default #defines that
+we used for VxWorks 5.3.1/g++ 2.7.2:
+
+
#define INCLUDE_CPLUS /* include C++ support */
+#define INCLUDE_CPLUS_IOSTREAMS /* include iostreams classes */
+#define INCLUDE_CONFIGURATION_5_2 /* pre-tornado tools */
+#define INCLUDE_DEBUG /* pre-tornado debugging */
+#define INCLUDE_LOADER /* object module loading */
+#define INCLUDE_NET_SYM_TBL /* load symbol table from network */
+#define INCLUDE_SYM_TBL_SYNC /* synchronize host and target symbol tables */
+#define INCLUDE_NFS /* nfs package */
+#define INCLUDE_PING /* ping() utility */
+#define INCLUDE_POSIX_ALL /* include all available POSIX functions */
+#define INCLUDE_RDB /* remote debugging package */
+#define INCLUDE_RLOGIN /* remote login */
+#define INCLUDE_RPC /* rpc package */
+#define INCLUDE_SECURITY /* shell security for network access */
+#define INCLUDE_SHELL /* interactive c-expression interpreter */
+#define INCLUDE_SHOW_ROUTINES /* show routines for system facilities*/
+#define INCLUDE_SPY /* spyLib for task monitoring */
+#define INCLUDE_STARTUP_SCRIPT /* execute start-up script */
+#define INCLUDE_STAT_SYM_TBL /* create user-readable error status */
+#define INCLUDE_SYM_TBL /* symbol table package */
+#define INCLUDE_UNLOADER /* object module unloading */
+#define INCLUDE_WINDVIEW /* WindView command server */
+
+
+Also, automatic construction/destruction of static objects
+should be enabled.
+
+If you use TAO, it's also a good idea to increase the
+NUM_FILES parameter from its default of 50 to,
+say, 1000.
+
+Please note that those VxWorks kernel configuration parameters
+are set in the VxWorks configAll.h file. You must rebuild your
+VxWorks kernel after modifying that file.
+
+If you're first getting started with ACE and/or VxWorks, I recommend
+just building the ACE library and tests first. (Some of the ACE
+examples, in System_V_IPC, don't build on VxWorks yet.) Then try
+running the tests. Please see $ACE_ROOT/tests/README for the latest
+status of the ACE tests on VxWorks.
+
+Please note that the main entry point is renamed to
+ace_main (configurable via ACE_MAIN) on VxWorks with g++,
+to comply with its restriction against using main.
+In addition, ACE_HAS_NONSTATIC_OBJECT_MANAGER is enabled by default
+to cleanly support construction and destruction of static objects.
+Please see the Non-static
+ACE_Object_Manager discussion for the important implication
+of this feature.
+
+ACE threads (VxWorks tasks) can be named, for example, by supplying a
+non-null argument to the Thread_Manager spawn routines. However,
+names beginning with "==ace_t==" are forbidden because
+that prefix is used internally by ACE.
+
+You can spawn a new task to run ace_main, using either
+VxWorks sp, or ACE'S spa.
+spa can be used from the VxWorks shell to pass arguments
+to ace_main. Its usage is:
+
+
+spa ace_main, "arg1" [, ...]
+
+
+All arguments must be quoted, even numbers. You can start also ace_main
+without spawning another thread by using:
+
+
+spaef ace_main, "arg1" [, ...]
+
+
+ACE also provides the function vx_execae which is capable of running
+ace_main in a separate thread, wait for the task to finish and return
+the return code from ace_main:
+
+
+int vx_execae (FUNCPTR acemain,char* arguments, int prio = 0, int opt = 0, int stacksz = 0);
+
+
+You could call this from the VxWorks shell like:
+
+
+When prio, opt or stacksz are omitted or specified
+as 0 default values will be used. See the VxWorks shell documentation for the
+defaults for prio and opt. For stacksz the default is
+ACE_NEEDS_HUGE_THREAD_STACKSIZE.
+The arguments string will be parsed and passed on to ace_main as
+a regular argc and argv.
+
+Be aware of the fact that when you execute ace_main directly from the VxWorks
+shell argc will be zero and argv* will also be zero. Using argv[0] will not return
+the program name, but will result in a crash.
+The ACE helper functions spa, spaef and vx_execae prevent
+this problem by building a regular argc and argv which also contain a
+valid argv[0] element.
+
+NOTE: Since VxWorks support is currently being reworked with
+an initial focus on static builds the support for shared builds is momentarily
+broken. This will be remedied(!) as soon as possible.
+
+ACE supports shared libraries for VxWorks, but only with the g++
+compiler. To build shared libraries instead of the default static
+libraries, added shared_libs_only=1 to either your
+ACE_wrappers/include/makeinclude/platform_macros.GNU or
+your make invocation. Then, be sure to load the ACE (and
+any other) shared library before loading your executable(s).
+
+A shared library for VxWorks uses the same code as for a static
+(non-shared) library. However, calls to static constructors/
+destructors are added. The code in the shared library must
+be reentrant if you shared it between programs (tasks). The
+ACE library meets this requirement.
+
+Shared libraries reduce build time, executable size, and load
+time of the executable. But, you must manually load the shared
+library before loading your executable(s) with a command such as:
+
+-> ld < libACE.so
+
+Shared libraries can be unloaded the same way an executable
+(module) is unloaded.
+
+NOTE: Shared libraries on VxWorks aren't the same as
+shared libraries on other operating systems. In particular, there is
+no support for creating copies of writeable global (static) data in
+the shared library. This includes the singleton ACE_Object_Manager
+instance pointer. If you share global data between separate programs,
+they may not work properly. See the discussion of shared code and
+reentrancy in the VxWorks' Programmers Guide.
+
+Instead of trying to run separate programs onto a VxWorks target, we
+recommend creating just one program, and spawning a thread for each
+task. The TAO IDL_Cubit test collocation
+test is a good example.
+
+It's easy to link your ACE and/or TAO libraries into the VxWorks kernel.
+Just build shared versions, but
+disable the munch step. The easiest way to do that is to set the
+LD make variable to the name of your linker. For
+example, to build a libACE.so for PowerPC that can be linked into
+the kernel:
+
% cd $ACE_ROOT/ace
+% make LD=ldppc shared_libs_only=1
+
+After building the shared lib, link it into the kernel by setting
+the MACH_EXTRA make variable in the kernel configuration
+Makefile. Then, build the kernel using make exe.
+
+The ACE tests write their output files in a directory named
+log/, below the current (tests) directory.
+
+
+To run the tests from the build directory on an NT host where you crossbuild your
+VxWorks ACE/TAO you can set up the Target Server File System (TSFS) in your Target Server
+configuration. If you f.i. set the root for the TSFS to the root directory of your builddisk
+you can set the default directory for the target by issueing the following command
+from a Host shell: '@cd "/tgtsvr/{path to ACE}/ACE_wrappers/tests"'.
+The '@' addition makes sure this command is executed for the target environment and not the
+local host shell environment.
+If you also issue the command 'cd {path to ACE}/ACE_wrappers/tests' you can execute the
+generated one button testscript like: '< run_test.vxworks'.
+
+
+Running the ACE tests automatically from the ACE autobuild tool using Target Server and Host
+shell options is also supported.
+
+
+If you don't have NFS included in your VxWorks kernel, you can use these steps, provided by
+Clarence M. Weaver,
+to run the tests and capture their output:
+
+
What I did was create a log directory on the boot NT host of my VxWorks
+ target.
+
I copied all the test applications and the run_test.vxworks script to
+ the parent of the log directory.
+
Using the target shell not the host shell, I "cd" to the directory
+ containing the script and test programs.
+
Invoked the script using < run_test.vxworks from this target shell.
+
+
+Kirk Davies provided this
+approach for running the ACE tests on Tornado II:
+
+
+
Under Tornado II, I set up the Target Server File System (TSFS), and
+ the test logs get written to the log subdirectory under that.
+
You have to set an environment variable before running the tests:
+
+The following, very useful information was contributed by
+Chris Ryan
+and Paul von Behren.
+Please submit corrections, additions, or clarifications to the
+the ACE mailing list.
+
+NOTE:The make (version 3.74) that is provided with
+Tornado 2.2 cannot be used to build ACE. A working version is available
+from the WindRiver support site, download the
+
+make3_80.gvk_patches and the
+
+make3_80.tor2_2.new_dependency_rules package and install them.
+
+Using the Cygnus tools, this approach works:
+
+
You'll build both your NT and VxWorks executables in the same
+ workspace (directory hierarchy). This works because the NT
+ compiler and ACE's Makefiles put their output in different
+ directories.
+
Set up your
+ ACE_wrappers/include/makeinclude/platform_macros.GNU
+ as usual for VxWorks. See
+ the
+ g++/VxWorks platform file for more information.
+
Create an ACE_wrappers/ace/config.h file that looks
+ something like the following.
+
#if defined (_MSC_VER) || defined (__BORLANDC__)
+# include "ace/config-win32.h"
+#else
+# include "ace/config-vxworks5.x.h"
+#endif
+
+
Set your ACE_ROOT, CPP_LOCATION,
+ WIND_BASE, and WIND_HOST_TYPE environment
+ variables.
+
Build for NT, then build for VxWorks.
+
+
+A few additional Windows Notes, from Paul von Behren:
The Tornado IDE will use a standard Makefile for project
+ builds, but does not have a GUI interface for managing the
+ Makefile. By default, it will use rules from Makefile in the current
+ directory and you can configure it to add certain Makefile
+ targets to the project. If you have ACE_ROOT defined
+ before starting Tornado, you can specify an ACE Makefile as a Tornado
+ target and Tornado will then call make from the menu.
+
+
+And Chris Ryan's instructions for building for VxWorks targets
+on Windows NT hosts:
+
+
+
+
+ aced.dll is produced in an ACE NT source tree according to
+ documented procedure for Windows VC++ ACE build.
+
+ cygwin.dll is from the Cygnus GNU software download and install.
+
+
Basically, follow documented procedure for ACE build/install on UNIX
+ platform. Create a $ACE_ROOT/ace/config.h that looks
+ like:
+
#include "config-vxworks5.x.h"
+
+
+ And create a
+ $ACE_ROOT/include/makeinclude/platform_macros.GNU
+ that looks like:
+
+ WIND_BASE = /tornado
+ WIND_HOST_TYPE = x86-win32
+ CPU = I80486
+ include $(ACE_ROOT)/include/makeinclude/platform_vxworks5.5.x.GNU
+
+
+
When using cygnus windows GNUTools on WinNT you have to start
+ make with "--unix" option, otherwise WinNT shell cmd.exe is responded and
+ not sh.exe, i.e.,
+
make --unix static_libs_only=1
+
+
+
+
TAO on NT Tornado host, VxWorks target.
+
+
+
Build ACE and TAO_IDL in the NT tree as already documented.
+ Be sure to build ACE's gperf on NT, in
+ ACE_wrappers/apps/gperf/src.
+
+
Build $TAO_ROOT/tao
+
CPP_LOCATION=/Program Files/DevStudio/VC/bin/CL.exe
+ cd $TAO_ROOT/tao
+ /gnuwin32/b18/H-i386-cygwin32/bin/make
+
+
+
Build orbsvcs.
+
CPP_LOCATION=/Program Files/DevStudio/VC/bin/CL.exe
+ cd $TAO_ROOT/orbsvcs/orbsvcs
+ /gnuwin32/b18/H-i386-cygwin32/bin/make
+
+
+
Build $TAO_ROOT/tests
+
+
+
+
Jaffar Shaikh's
+Notes for Building ACE and TAO for VxWorks on NT host
+
Scenario: I was building the ACE and TAO for VxWorks
+on NT. The target system was a PPC860 based chassis and another a NT
+host based card.
+
Host System:
+
NT 4.0 workstation with 128 M RAM, 266MHz Pentium.
+WIND_BASE = /tornado
+WIND_HOST_TYPE = x86-win32
+include $(ACE_ROOT)/include/makeinclude/platform_vxworks5.5.x.GNU
+ACE_COMPONENTS=FOR_TAO (you may choose this option to build ACE library that supports TAO)
+
+
+
+
Steps to Build
+
1) Build Ace.dll under NT
+
In MS Visual C++ open C:\Corba\ACE_wrappers\ace.sln And build Ace
+DLL
+
Copy Ace.dll in C:\bin
+
+
2) Build gperf utility under NT
+
In MS Visual C++ open
+C:\Corba\ACE_wrappers\apps\gperf\src\gperf.sln. Build gperf.exe
+
Copy gperf.exe to C:\bin
+
+
3) Mount Directries in Cygwin
+
Click on Cygnus Solutions -> Cygwin Bash Shell
+
Mount following directories by using mount command.
+
create respective directories first then use mount command
+
+
e.g. Create /Corba directory then use $mount -s "C:\Corba"
+/Corba
+
+
C:\Corba mount to /Corba
+
C:\tornado mount to /tornado
+
C:\Perl mount to /perl
+
C:\Cygwin mount to /cygwin
+
C:\bin mount to /bin
+
C:\Program Files mount to /Program Files
+
+
4) Build ACE in Cygwin
+
$cd /Corba/ACE_wrappers/ace
+
$make static_libs_only=1
+
This will build your ace library libACE.a for VxWorks. If you use
+option shared_libs_only=1 then the build will be libACE.so. The other
+options are same as follows.
The minimum Tao does not have following components,
+
Dynamic Skeleton Interface
+
Dynamic Invocation Interface
+
Dynamic Any
+
Interceptors
+
Interface Repository
+
Advanced POA features
+
CORBA/COM interworking
+
+
You may play around with above options to find suitable build for
+your needs. For example when you give option debug=1 all the debug
+symbols will be created and the build will huge in size. The debug
+symbols are necessary when you want to debug your code.
ACE can be built for Android by using the Android Native Development Kit
+(NDK). This is different than the standard way of writing Android
+applications in Java which run the on Android Runtime or the older Dalvik
+Virtual Machine. Applications built using the NDK are native Linux applications
+written in C or C++ specifically compiled to run on Android systems. In
+addition, applications built using the NDK have access to Android-specific APIs
+much like the ones available to Java-based Android applications.
+
+
+
+
Windows Users: These instructions are written for a Unix based
+platform like Linux, but can also be used on Windows. If you are using an
+virtualized Linux environment like Windows Subsystem for Linux (WSL), Docker,
+or a traditional VM, then you can use the Linux version of the NDK and ignore
+rest of this note and all the other Windows specific notes.
+
+
+
If that is not the case, you should also pay attention to the notes marked
+with "Windows Users:" in addition to the rest of the instructions. In
+addition to the Windows version of the Android NDK, you will also need
+MSYS2 for Unix utilities that ACE needs.
+
To build ACE for Android you need to download the NDK and generate a
+toolchain for the specific Android target you want. The specific target is
+defined by two things:
+
+
+
- The minimal API level to target.
+
A lower level means larger amount of potential users but also
+ potentially less features. Android has many API levels
+ to target. They roughly correspond to the versions of Android.
+
+
- The CPU architecture to target (Also called the Application Binary
+ Interface or ABI by the NDK documentation).
+
In addition to ARM, Android also supports x86 and MIPS,
+ although support for MIPS has been dropped from the NDK. This is the official
+ documentation on the ABIs. These are the ABIs that ACE supports at the
+ time of writing and must be passed to ACE as ANDROID_ABI:
+
+
+
armeabi-v7a
+
32-bit ARM, The default ABI for both the NDK and ACE.
+
armeabi-v7a-with-neon
+
armeabi-v7a with NEON extensions enabled.
+
arm64-v8a
+
64-bit ARM, Sometimes referred to as aarch64.
+
x86
+
32-bit x86
+
x86_64
+
64-bit x86
+
+
+ It should be noted that starting in August 2019, the Google Play
+ Store will require new apps to have 64-bit libraries if they have native
+ libraries. 32-bit native libraries will still be supported but they must also
+ have 64-bit libraries. Look up any restrictions that may affect
+ apps you want to publish on the Play Store, including minimum API
+ level.
+
+
+
+
+
+
+
To generate a toolchain, one use must use
+build/tools/make_standalone_toolchain.py in the NDK. A destination must be
+chosen and is denoted here as $TOOLCHAIN. For example, to generate a
+toolchain targeting 32-bit ARM Android 7.0 "Nougat" (API Level 24) and later:
+
+./make_standalone_toolchain.py --arch arm --api 24 --install-dir $TOOLCHAIN
+
+
$TOOLCHAIN/bin must be in your $PATH when building ACE and
+applications using ACE.
+
+
This table shows how the ANDROID_ABI variable and the --arch argument correlate:
+
+
+
ANDROID_ABI
+
--arch
+
+
+
armeabi-v7a
+
arm
+
+
+
armeabi-v7a-with-neon
+
arm
+
+
+
arm64-v8a
+
arm64
+
+
+
x86
+
x86
+
+
+
x86_64
+
x86_64
+
+
+
+
+
Windows Users:
+Android NDK includes Python in prebuilt\windows-x86_64\bin for
+64-bit Windows NDKs. For the example above, assuming %NDK% is the
+location of the NDK and %TOOLCHAIN% is the desired location of the
+toolchain, run this command instead:
For Windows %TOOLCHAIN%\bin and the location of the MSYS2
+utilities must be in %PATH% when cross compiling ACE. The default
+location for these would be C:\msys64\usr\bin.
+
+It is highly recommended to use the latest NDK available assuming
+that it works with ACE. It is possible to use NDKs older than r18, but these
+have caveats:
+
+
+
+ In NDK r16, a file called ndk-version.h was added that
+ contains the version of the NDK. If using an earlier NDK, you must
+ define the macros __NDK_MAJOR__ and __NDK_MINOR__
+ in ace/config.h before
+ #include "ace/config-android.h".
+ The scheme works like this:
+
+
+
Revision
+
__NDK_MAJOR__
+
__NDK_MINOR__
+
+
+
r16
+
16
+
0
+
+
+
r16a
+
16
+
1
+
+
+
r16b
+
16
+
2
+
+
+
+
+ As of NDK r18, the only compiler that comes with the NDK is clang and by
+ default the build system assumes that clang is available and will use it.
+ However there was a transitional period between r12 and r17 where GCC and
+ clang both exist in the NDK. In some cases GCC should be used if linking
+ errors occur with these NDKs (For example missing references to
+ stderr). To let the build system decide between them, set
+ android_force_clang:=0 in
+ include/makeinclude/platform_macros.GNU before including
+ platform_android.GNU. This should be set for NDKs before r15.
+
+
+ There are probably unknown conflicts, especially in the minor revisions
+ before the last minor revision of a NDK revision.
+
Windows Users: If cross compiling TAO and the host tools were
+ built using using Visual Studio, make sure cl.exe can be run
+ from the environment when building for Android, as tao_idl
+ will need to use it as a C preprocessor.
+
+ Set ANDROID_ABI to one of the options above. This
+ must match the toolchain --arch argument used according
+ to the table above.
+
+
Set options for debug and optimization options as desired.
+
If you want to compile static, add static_libs_only:=1
+
Must include include $(ACE_ROOT)/include/makeinclude/platform_android.GNU.
+
+ If building TAO, set the tao_idl options specified in
+ the cross compiling instructions in TAO-INSTALL.html
+
+
+
+
+
+
Generate makefiles (if necessary).
+
Build with GNU make. Make sure you have $TOOLCHAIN/bin in
+ your $PATH.
+
+ Windows Users: Make sure you have %TOOLCHAIN%\bin
+ and MSYS2's bin in your %PATH% when building.
+ If you are cross compiling TAO you will also need a preprocessor for
+ tao_idl available (See Windows note above).
Native applications using the ACE library can be installed onto devices by
+several different methods. The files can be include as assets of Java
+application and can be written by the Java application into it's executable
+program directory. The native application can be downloaded by a Java
+application and written into the Java applications executable program
+directory. The native application can also be uploaded using the Software
+Development Kit's ADB tool. This method requires uploading the native
+application to a directory that allows execution and having any output
+directed to a writable directory.
+On Android, ACE_Log_Msg (and therefore ACE_DEBUG and
+ACE_ERROR) uses Android's logging system (aka Logcat) by default
+in addition to stderr because stdout and
+stderr are discarded under normal circumstances. To disable this
+at runtime, run:
+
+
+
+ACE_LOG_MSG->clr_flags (ACE_Log_Msg::SYSLOG);
+
+
+
To disable this at compile time include these lines in config.h:
+ Depending on the features of ACE, TAO, or other software desired, you might need
+ OpenSSL. On Android, OpenSSL isn't part of the NDK Library and Android
+ preloads the system SSL library (either OpenSSL or BoringSSL) for the Java
+ Android API. This means OpenSSL MUST be statically linked to avoid
+ conflicts with the almost certianly incompatible system SSL library.
+
+ To build OpenSSL for Android, please read NOTES.ANDROID that comes
+ with OpenSSL's source code. The static libraries will used if the shared
+ libraries are not found. This can be accomplished by either disabling the
+ generation of the shared libraries by passing no-shared to
+ OpenSSL's Configure script or just deleting the so files after
+ building OpenSSL.
+
+
+Building and installing ACE Network Services on UNIX is relatively
+simple (the process for Win32 is different).
+Here's what you need to do:
+
+
+
+
Build and install ACE on UNIX as described earlier. If ACE is built at the root of the ACE
+ source tree (and ACE has been ported to your platform, of course) the
+ netsvcs static and shared object libraries should be built
+ automatically. In addition, the server driver program
+ (main) contained in $ACE_ROOT/netsvcs/servers/main.cpp
+ should also be compiled and ready to run.
+
+
Set your LD_LIBRARY_PATH environment variable to
+ where the binary version of the ACE netsvcs library. For
+ example, you probably want to do something like the following
By default, if the shared object library is built, the services
+ are linked into the main driver program dynamically.
+ To specify which services should be linked in and executed, edit the
+ $ACE_ROOT/netsvcs/servers/svc.conf
+ file. During your editing, you should update information (such as the
+ default service port numbers) that affects the initialization of
+ services in this file. Refer to the
+ Service Configurator
+ documentation to learn how the configuration file is parsed and
+ how the services are dynamically linked and executed. In
+ addition, refer to the Network
+ Services documentation to learn more about how to configure
+ each network service.
+
+
If you only want to link the services statically, simply remove
+ or rename the svc.conf file.
The first step for all platforms is to build and install the
+OpenSSL distribution. The
+ACE_SSL library must then be built according to the instructions
+below.
+
Unix
+
+
Make sure the OpenSSL header file directory is in your compiler's
+ include path, and that OpenSSL libraries are in your library link/load
+ path (e.g. LD_LIBRARY_PATH). If you
+ installed OpenSSL into a set of directories unknown by the compiler,
+ set the SSL_ROOT environment variable to point to the
+ top level directory of your OpenSSL distribution, i.e. the one
+ containing OpenSSL's include and lib
+ directories.
+
Build ACE as described above. When building ACE, add
+ ssl=1
+ to your make
+ command line invocation, or add it to your
+ platform_macros.GNU file.
+
Build the ACE_SSL library in the $ACE_ROOT/ace/SSL
+ directory. The ACE_ROOT environment variable should be set
+ prior to this point.
+
+
Microsoft Visual Studio
+
+
Set the SSL_ROOT environment variable to the location
+ of the directory containing the OpenSSL inc32 and
+ out32dll directories.
+
Add ssl=1 to your MPC
+ $ACE_ROOT/bin/MakeProjectCreator/config/default.features
+ or $ACE_ROOT/local.features file.
+
At the moment you are using OpenSSL v1.1 or
+ newer also add openssl11=1 to your MPC
+ $ACE_ROOT/bin/MakeProjectCreator/config/default.features
+ or $ACE_ROOT/local.features file.
+
Re-run MPC to add
+ support for building the ACE_SSL library to your MSVC++
+ workspaces and projects.
+
Open the ACE.sln solution, and refer to the ACE build
+ and installation instructions above for details on creating a
+ config.h configuration header for this platform. Once
+ the config.h file has been created, build the
+ ACE_SSL project.
+
+
Embarcadero C++
+
Support for building ACE's ACE_SSL library and TAO's SSLIOP
+ pluggable protocol with Embarcadero C++ does exist.
+
+
Set the SSL_ROOT environment variable to the location
+ of the directory containing the OpenSSL inc32 and
+ out32 directories.
+
Add ssl=1 to your MPC
+ $ACE_ROOT/bin/MakeProjectCreator/config/default.features
+ or $ACE_ROOT/local.features file, and re-run MPC to add
+ support for building the ACE_SSL library to your Embarcadero C++ makefiles.
+
+There is a general method for building and using ACE_Reactors for various GUI
+libraries.
+
Building GUI Reactor Library
+
+
Try to generate build files using MPC. Inspect the output of MPC to find out which features are
+ necessary to build given reactor. Add these features to
+ ACE_wrappers/bin/MakeProjectCreator/*.features file, or pass them directly to MPC
+ using -features command line option. For example, for FlReactor the procedure
+ consists of five steps
+
+
In the first pass one gets that x11 (X11 libraries) is missing.
+ $ mwc.pl -type gnuace
+ Skipping ACE_FlReactor (ace_flreactor.mpc), it requires x11.
+
+ Ensure that X11 libraries are installed, then pass x11=1 feature to MPC.
+
In the second pass one gets that gl (OpenGL library) is missing.
+ $ mwc.pl -type gnuace -features x11=1 ace.mwc
+ Skipping ACE_FlReactor (ace_flreactor.mpc), it requires gl.
+
+ Ensure that OpenGL libraries are installed, then pass gl=1 feature to MPC.
+
In the third pass one gets that fl (Fast Light Toolkit) is missing.
+ $ mwc.pl -type gnuace -features x11=1,gl=1 ace.mwc
+ Skipping ACE_FlReactor (ace_flreactor.mpc), it requires fl.
+
+ Ensure that Fast Light Toolkit libraries are installed, then pass fl=1
+ feature to MPC.
+
In the fourth pass one gets that ace_flreactor feature is missing
+ $ mwc.pl -type gnuace -features x11=1,gl=1,fl=1 ace.mwc
+ Skipping ACE_FlReactor (ace_flreactor.mpc), it requires ace_flreactor.
+
+ Allow MPC to generate makefiles for FlReactor by setting ace_flreactor=1 feature.
+
In the last pass one obtains files for building FlReactor.
+ $ mwc.pl -type gnuace -features x11=1,gl=1,fl=1,ace_flreactor=1 ace.mwc
+
+
+ Currently to simplify MPC generation some of features are turned on by default in
+ ACE_wrappers/bin/MakeProjectCreator/global.features. For examples to generate
+ files related with Fl one has to provide only fl=1 feature. To obtain a more fine grained controll
+ over MPC generation process one may modify ACE_wrappers/bin/MakeProjectCreator/*.features
+ files.
+
+
Required build files are generated now, it is enough then to invoke build tool.
+ For example for under MPC::gnuace one has to call
+ make fl=1. For MPC::vc7 target all features are
+ encoded in generated project files, thus it is enough to compile ACE using MSVC.
+
+
+ The build procedure leads to a specific GUI Reactor library. For example, for
+ Qt and Linux one gets libQtReactor.so, while for
+ Windows the results are shared QtReactor.dll and import
+ QtReactor.lib libraries or their variants depending on build options.
+ When compiling TAO also GUI related libraries are created like libTAO_QtResource.so.
+
Using GUI Reactor Library
+ Here one has at least three use cases:
+
+
Applications with their own build system.
+ To use ACE support for GUI one has to include specific GUI headers and
+ link with specific ACE_[GUI]Reactor library. When using TAO support for GUI one has
+ also to link with specific TAO_[GUI]Resource library.
+
Applications with build system using MPC.
+ In general, it is better to create specific base projects for using ACE GUI support in such application.
+ Base projects provided by ACE ACE_wrappers/bin/MakeProjectCreator/[ace,tao]_[gui][reactor,resource].mpb
+ may be an examples of how to do this.
+
Internal ACE applications like tests or examples.
+ MPC project for internal ACE application using GUI support should be derived from
+ ace_[gui]reactor.mpb base projects. To employ TAO support for GUI one should derive
+ the project from tao_[gui]resource.mpb These base projects ensure that all necessary libraries
+ are linked to the application, specifies features necessary to build a project and moreover impose a
+ build order consistant with ACE. For example, the application project using XtReactor should be
+ derived from ace_xtreactor.mpb.
+
+
Notes on specific GUI Reactors
+
+
QtReactor
+ The build is controlled by ace_qtreactor [1 by default] feature.
+ To build this reactor one has to provide feature qt [0 by default] (Qt library). Moreover,
+ it is assumed that Qt was installed in a standard way
+ and QTDIR points to Qt installation folder. To build TAO
+ support for Qt one should use tao_qtresource [1 by default] feature.
+
XtReactor
+ The build is controlled by ace_xtreactor [1 by default] feature.
+ To build this reactor one has to provide the following features: x11 [1 by default]
+ (X11 libraries) and xt [1 by default] (X11 Toolkit).
+ Moreover, some examples and tests related with XtReactor
+ needs additionall features namely either motif [0 by default] (Motif/Lesstif libraries) or
+ athena [0 by default] (Athena widgets). To build TAO
+ support for xt one should use tao_xtresource
+ [1 by default] feature.
+
TkReactor
+ The is controlled by ace_tkreactor [1 by default] feature. To build this reactor one has to provide
+ tk [0 by default] (Tcl libraries) feature. To build TAO
+ support for Tk one should use tao_tkresource [1 by default] feature.
+
FlReactor
+ The build is controlled by ace_flreactor [1 by default] feature.
+ To build this reactor one has to provide the following features: x11
+ [1 by default] (X11 libraries),
+ gl [1 by default] (OpenGl) and fl
+ [0 by default] (Fast Light Toolkit). To build TAO
+ support for Fl one should use tao_flresource [1 by default] feature.
+ MS Windows: The paths to fltkdll and
+ OpenGL32 libraries, as well as fltk header files
+ should be setup manually for succesfull compilation. Obviosuly,
+ x11switch is ignored for this platform.
+
+
+ Take a look at (CE-status.txt) for
+ up-to-date information about ACE on Windows CE and Windows Mobile.
+
+
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.
+
+ 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 <shl@janis.gtri.gatech.edu>
+ for providing the following useful information:
+
+ By default, ACE uses both the Solaris and POSIX thread
+ interface. To disable use of the Solaris thread interface, add
+ -D_POSIX_PTHREAD_SEMANTICS to the
+ CFLAGS in your
+ $(ACE_ROOT)/include/makeinclude/platform_macros.GNU.
+ See the Solaris Intro (3) man page for more information.
+
+ To disable ACE thread support completely, build with the
+ threads=0 make flag. See the Makefile Flags section below for more
+ information on make flags.
+
+ 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.
+
+
AIX
+
+ 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.
+
+ The ace/config-aix-5.x.h 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:
+ #define ACE_HAS_AIO_CALLS to your config.h
+ file before including ace/config-aix-5.x.h.
+
+ 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.
+
+ For your platform_macros.GNU file, you should use
+ platform_aix_ibm.GNU when building ACE with any of the
+ IBM compilers and platform_aix_g++.GNU when building ACE
+ with g++.
+
+ BTW, here's a technique from Rob Jordan <jordan@hursley.ibm.com>
+ that can reduce the size of the ACE libraries by about one
+ third, and can also be applied to applications. It works by
+ optimising the sharing of template functions, which are created
+ in an "unusual" way under AIX. It also speeds up
+ compilation.
+
+ Here's how to optimise the ACE library generation:
+
+ Look at the ace/GNUmakefile.ACE
+ in $ACE_ROOT/ace. Create a file called
+ ACE_All_Src.cpp, and add a line to #include
+ each of the source files
+ listed under FILES= in the GNUmakefile. Create a
+ file called ACE_All_Tmp.h
+ and add a line to #include each of the .h files listed under
+ TEMPLATE_FILES= in the GNUmakefile. Now update the
+ GNUmakefile so that
+ FILES=ACE_All_Src and
+ TEMPLATE_FILES=ACE_All_Tmp.
+
+ ACE has been ported to Linux on
+ Intel, Alpha, and PowerPC platforms. If you use a RedHat 5.x
+ distribution, it's best to use RedHat 5.1 or later. ACE works
+ without any modifications on RedHat 5.1 and later, and on
+ Debian 2.1 on both Intel and Alpha. Use the
+ platform_linux.GNU and ace/config-linux.h
+ in your platform_macros.GNU and
+ config.h files, respectively. The same
+ files can be used on PowerPC, with LinuxPPC
+ 1999 (R5), with glibc 2.1.1.
+
+ If you run out of memory, it's easy to add virtual memory on
+ Linux. Please see the mkswap man page. You'll
+ need at least 256 to 300 Mb of virtual memory (RAM + swap) to
+ compile all of ACE+TAO. The System
+ Resource Requirements section has some suggestions on how
+ to reduce the memory requirement.
+
+ The glibc 2.0 dynamic loader isn't thread safe. If you want to
+ use the Invocation API you'll have to set
+ LD_BIND_NOW=true. If you want to use
+ dlopen, you should use RTLD_NOW. The
+ dynamic loader in glibc 2.1 is thread safe.
+
+ NOTE: The TAO NameService uses IP multicasting
+ by default, though it is not required. IP multicast on Linux
+ requires the following:
+
+
+
Enable IP multicast in the Linux kernel. It is enabled in
+ the default RedHat 5.1 kernel. In older distributions, you
+ can enable it by rebuilding your kernel with CONFIG_IP_MULTICAST
+ enabled.
+
Enable IP multicast in ACE. It is enabled by default in
+ ace/config-linux.h. If you don't use
+ IP multicast, add #define ACE_HAS_IP_MULTICAST 0
+ to your ace/config.h before building ACE.
+
There must be a network interface that is up and supports
+ multicast. If you have linuxconf, it's easiest to use that
+ to add a network route for multicast (224.0.0.0) on one of
+ your network interfaces, such as eth0. If
+ you don't have or use linuxconf, try adding a multicast
+ routing table entry using something like this:
+
# route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0
+
+
+
+ Some of the ACE tests fail on older, pre-glibc2 Linux platforms,
+ such as RedHat 4.2. The problems are with threads and
+ thread-specific storage.
+
+
SCO UNIX
+
+ ACE has been ported to SCO UNIX using the GNU g++ 2.7.2
+ compiler. Arturo Montes <mitosys@colomsat.net.co>
+ maintains this code. In addition, he also maintains a version
+ of FSU pthreads.
+
+
SGI IRIX 5.x and 6.x
+
+ ACE used to build fine using the SGI C++ and GNU GCC compilers
+ for IRIX 5.x. It has been ported to IRIX 6.x using the SGI
+ MipsPro 7.1 C++ compiler; be aware that in IRIX 6.2 there is a
+ number of patches that have to be installed and exceptions
+ appear to fail with the O32 ABI. Please check the config files
+ for the details.
+
+
OSF/1 3.2 and 4.0 (a.k.a. Digital UNIX 4.0)
+
+ The Digital UNIX C++ 5.4 through 5.7 compilers have problems
+ with ACE's templates. They compile the lib and most of the test
+ programs, although they warn about template usage. Most tests
+ run, some dump core. If you use a 5.x version of cxx, be sure
+ to set the CXX_VER variable to CXX_5, either on your make
+ command line or in an environment variable. The ACE Makefiles
+ assume by default that the cxx version is 6.x or later.
+
+ CXX 6.0 and 6.1 are much improved over 5.x: V6.0-020, V6.1-025,
+ and later build all of ACE cleanly. All of the tests in
+ $(ACE_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.
+
+ NOTE: if you use Digital UNIX 4.0f or later, you must
+ use ace/config-tru64.h instead of
+ ace/config-osf1-4.0.h. ace/config-tru64.h
+ can be used for all supported compilers on any version of
+ Digital UNIX after and include 4.0. And, with 4.0f and later when
+ using Digital CXX, you must use
+ include/makeinclude/platform_tru64_cxx.GNU instead of
+ include/makeinclude/platform_osf1_4.0.GNU.
+
+
FreeBSD
+
+ FreeBSD is a fast evolving platform. However, it has the
+ advantage of having standard releases. At this moment, ACE is
+ only perodically tested against -stable (3.1R) and we rely a lot
+ on FreeBSD users' feedbacks.
+
+ Notice that on older FreeBSD, ld.so only looks for
+ so libraries with version number appended. ACE makefiles
+ create symlinks for most shared libraries if
+ versioned_so is defined to 1 in
+ $ACE_ROOT/ace with appropriate ACE version.
+ However, this does not work for libACE.so itself so you have to
+ create it manually (If you figure out how to do this, please let
+ us know) like this:
+
+ On newer FreeBSD (3.0 or later,) this is no longer necessary.
+
+
NetBSD
+
+ Like older FreeBSD, NetBSD's ld.so also requires
+ versioned .so files.
+
+
OpenBSD
+
+ ACE has been ported to OpenBSD 3.1 and GNU g++ 2.95.3.
+
+ As with FreeBSD and NetBSD, OpenBSD requires versioned .so
+ files. This is currently handled by the build files and no
+ additional work is needed.
+
+ ACE has been ported to OpenBSD with and without pthreads
+ enabled. When using pthreads, though, C++ exceptions must be
+ disabled. This is a known problem with the current release of
+ OpenBSD (see www.openbsd.org, bug #1750). ACE emulated
+ exceptions work fine.
+
+ Compiling TAO may require the user data segment size
+ restrictions and possibly other options to be increased. This
+ is done by modifying the default user class in /etc/login.conf
+ or by adding a new class and modifying the master passwer file
+ accordingly.
+
+
UnixWare
+
+ Steve Huston <shuston@riverace.com>
+ has ported ACE to work with UnixWare 2.01 and g++.
+
+ Ganesh Pai <gpai@voicetek.com>
+ subsequently did the port for version 2.1.2, also with g++.
+
+ Phil Mesnier <
+ mesnier_p@ociweb.com> updated the port to support
+ UnixWare 7.1.0, with help from Michael Meissnitzer
+ <
+ michael.meissnitzer@siemens.at>, Christian Klepp <
+ christian.klepp@siemens.at
+ > and Engelbert Staller <
+ engelbert.staller@siemens.at>
+ Building ACE (and TAO) on Unixware 7.1.0 requires a very specific
+ g++ build environment. In particular, you must build and install
+ g++ 2.95.2, along with binutils 2.9.1. The order (and the declaration
+ of configuration) is extremely important. Using the gcc compiler
+ provided on the Skunkware CD on a pentium system, here is the recipe
+ I used to build a working environment (as root):
+
mkdir /usr/local/newgnu
+< ftp and untar binutils-2.9.1 >
+< ftp and untar gcc-2.95.2 >
+ mkdir -p build/binutils build/gcc
+ cd build/binutils
+ ../../binutils-2.9.1/configure i386-sco-sysv4
+ gmake # takes a long time
+ gmake install # this creates /usr/local/i386-sco-sysv4/...
+ mkdir /usr/local/i486-pc-sysv5/bin
+ cd /usr/local/i486-pc-sysv5/bin
+ for a in /usr/local/i386-sco-sysv4/bin/*; do ln -s $a .; done
+ #links all the newly installed utilities
+
+ cd /usr/local/newgnu/build/gcc
+ ../../gcc-2.95.2/configure --with-gnu-as --with-gnu-ld
+ gmake bootstrap # takes a long time
+ gmake install
+ mkdir /usr/local/i586-UnixWare7.1.0-sysv5/bin
+ for a in /usr/local/i386-sco-sysv4/bin/*; do ln -s $a .; done
+
+ Once done, ACE and TAO will successfully build and link.
+
+ 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:
+
+
+
Increase the limits in /etc/starttab,
+ then reboot system. We use these limits:
+
# Data, stack, and core file limits (in Kbytes)
+80000
+16000
+102400
+
Enable or expand virtual memory, with something like:
+
# mkcontig /swap 320
+# prio 17 vmstart /swap
+ See the mkcontig and vmstart
+ man pages, and /bin/rc.
+
+
+ Please see the comments in the
+ ACE
+ platform_lynxos.GNU file for information on, and an
+ example of, tailoring for your particular platform.
+
+ NOTE: if you want to use IP multicast on LynxOS, be sure to add
+ this line to your /net/rc.network, and reboot:
+
+ /bin/route add "224.0.0.0" "$my_name"
+
+
+
VxWorks
+
+ David Levine 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.
+
+ At this moment Remedy IT 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 here.
+
+
+ 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
+ #define ACE_HAS_IP_MULTICAST to your
+ ace/config.h.
+
+ 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 SPR 4542
+ for more information.
+
+ In addition to all of the other benefits of ACE, it helps work
+ around some deficiencies with VxWorks. The problems are:
+
+
+
+
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.
+
+
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 below
+ for details.
+
+
+
+ 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.
+
+ 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 cplusDtors and
+ then cplusCtors between runs.
+
+
MVS OpenEdition
+
+ All of ACE has been ported to OpenEdition by Chuck Gehr <gehr@sweng.stortek.com>.
+ The ACE library, all the tests and most of the examples and apps
+ build clean. There are still some problems that need to be
+ ironed out:
+
+ MVS does not support the dynamic linking dl...() calls that the
+ Service Configurator uses to dynamically link services at run
+ time. As a result, all the examples and apps that use a svc.conf
+ file (for dynamically configuring service objects) do not work,
+ however, most of these apps can be built/run statically. Also,
+ the Svc_Conf_l.cpp and Svc_Conf_y.cpp files are generated using
+ flex and yacc on a ascii (not ebcdic) machine and as a result
+ they don't work very well with ebcdic svc.conf files. We should
+ be able to regenerate these files on MVS but MVS doesn't have
+ flex. This is something that needs to be done.
+
+ Some of the tests do not execute properly. This is a minority
+ and over time the goal is to get to 100%.
+
+ The make scheme for some of the apps still doesn't work
+ perfectly on MVS. This is mainly due to the way shared
+ libraries are handled on MVS. See additional
+ build tips for MVS for more on this.
+
+
QNX Neutrino
+
+ ACE has been ported to QNX Neutrino
+ 2.0. We cross-compile for Neutrino on a QNX4 host using g++
+ 2.8.1, using the ace/config-qnx-neutrino.h
+ and include/makeinclude/platform_qnx_neutrino.GNU
+ configuration files. Many of the ACE tests succeed, though some
+ fail. As the porting effort progresses, we hope to eliminate
+ these failures. If you know of fixes, please send them to
+ us.
+
QNX RTP
+
+ ACE has been ported to QNX RTP
+ . We compile for QNX RTP using the GCC compiler shipped with the
+ distribution, using the ace/config-qnx-rtp.h
+ and include/makeinclude/platform_qnx_rtp_gcc.GNU
+ configuration files.
+ Many of the ACE tests succeed, though some
+ fail. As the porting effort progresses, we hope to eliminate
+ these failures. If you know of fixes, please send them to
+ us.
+
+ Under the current version of QNX RTP ACE fails if compiled with
+ inline=0 .
+
+ 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 RTEMS_MAKEFILE_PATH to point to the location
+ of your RTEMS installation, see below for an example.
+ When building without network support you will need the ace_for_tao
+ subsetting functionality enabled. For this add ace_for_tao = 1
+ to your bin/MakeProjectCreator/config file and regenerate the
+ GNU makefiles as described here.
+
+
PharLap ETS
+
+ ACE has been ported to Ardence's
+ PharLap ETS
+ 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).
To build for PharLap, you'll need to use MPC to
+ generate .sln/.vcproj files with the ETS configurations. For example:
+
+ 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
+ _ETS suffix and will include the "ETS Debug" and
+ "ETS Release" configurations.
+ 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.
+
+ 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:
+
+
msvcp71d.dll
+
msvcr71d.dll
+
+
+ To build ACE for National Instruments' LabVIEW RT, use
+ the Pharlap ETS information above, but add the following line to your
+ config.h file:
+
+ #define ACE_PHARLAP_LABVIEW_RT
+
+ This setting makes the necessary adjustments for LabVIEW's implementation
+ of Pharlap ETS.
+
+ 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 log directory under the
+ current working directory while executing, add the following line to
+ your config.h file:
+
+ #define ACE_PHARLAP_TESTLOG_TO_FILE
+
+ This setting has no affect on TAO tests which always write test output
+ to stdout.
+
+
+
Mac OS X (10.2.x)
+
+
ACE builds and runs on Mac OS X 10.2.x, but the following are
+ needed to build it:
+
+
1. The latest version of the Apple Developer Tools
+ (December 2002)
+
2. The dlcompat library (obtained either through Fink or
+ SourceForge)
+
+
When creating $ACE_ROOT/ace/config.h for Mac OS X, you need
+ to add the following if you obtained dlcompat via Fink:
Currently, all ACE tests pass except Process_Mutex_Test and
+ MEM_Stream_Test. Also, Mac OS X doesn't yet support *nix
+ aio_* calls, and ACE does not know anything about Mach.
+
+
The work to port ACE to Mac OS X was done by several people,
+ John Zorko
+ <j.zorko@att.net> is
+ only one of them.
+
+
iPhone/iPod Touch/iPad
+
+
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:
+
+
1. The iPhone SDK.
+
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.
+
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.
+
4. When creating $ACE_ROOT/include/makeinclude/platform_macros.GNU,
+ include 'include $(ACE_ROOT)/include/makeinclude/platform_macosx_iphone.GNU'
+ in the file.
+
+If you use the GNU GCC g++ compiler please note the following:
+
+
+
ACE/TAO needs g++ 2.95.x or better. Older versions are not usable anymore
+
+
Make sure to update your gcc config.status
+ file. This file is produced when installing gcc; it specifies
+ where to install the binary files that gcc uses. For example,
+ it specifies whether to use Solaris's /usr/ccs/bin
+ binary utils or GNU binary utils. The
+ config.status file is an output of the gcc
+ configure script; it is preferable to use the
+ --prefix option to configure instead
+ of hacking its output.
+
+
If you are getting weird link errors when building libACE
+ on Solaris you are probably using the GNU linker. Try using the
+ Sun linker (/usr/ccs/bin/ld) instead. Note that gcc first looks
+ for the GNU linker if it is installed along with gcc. The only
+ way to not use the GNU linker is to delete it from the
+ installation or to build your own compiler with no linker. Be
+ aware that you still need the libraries and includes of gcc.
+
+ NOTE: if you do use the GNU linker, you might need to change
+ the -G flag to -shared in
+ the SOFLAGS definition in your
+ include/makeinclude/platform_macros.GNU.
+
+
Don't get too confused about contradictory statements in
+ the gcc documentation. It was written by different
+ people...
+
+
Make sure that the linker invoked by gcc produces code
+ that initializes static objects. Please see gcc's
+ documentation for using collect2.
+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
+
The amount of system resources required to build
+ACE and TAO varies greatly. The required system resources are
+influenced by OS and compiler platform, build options, and component
+configurations. As a rough guide, the typical peak memory requirement
+can be well over 512 MB (notably, for TAO's orbsvcs). Depending on
+your OS and compiler configuration, an entire build
+of ACE and TAO can use well over 4 GB of disk space. It's usually not
+necessary to build all of ACE and TAO, though.
+
+Much less disk space is required for just the libraries. For example,
+see the ACE
+library subset sizes.
+
+If you run out of memory when building, you might consider trying
+some or all of these suggestions:
+
+
Enable or increase virtual memory. If you're on a Linux or LynxOS platform,
+ please see the appropriate sections above.
+
Disable/enable optimization and/or debugging. See the
+ Makefile Flags discussion for information
+ on how to do that via ACE's Makefiles.
+
If you're using g++, try removing -pipe from
+ CFLAGS in your
+ include/makeinclude/platform_macros.GNU file.
+
Restrict the components that you build. For ACE and TAO, see the
+ discussion of ACE_COMPONENTS in the
+ ACE subsets page. For TAO's
+ orbsvcs, see the discussion of TAO_ORBSVCS in
+ orbsvcs Library configuration information.
+
+If disk space is a problem, disabling debugging should greatly
+reduce object code, and therefore, library size. This is especially
+true with g++.
+
+Toshio Hori <toshi@etl.go.jp> provided these tips for reducing
+disk space usage:
+
+To save space on a Unix machine, I usually run
+ 'find . -name \*.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 Embarcadero C++
+Builder.)
+
+Finally, to save space, may want to run 'make clean' after 'make'. It
+removes generated object files and leaves libraries/executables
+intact. If you want to remove any of the libraries/executables, as
+well, try 'make realclean'.
+
+
+
+
+
General MPC information
+
+
+The
+Makefile Project Creator (MPC) is a tool that takes platform and
+building tool generic files (mpc files) as input, which describe basic
+information needed to generate a "project" file for various build
+tools, including Make, NMake, Visual C++ 6, Visual C++ 7, etc. Please
+see USAGE, README for documentation on MPC.
+
+
+
+A common usage for creating a Windows workspace containing just the
+core ACE and TAO libraries and executables is the following:
+
+
+
+C:> cd %TAO_ROOT%
+C:> %ACE_ROOT%\bin\mwc.pl -type vc71 TAO_ACE.mwc
+
+
+
+Replace vc71 with whatever project type you want to use. On Linux and
+other UNIX platform use the gnuace type:
+
+
+
+% cd $TAO_ROOT
+% $ACE_ROOT/bin/mwc.pl -type gnuace TAO_ACE.mwc
+
+
+
+This creates the appropriate GNUmakefiles. Additional information on
+how to obtain, configuration, and build ACE+TAO using MPC appear at
+the OCI FAQ.
+
+
+
+If you are attempting to generate project files using MPC, and you get
+the following error message:
+
+
+
ERROR: Unable to find the MPC modules in /builds/ACE_wrappers/MPC.
+You can set the MPC_ROOT environment variable to the location of MPC.
+
+
+
+You need to do one of the following:
+
+
+
+
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.
+
Check out MPC from the DOC Group git repository
+and set your MPC_ROOT environment variable.
+
+
+
+You can check
+out MPC from the DOCGroup git repository using the following command.
+
+The README and USAGE files in the MPC/docs directory are an up-to-date
+source of documentation, however it is not a complete set of
+documentation. The TAO Developer's Guide from OCI starting with the
+1.3a version contains more information about MPC.
+
+
+
+The MPC chapter from the TAO Developer's Guide is available at
+http://downloads.ociweb.com/MPC/. Some of MPC has changed since
+this version, but it is largely accurate. An updated version will be
+available as newer versions of the TAO Developer's Guide are released.
+In the meantime, please see the README and USAGE files in the MPC
+directory.
+
+The Eclipse CDT C++ development environment can be used to develop ACE applications. You can configure a new CDT project to build ACE using either a local source distribution or checking out ACE from CVS in Eclipse. These are the steps to create the CDT project to build ACE.
+
+
+
+
To create an Eclipse project for ACE starting from CVS:
+
+
In the "CVS Repository Exploring" perspective, navigate to the module containing ACE.
+
Checkout the module using "Check Out As" and select the "project configured using the New Project Wizard" option.
+
Select "Standard Make C++ Project" for the project type.
+
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.
+
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.
+
Select the root folder for the project and use the "Create Make Target" wizard to setup the appropriate make command and options.
+
Select the root folder and run "Build Make Target." This will build ACE.
+
+
+
+
+
+
+
To create an Eclipse project for ACE from a local source distribution:
+
+
Launch the "New Project Wizard" in Eclipse.
+
Select "Standard Make C++ Project" for the project type.
+
On the project name page, uncheck the "use default" location option and replace the default path with the path to your source distribution.
+
Follow the steps, up to the point of running make, for building ACE on your platform.
+
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.
+
Select the root folder for the project and use the "Create Make Target" wizard to setup the appropriate make command and options.
+
Select the root folder and run "Build Make Target." This will build ACE.
The ACE_Object_Manager can be instantiated
+as a static object, can be instantiated on the stack of the main
+program thread, or can be explicitly instantiated and destroyed by the
+application with ACE::init () and ACE::fini
+(). The comments in the header file,
+ace/Object_Manager.h, as well as Section 1.6.3 in
+The ACE Programmer's Guide
+provide more detail.
+
+
+Special requirements are imposed on applications if the
+ACE_Object_Manager is instantiated, by ACE, on the stack of the main
+thread. This behavior is selected by defining
+ACE_HAS_NONSTATIC_OBJECT_MANAGER in
+ace/config.h. Again, see the ACE Object_Manager header file,
+ace/Object_Manager.h for more information. One of
+these requirements is discussed here, because it is so important.
+Please note that ACE_HAS_NONSTATIC_OBJECT_MANAGER is
+defined in the distributed ACE config.h headers for
+VxWorks and Win32.
+
+The important requirement is that the program must
+declare its main function with two arguments, even if
+they're not used, and with int return type:
+
+
+int
+main (int, char *[])
+
+
+If you don't declare mainexactly that
+way, then you'll see a link error about ace_main_i being
+undefined.
+
+Alternatively, this feature can be disabled by commenting out the
+#define ACE_HAS_NONSTATIC_OBJECT_MANAGER in the
+ace/config.h. But, that will make repeated testing more
+difficult on VxWorks. And, you'd either have to call static
+constructors and destructors manually or unload/load the program
+between runs. On Win32, disabling the feature can possibly lead to
+shutdown difficulties.
+
+
+ACE_HAS_NONSTATIC_OBJECT_MANAGER assumes that your
+main function is named main. Any violation
+of this assumption is at your peril. If you really need to call your
+entry point something other than main, you'll need to
+construct and destroy the ACE_Object_Manager. The best way to do that
+is to call ACE::init () and ACE::fini ().
+Or, see the #define of main (int, char *[])
+in ace/OS_main.h to see how ACE does
+that for entry points named main.
+
+
+
+On UNIX platforms, we typically like to support multiple platform
+builds using the same ACE source tree. This idiom is supported by ACE
+using the $ACE_ROOT/bin/create_ace_build.pl script.
+
+To clone the source tree, create ./build and ./build/{your build name}
+subdirectories under the ACE_wrappers directory.
+Then invoke the create_ace_build.pl script to clone the source tree using
+soft links from your build directory back to the actual sources.
+Here is an example:
+
+
% cd ACE_wrappers
+% mkdir build build/build-SunOS5
+% perl bin/create_ace_build.pl -a -v build-SunOS5
+% cd build/build-SunOS5
+% setenv ACE_ROOT $cwd
+% make
+
+
+This will establish a complete tree of links. In addition, make sure
+you set your LD_LIBRARY_PATH to
+$ACE_ROOT/lib:$LD_LIBRARY_PATH on SVR4 UNIX
+platforms.
+
+When you do a make in the $ACE_ROOT directory you will be producing
+object code that is not stored in the same place as the original
+source tree. This way, you can easily build another platform in a
+parallel tree structure.
+
+See the comments at the top of the create_ace_build.pl script for
+further usage information.
+
+
+
+For all intents and purpose, MVS OpenEdition (OE) is another flavor of
+UNIX, therefore, the instructions under Building
+and Installing ACE on Unix can be used along with the following
+additional tips:
+
+You can get a copy of GNU make that has been ported to MVS OpenEdition from
+the IBM OpenEdition web site.
+ACE's make scheme generates compile commands that have options and
+operands interspersed. By default, the c89/cc/c++ compiler expects all options to
+precede all operands. To get around this, you must set a special
+compiler environment variable (_CXX_CCMODE) to 1 which tells the compiler
+to allow options and operands to be interspersed.
+
+Note that the environment variable LD_LIBRARY_PATH is
+called LIBPATH on MVS.
+
+Shared objects are built a little different on MVS than on
+other UNIX implementations. This has been accounted for in the makefiles
+that come with ACE When the linker (via the cxx command) builds the
+libACE.so file it will also create a file called libACE.x. This is a
+side-deck file and it must be included in subsequent link edits with
+application code. For more information on this see the C/C++ MVS
+Programming Guide. If you want to build your application statically,
+i.e., using libACE.a instead of libACE.so, you can set ACELIB to
+ACELIB_STATIC in platform_mvs.GNU.
+
+When the libACE.so file is built (via the MVS pre-linker and binder), you
+will get a rc=4 from the pre-linker. This is ok. This is due to some
+warnings about unresolved references which should get resolved during the
+link step. Note, however, there shouldn't be any unresolved references
+from the binder (linkage editor). You can get pre-link and link maps by
+uncommenting the PMAP and LMAP lines in the platform_mvs.GNU file.
+
+
+
+GNU make provides many options to customize its operation. See its
+documentation for more information. One example is that for multi-cpu
+UNIX machines you will be able to build faster if you use:
+
+
+% make -j n
+
+
+which allows parallel compilation. The number n should
+typically be the number of CPUs. It is likely that builds will be
+faster even on single-CPU UNIX machines with make -j
+2.
+
+ACE further supports the following flags. They can be enabled either
+on the command line, e.g., "make purify=1", or added to your
+platform_macros.GNU. To disable the option,
+set the flag to null,
+e.g., "make debug=". Some flags support setting to 0 disable, e.g.,
+"make debug=0". debug=1 is enabled in the platform files that are
+released with ACE.
+
+Please note that the effects of a flag may be platform specific.
+Also, combinations of certain flags may or may not be allowed on
+specific platforms, e.g., debug=1 opt=1 is supported by g++ but
+not all other C++ compilers.
+
+If you use Purify or Quantify: purify or quantify must
+be on your PATH. By default, ACE puts the Purify/Quantify
+caches below /tmp. To override that, set the
+PURE_CACHE_BASE_DIR variable, either in your environment
+or on the make make command line, to the destination
+directory for your instrumented libraries.
+
+
Flag Description
+---- -----------
+debug Enable debugging; see DCFLAGS and DCCFLAGS.
+exceptions Enable exception handling (not supported by all platforms).
+include_env Support old-style ACE_TRY_ENV declarations in methods.
+ This switch is necessary for compiling TAO applications
+ in the native exception configuration that were written
+ for TAO versions before 1.2.2.
+ In TAO 1.2.2, new macros were introduced that supercede
+ the direct ACE_TRY_ENV declarations. These are the
+ ACE_ENV_ARG macros that are defined in ace/CORBA_macros.h
+ and are documented in docs/exceptions.html.
+ This switch only affects the exceptions=1 configuration.
+ It is for backward compatibility only.
+ There will be warnings about unused _ACE_environment_variable
+ parameters when using include_env=1.
+ If possible, do not use it, but instead change your TAO
+ applications to use the ACE_ENV_ARG macros.
+fast Enable -fast option, e.g., with Sun C++.
+inline Enable ACE inlining. Some platforms enable inlining by
+ default, others do not.
+optimize Enable optimization; see OCFLAGS and OCCFLAGS.
+pace Enable PACE as the underpinnings of ACE_OS.
+probe Enable ACE_Timeprobes.
+profile Enable profiling; see PCFLAGS and PCCFLAGS.
+purify Purify all executables.
+quantify Quantify all executables.
+repo Use GNU template repository (g++ with repo patches only).
+rtti Enable run-time type identification. On some platforms,
+ it is enabled by default, so this is ignored.
+shared_libs If migrating from prior version use shared_libs_only
+static_libs If migrating from prior version use static_libs_only
+shared_libs_only Only build shared libraries. Ignored if no SHLIBs are
+ specified by the Makefile, as in performance-tests/Misc.
+static_libs_only Only build static libraries.
+threads Build with thread support.
+xt Build with Xt (X11 Toolkit) support.
+fl Build with FlTk (Fast Light Toolkit) support.
+tk Build with Tk (Tcl/Tk) support.
+qt Build with Qt (Trolltech Qt) support.
+ssl Build with OpenSSL support.
+rapi Build with RAPI
+split Build the library by first splitting up the ACE source
+ to several files, with one object code entity for each
+ source file. This allows an application that is linked
+ with ACE to extract _exactly_ what it needs from the
+ library, resulting in a smaller executable. Setting this
+ to 1 overrides debug to 0.
+
+Usually, users do not need to be concerned with make targets.
+Just enter "make" on the command line to build. A few notable
+targets are listed below.
+
+Target Description
+------ -----------
+show_statics Lists all static objects in object files built for
+ current directory. Only supported for g++.
+show_uninit Lists all uninitialized in object files built for
+ current directory. Only supported for g++.
+
+
+
+If users are building from our Git repository the
+GNUmakefiles, and project files for building on various platforms will
+not be available. Git users are expected to generate them
+using MPC before building ACE, TAO or
+CIAO. We point out some suggestions below to get bootstrapped
+quickly.
+
+
+
You can clone all code easily from our git repository.
+
Please make sure that you have
+ perl installed, preferably perl
+ 5.8 or higher. Users on Win32 based platforms are recommended to use
+ Active
+ State Perl or Strawberry Perl.
+ We use both perl versions without problems. We have
+ ran into problems trying to use the cygwin version of perl on Win32
+ based platforms.
+
+
+
To build ACE and associated tests, examples,
+ and associated utility libraries with GNUmakefiles, you must
+ generate GNUmakefiles with MPC:
+ $ACE_ROOT/bin/mwc.pl -type gnuace ACE.mwc
+
On Windows, with Visual Studio 2015, you must generate solution and project files with MPC:
+
+ $ACE_ROOT/bin/mwc.pl -type vc14 ACE.mwc
+
+ On Windows, with Visual Studio 2017, you must generate solution and project files with MPC:
+ $ACE_ROOT/bin/mwc.pl -type vs2017 ACE.mwc
+
+ On Windows, with Visual Studio 2019, you must generate solution and project files with MPC:
+ $ACE_ROOT/bin/mwc.pl -type vs2019 ACE.mwc
+
If you want to build TAO and its associated libraries
+ please see TAO-INSTALL for details.
+