Table of Contents
General Notes | |
|
New Features | |
Many important new features and bug fixes have been introduced in TAO 1.3a. They are described briefly here. These and many other features of TAO 1.3a are detailed in OCI's TAO Developer's Guide, Version 1.3a, available separately.
Many bugs have been fixed or work-arounds provided since TAO 1.2a. Here we highlight a few of the more important bug fixes since TAO 1.2a, focusing especially on fixes for bugs that could cause crashes, deadlocks, resource leakage, or race conditions. Each bug is referenced by a number as assigned by the DOC group Bugzilla bug database found at http://deuce.doc.wustl.edu/bugzilla/index.cgi.
* Bug 1020
(
http://deuce.doc.wustl.edu/bugzilla/show_bug.cgi?id=1020) deserves
special explanation. The problem, as described in the bug report, could
cause a multithreaded client with a connection to a server to crash if
the server died. A client thread, trying to send a request to the
server, may attempt to close the connection. Meanwhile, another
thread might awaken in the reactor and also attempt to close the
connection, resulting in a segmentation violation and crash.
The partial solution, designed and implemented by
Balachandran Natarajan, is similar in spirit to how the TCP
state machine models connection teardown. Connection closure in the
ORB is now modeled as an event that is handled through the ORB's
leader-followers mechanism. In addition, event handling along the
invocation path and along the connection handling path were separated
for better separation of concerns. A regression test,
|
Solaris | ||||||||||||||||||
All of the Solaris builds used the recommended OCI build flags in addition to the platform_macros.GNU and config.h files already set up for the SunOS platform and compiler. Files Used for SunOS Builds
Sun C++ Notes Use the fast=1 instead of optimize=1 for optimizing with Sun compilers because it selects a combination of compilation options for optimum execution speed. Other optimization levels may reduce the footprint, but do not have a corresponding flag in ACE/TAO.
Tests No ACE tests fail on any platform. A scattering of TAO tests fail, but no test/feature fails across platforms.
|
Linux | |||||||||||||||
All of the Red Hat builds used the recommended OCI build flags in addition to the platform_macros.GNU and config.h files already set up for the Linux platform and compiler.
Red Hat 7.x gcc 2.96 Notes
|
Windows | ||||||||||||||
All of the Windows builds used the recommended OCI build flags in a config.h file as shown below. Files Used for Windows Builds
We also test infrequently using a wider variety compilers. Various combinations of the following. We're reasonably sure that most sensible versions of the following will work correctly, but we can't guarantee a configuration unless we test it regularly. Operating Systems
Compilers
Libraries
The following config.h file is used for all Windows nightly builds.
// contents of config.h #define ACE_DISABLE_WIN32_ERROR_WINDOWS #define ACE_HAS_STANDARD_CPP_LIBRARY 1 #include "config-win32.h" The first line disables the popup of error windows when running the automated tests. It is not normally needed for ordinary user programs. It would only be used if an automated build was being done. The platform_macros.GNU file is not used for Windows platforms.
Compile Notes
Execution Notes
create_ace_build.pl You can now use this perl script to set up a build for ACE/TAO, so that multiple builds can share a single code base (this is a new feature with 1.3a). You must run this command from within the ACE_wrappers directory, and ACE_wrappers\bin should be in your path. Example: create_ace_build.pl vc71Running this command will create a directory called ACE_wrappers\builds\vc71. Most of the directory structure under ACE_wrappers will be duplicated under this directory, and hard links will be created back to the files under ACE_wrappers. For example, if you modify ACE_wrappers\ace\OS.h, then ACE_wrappers\builds\vc71\ace\OS.h will automatically be modified. Windows does not support symbolic links, so that if you delete a file, it will not automatically be deleted. If you then add a new file with the same name as the old one, it will not be linked. To refresh your links in this case, you can run create_ace_build.pl without any options, and it will update all links for every build. You can set up as many builds as you want by simply running the script again with a different argument. By default, it's assumed that you will use MPC to generate any project files for the new build, so no project files or Makefiles are linked from ACE_wrappers.
Tests A scattering of ACE and TAO tests fail, but no test/feature fails across platforms. In addition, the notify service will not load when building release mode Borland 5.5. (This will likely be fixed in a subsequent patch release.)
|
Tru64 | ||||||
The Tru64 builds used the recommended OCI build flags in addition to the platform_macros.GNU and config.h files already set up for the Tru64 platform and compiler. Files Used for Tru64 Builds
In addition The default ulimits on these platform are not sufficient to build TAO. The problem is the virtual memory limits, vmemory and data must be increased to the maximum allowed. For us, this is vmemory=4194304 and data=1048576. In addition the operating system must be configured to have larger limits for semaphore operations. ipc: sem_mni = 250 sem_msl = 125 sem_opm = 100 sem_ume = 100
CXX Notes There is a problem with the Naming Service when built with Compaq C++ compilers and optimization. The source in question is Bindings_Iterator_T.cpp and the modules that use this are Persistent_Naming_Context.o and Transient_Naming_Context.o in library libTAO_CosNaming.so. The problem exists on C++ V6.2 to V6.5 and on UNIX 5.1 and 4.0F. The problem occurs at all optimization levels from O1 through O4. It is unknown when a fix will be available
Tests 2 ACE tests fail
|
AIX | ||||||
All of the AIX builds used the recommended OCI build flags OCI build flags in addition to the platform_macros.GNU and config.h files already set up for the AIX platform and compiler.
When using GNU Make that is part of AIX toolbox for Linux applications, it may be necessary to modify the file access permissions of the make executable to ensure the LIBPATH environment variable is propagated to make system properly. This can be done as follows: chmod 755 /opt/freeware/bin/make See this message for further information. Files Used for AIX Builds
NOTE: The preprocessor for VA C++ 5 does not function correctly when used by tao_idl. Therefore, the GNU Preprocessor was used for tao_idl by setting TAO_IDL_PREPROCESSOR=g++ in platform_macros.GNU.
Tests No ACE tests fail on this platform. The AVStreams tests are known not to work on this platform.
|
HP-UX | |||||||||
All of the HPUX builds used the recommended OCI build flags OCI build flags in addition to the platform_macros.GNU and config.h files already set up for the HPUX platform and compiler. Files Used for HPUX Builds
Tests No ACE tests fail on HP-UX 11.00. The ACE Multicast_Test fails on HPUX 11.20 due to platform implementation differences. The TAO RTCORBA tests fail due to lack of support for the HP-UX thread priorities.
|
Irix | ||||||
The SGI IRIX build used the recommended OCI build flags in addition to the platform_macros.GNU and config.h files already set up for the IRIX platform and compiler. Files Used for IRIX Builds
Tests
The ACE Multicast test fails due to platform implementation differences.
A few TAO tests fail. In many cases this is due to a possible bug in the
way the compiler deals with exceptions.
For one test,
|
MACOSX | ||||||
All of the MACOSX builds used the recommended OCI build flags in addition to revised platform_macros.GNU and config.h files developed for the MACOSX platform and compiler. Files Used for MACOSX Builds
In addition The Apple Developer Kit Dec 2002 is required and two additional packages will have to be loaded from open source available on the net.
Notes The major problem with getting TAO to run on MACOSX was lack of full initialization of static objects. About half of the tests were failing. Apple is aware of the problem, but a fix does not appear to be imminent. Seems to be somewhat difficult problem with some legacy implications. Thus, for ACE/TAO the Mac will not be supportable for any earlier versions than 1.3a of ACE/TAO and 10.2.x of MACOSX. There are three or four environment variables that are required to be defined in the user's environment.
And, if you are building ACE/TAO and wish to run the tests,
Tests 2 ACE tests fail
|
VxWorks | ||||||
The VxWorks builds used the recommended OCI build flags with static libraries only and no exceptions in addition to the platform_macros.GNU and config.h files already set up for the VxWorks platform and compiler. Files Used for VxWorks Builds
The build was cross-compiled on a Solaris platform for a PPC 604 target. A cross-compile using Windows for a PPC 604 target has also been done. Build Notes The VxWorks build was for static libraries only, since that is the most common use on this platform. Also, the build was without native exceptions again, since that is the most common. This build also uses "#define ACE_HAS_EXPLICIT_TEMPLATE_INSTANTIATION" in its config.h since it was found that implicit template instantiation does not work in all cases. Not all of the orbsvcs and orbsvcs tests will build on VxWorks. Tests Basic ACE and TAO tests work on VxWorks.
|
Others | |
These are platforms for which some amount of work has been done. This does not mean that these platforms are fully supported, only that they may be usable in circumstances similar to those in which they were tested. The 5.3a version of ACE has been built and tested with the Green Hills tool kits versions 3.5 and 4.0 on both Solaris for Solaris, Solaris for VxWorks, and Linux for Linux. The 1.3a version of ACE/TAO has been built with the Green Hills Integrity toolkit 4.0 running on Windows for the Green Hills Integrity OS. Green Hills Integrity is a fairly new Real-Time OS for embedded systems. As such, systems on which it runs are generally limited in the resources which they can provide. For example, the system on which we tested was very limited in memory, so very little of the standard tests could be run.
|
BuildFlags | |||||||||||||||||||||||||||||||
If you're doing your own build, you can have the following flags set which OCI uses in its own builds. For UNIX and UNIX-like platforms that use GNU Make, use platform_macros.GNU. For Windows/Visual C++ builds, use config.h. If an option is not listed below, let it default. Turned on:
Turned off:
Variable--dependent on platform and other settings:
For Windows OnlyUse the macros to set things up in a config.h file.
For Windows 95/98, add #define ACE_HAS_WINNT4 0for additional information see http://www.theaceorb.com/faq/index.html#012
|