diff --git a/icu4c/readme.html b/icu4c/readme.html index 7e2549be81..7417140f1a 100644 --- a/icu4c/readme.html +++ b/icu4c/readme.html @@ -31,10 +31,10 @@
Version: 2006-Aug-31
+
Version: 2006-Oct-20
Copyright © 1997-2006 International Business Machines Corporation and
others. All Rights Reserved.
You can install ICU on z/OS or OS/390 (the previous name of z/OS), but IBM - tests only the z/OS installation. These platforms commonly are called "MVS". - You install ICU in a z/OS UNIX system services file system such as HFS or - zFS. On this platform, it is important that you understand a few details:
+ tests only the z/OS installation. You install ICU in a z/OS UNIX system + services file system such as HFS or zFS. On this platform, it is important + that you understand a few details:z/OS introduced the concept of Extra Performance Linkage (XPLINK) to
- bring performance improvement opportunities to call-intensive C and C++
- applications such as ICU. XPLINK is enabled on a DLL-by-DLL basis, so if
- you are considering using XPLINK in your application that uses ICU, you
- should consider building the XPLINK-enabled version of ICU. You need to
- set ICU's environment variable OS390_XPLINK=1
prior to
- invoking the make process to produce binaries that are enabled for
- XPLINK.
Note: XPLINK, which is enabled for z/OS 1.2 and later, requires the - PTF PQ69418 to build XPLINK enabled binaries.
-OS390_XPLINK=1
prior to
+ invoking the make process to produce binaries that are enabled for
+ XPLINK. The XPLINK option, which is available for z/OS 1.2 and later,
+ requires the PTF PQ69418 to build XPLINK enabled binaries.When you build ICU on a system such as z/OS 1.2, the binaries that - result can run on that level of the operating system and later, such as - z/OS 1.3 and z/OS 1.4. It's possible that you may have a z/OS 1.4 system, - but you may need to deliver binaries on z/OS 1.2 and above. z/OS gives - you this ability by targeting the complier and linker to run at the older - level, thereby producing the desired binaries.
- -To set the compiler and LE environment to OS/390 2.10, specify the
- following, "./runConfigureICU OS390V2R10
"
To set the compiler and LE environment to z/OS 1.2 specify the
- following, "./runConfigureICU zOSV1R2
"
ICU's tests use usleep()
, which is multithread unsafe on
- versions of Solaris before version 9. This does not mean that ICU is not
- thread safe because only ICU's test code uses usleep()
. The
- sleep()
and nanosleep()
functions could be used in
- ICU's multithreaded tests, but sleep()
and
- nanosleep()
are not a stable API between versions of Solaris.
- Solaris 9 fixes usleep so that it is multithread safe.
This hanging behavior tends to appear on multi-CPU machines. Single CPU - Solaris 8 machines do not seem to show this behavior.
- -In a future version of ICU, we hope to find a portable solution to this - problem that will work between the modern versions of Solaris.
- -Solaris 8, and earlier, has outstanding thread deadlocking issues that - may be problematic for applications using either native, or - POSIX, threading on these platforms. Sun states that Solaris 9 does - not have the deadlock problems. Deadlocks may occur - either during initialization of the Solaris threading library, or at any - other time.
- -Sun Microsystems has provided a Sun Alert Notification regarding the - issue. Users should consider applying the latest OS patches - to their Solaris installations in order to help avoid deadlock. Further - information regarding the issue, and links to applicable patches, may be - found at:
- -[1] "Applications Linked to libthread May Hang", Sun Alert
- Notification, Sun Microsystems, Inc., 04-Sep-2002
- http://sunsolve.sun.com/search/document.do?assetkey=1-26-46867
Sun is not providing patches for Solaris 6 (2.6), or - earlier.
- -Sun states that by applying the patch users will avoid the deadlock - issues. However, with all applicable patches applied, deadlock - may still be seen, as demonstrated by the ICU Mutex unit - tests. The unit test will hang indefinitely. No bug exists in ICU. However, a - latent bug still exists in Solaris, which Sun Microsystems has yet to - resolve. In order to avoid this, users are suggested to - modify their LD_LIBRARY_PATH according to the guidelines specified by Sun - Microsystems in the Sun Alert Notification.
-In order to avoid synchronization and threading issues, developers are @@ -1625,10 +1543,10 @@ ADDENVVAR ENVVAR(OUTPUTDIR) VALUE('libraryname')
Failure to do this may cause spurious lock conflicts, recursive mutex failure, and deadlock.
-[2] "Solaris Multithreaded Programming Guide, Compiling and +
Source: "Solaris Multithreaded Programming Guide, Compiling and
Debugging", Sun Microsystems, Inc., Apr 2004
http://docs.sun.com/db/doc/806-6867/6jfpgdcob?a=view
Windows 2000/XP: Use the System Icon in the Control + Panel. Pick the "Advanced" tab. Select the "Environment Variables..." + button. Select the variable PATH in the lower box, and select the lower + "Edit..." button. In the "Variable Value" box, append the string + ";<ICU>\bin" to the end of the path string. If there is + nothing there, just type in "<ICU>\bin". Click the Set button, + then the OK button.
Note: When packaging a Windows application for distribution and installation on user systems, copies of the ICU DLLs should be included with @@ -1721,8 +1633,8 @@ ADDENVVAR ENVVAR(OUTPUTDIR) VALUE('libraryname') User Guide ICU Data chapter.
-ICU 2.8 removes the requirement that ICU be completely built in the native - operating environment. It adds the icuswap tool which can be run on any +
ICU 3.6 removes the requirement that ICU be completely built in the native + operating environment. It adds the icupkg tool which can be run on any platform to turn binary ICU data files from any one of the three formats into any one of the other data formats. This allows a application to use ICU data built anywhere to be used for any other target platform.
@@ -1772,14 +1684,12 @@ ADDENVVAR ENVVAR(OUTPUTDIR) VALUE('libraryname')