Re: [Stlport-devel] proofreading documentation [+patch]

[<fra...@fr...>]

Hi Ulrich

    It has been a long time since we hear from you.

    I haven't thought about announcement on clc++ forum, go ahead, no 
problem about it, it is even the opposite. I really would like to see 
more people gicing idea for STLport moreover there is the tr1 spec that 
we ahevn't work on yet.

    Have you also try latest CVS version. Once again we did big 
modification, especially in internal configuration, I don't remember 
having heard a report of a EVC++ user about that. Other major modif are:
- node and per thread allocator are now only available when building lib
- lock free node allocator has been fixed and is anable for Windows 
platform (32/64 bits) and for Linux (32 bits)
- I just add predicate check in _STLP_DEBUG mode, not yet complete but 
already effective for sorting algorithm.
- Borland support restored

Bests


Ulrich Eckhardt wrote:
> Hi Fellows!
>
> I'm currently trying to get up to speed on the current STLport and I'm really 
> impressed. It builds straight out of the box for eVC4. BTW: why didn't anyone 
> announce the release of 5.0.0 on clc++[m]? I would have done so myself but 
> first wanted to check if that was not possibly a conscious decision.
>
> Concerning the current release, I'm still having a few problems with the 
> unittests, one being that the MIPS compiler generates ICEs in release mode, 
> the other possibly being related to a bug in our SDK, but with just a single 
> patch (not included here yet) all my programs work fine.
>
> Anyhow, after downloading the current release, I went over the docs and 
> created the attached patch. Mostly, the corrections there are spelling 
> mistakes or grammatical mistakes, so it's nothing serious.
>
> cheers
>
> Uli
>   
> ------------------------------------------------------------------------
>
> Index: build/lib/README.options
> ===================================================================
> --- build/lib/README.options	(revision 938)
> +++ build/lib/README.options	(working copy)
> @@ -21,7 +21,7 @@
>  
>   impact:
>  
> -	It hasn't been quantify and highly depends on the way you use
> +	It hasn't been quantified and highly depends on the way you use
>  it. If you have specialised the boost::type_traits struct for all the
>  types you are using to instanciate the STL containers it might be a 
>  very important feature. Otherwise you will have to count on the boost
> @@ -53,7 +53,7 @@
>   impact:
>  
>  	Most of the time people are using this feature to avoid 
> -distribution of the STLport dll. So they link their numerous dll 
> +distribution of the STLport dll. So they link their numerous dlls 
>  with the static version of the STLport library but keep the dynamic
>  native runtime. Such a configuration might be dangerous. For instance
>  if you have always the same dll allocating memory and an other one 
> Index: doc/evc_workaround.txt
> ===================================================================
> --- doc/evc_workaround.txt	(revision 938)
> +++ doc/evc_workaround.txt	(working copy)
> @@ -1,4 +1,4 @@
> -This document describes the workaround for the resource_compiler on MS Windows
> +This document describes the workaround for the resource compiler on MS Windows
>  
>  
>  The resource compiler is not a C++ compiler, it is a compiler that translates
> Index: doc/FAQ
> ===================================================================
> --- doc/FAQ	(revision 938)
> +++ doc/FAQ	(working copy)
> @@ -3,15 +3,15 @@
>  Q1 About STLport and availability
>  
>  Q1.0 What is STLport?
> -Q1.1 What is benefits from using STLport?
> -Q1.2 What versions of STLport available?
> +Q1.1 What are the benefits from using STLport?
> +Q1.2 What versions of STLport are available?
>  
>  Q2 General
>  
>  Q2.0 Do I need a C++ compiler?
>  Q2.1 Do I need runtime libraries from C++ compiler?
>  Q2.2 Can I use containers and algorithms from STLport and iostreams from
> -library that shipout with compiler?
> +library that ship with my compiler?
>  Q2.3 Can I mix STL implementations in my project?
>  Q2.4 When I switch to STLport in my application, I get errors. Is STLport
>  so bad?
> @@ -22,7 +22,7 @@
>  are looked for in /usr/include/3.3.1. Is it a STLport bug?
>  Q3.1 Do I need to build library to use STLport?
>  Q3.2 During library compilation with MS VC++ 6.0 I see following error report:...
> -Q3.3 Does anybody success in building STLport on OS Y with compiler K n.n?
> +Q3.3 Has anybody succeeded building STLport on OS Y with compiler K n.n?
>  Q3.4 Does STLport support cross-compilation?
>  
>  Q4 Installation
> @@ -37,11 +37,11 @@
>  
>  Q6 Design
>  
> -Q6.0 In STLport present files like locale.h, setjmp.h, stdlib.h, etc.,
> -that do nothing except include native headers. Why this files present in STLport?
> +Q6.0 In STLport, files like locale.h, setjmp.h, stdlib.h, etc.,
> +do nothing except include native headers. Why are these files present in STLport?
>  Q6.1 Is STLport a replacement for headers and libraries that shipout
>  with compiler?
> -Q6.2 My tool detect memory leaks in application with STLport. Is this leak
> +Q6.2 My tool detects memory leaks in applications with STLport. Is this leak
>  from STLport?
>  
>                             Answers
> @@ -49,16 +49,16 @@
>  ========================================================================
>  
>  Q1.0 What is STLport?
> -A1.0 STLport is implementation of C++ Standard Library, as described in
> -the INTERNATIONAL STANDARD ISO/IEC 14882:1998(E) and latest
> +A1.0 STLport is an implementation of the C++ Standard Library, as described 
> +in the INTERNATIONAL STANDARD ISO/IEC 14882:1998(E) and latest
>  ISO/IEC 14882:2003(E).
>  
>  ========================================================================
>  
> -Q1.1 What is benefits from using STLport?
> +Q1.1 What are the benefits from using STLport?
>  
>  A1.1
> -  - For multiplatform/multicompilers project a coherent Standard library
> +  - For multiplatform/multicompilers project a coherent Standard Library
>  implementation.
>    - An easy to use STL safe mode detecting bad use of containers and
>  iterators.
> @@ -68,7 +68,7 @@
>  
>  ========================================================================
>  
> -Q1.2 What versions of STLport available?
> +Q1.2 What versions of STLport are available?
>  
>  A1.2
>  
> @@ -76,20 +76,20 @@
>  
>  Q2.0 Do I need a C++ compiler?
>  
> -A2.0 STLport is a C++ library. So answer is 'yes, you need'.
> +A2.0 STLport is a C++ library. So the answer is 'yes, you do'.
>  
>  ========================================================================
>  
>  Q2.1 Do I need runtime libraries from C++ compiler?
>  
> -A2.1 In any case C++ language support from compiler is required
> +A2.1 In any case, the C++ language support from compiler is required
>  for STLport (operators new, delete, RTTI, exceptions support). That's why
> -in most cases you need some runtime libraries from C++ compiler.
> +in most cases you need some runtime libraries from the C++ compiler.
>  
>  ========================================================================
>  
>  Q2.2 Can I use containers and algorithms from STLport and iostreams from
> -library that shipout with compiler?
> +the library that ships with my compiler?
>  
>  A2.2 This is a case of STL implementations mix. See A2.3 below.
>  
> @@ -124,7 +124,7 @@
>  did not tried to find functions in the namespaces where arguments' classes
>  are defined (indeed no compilers with full-featured support of ADL yet).
>  
> -Mix imlementation via library.
> +Mix implementation via library.
>  
>  Let's reduce all the complexity of STLport to some very simple example:
>  
> @@ -218,7 +218,7 @@
>  call a.push, or on assignment _str = s. This is evident here, but not
>  evident in real applications.
>  
> -The conclusion is: "Using Wrapper mode is very hard and we remove support
> +The conclusion is: "Using Wrapper mode is very hard and we removed support
>  for it".
>  
>  ========================================================================
> @@ -226,17 +226,16 @@
>  Q2.4 When I switch to STLport in my application, I get errors. Is STLport
>  so bad?
>  
> -A2.4 Before you post such message, please, check the STLport WHITHOUT
> -YOUR errors:
> +A2.4 Before you post such message, please, check STLport WHITHOUT YOUR code:
>    - build STLport library
>    - build STLport unit tests
>    - run STLport unit tests
> -If any of above steps fail, please, check you carefully follow
> -build instructions report (in most cases you definitely should reread
> +If any of above steps fail, please, make sure that you carefully followed
> +build instructions (in most cases you definitely should reread
>  instructions and check that you correctly unpack archive in case you see
>  'file not found' message). Build instructions you can found in files
>  INSTALL, doc/README.*, build/README*, build/test/unit/README*.
> -If you sure, submit bug report here:
> +If you are sure, submit bug report here:
>  https://sourceforge.net/projects/stlport
>  Don't forget to describe you operational environment, compiler version and
>  STLport version.
> @@ -246,8 +245,8 @@
>  Q3.0 On my XXXX Linux n.n g++ headers are in /usr/include/g++, but they
>  are looked for in /usr/include/3.3.1. Is it a STLport bug?
>  
> -A3.0 Path to native compiler headers for gcc correspond to default path
> -after build/install compiler (i.e. pathes from compiler origo).
> +A3.0 Path to native compiler headers for GCC correspond to default path
> +after build/install compiler (i.e. paths from compiler origo).
>  Package maintainers can use any path by own taste---we can't satisfy
>  variety of distributions/packages.
>  
> @@ -259,7 +258,7 @@
>  
>  ========================================================================
>  
> -Q3.1 Do I need to build library to use STLport?
> +Q3.1 Do I need to build a library to use STLport?
>  
>  A3.1 You may omit usage (and, thus building) STLport library, but in this
>  case you can't use iostreams, locale, complex.
> @@ -278,11 +277,12 @@
>  A3.2 You have a Platform SDK installed. Uncomment line
>  #define _STLP_NEW_PLATFORM_SDK 1
>  in the file stlport/stl_user_config.h. There is no way to detect SDK
> -presence during preprocessor stage.
> +presence during preprocessor stage, which is why you have to make this
> +change manually.
>  
>  ========================================================================
>  
> -Q3.3 Does anybody success in building STLport on OS S with compiler K n.n?
> +Q3.3 Has anybody succeeded building STLport on OS S with compiler K n.n?
>  
>  A3.3 See report about results of regression tests here: build/test/unit/STATUS.
>  
> @@ -290,23 +290,23 @@
>  
>  Q3.4 Does STLport support cross-compilation?
>  
> -A3.4 In case of gcc, use something like following sequence:
> +A3.4 In case of GCC, use something like following sequence:
>  
>    (cd build/lib; ./configure --target=${CROSSTARGET}; \
>       export PATH=${BASECROSS}/bin:${PATH}; make -f gcc.mak install-release-shared)
>  
> -where CROSSTARGET is gcc's cross prefix (something like 'i586-pc-linux-gnu',
> +where CROSSTARGET is GCC's cross prefix (something like 'i586-pc-linux-gnu',
>  if C++ cross compiler named as 'i586-pc-linux-gnu-c++'), BASECROSS is base of
>  cross-compiler's location (i.e. ${BASECROSS}/bin in case above is a location
>  of 'i586-pc-linux-gnu-c++').
>  
> -In case of non-gcc crosses, we need hands-made target system identification.
> +In case of non-GCC crossecompilers, we need hands-made target system identification.
>  The sample of such compiler (supported by STLport) is MetroWerks Codewarrior
>  for Novell Netware (mwccnlm).
>  
>  ========================================================================
>  
> -Q4.1 I tried "make -f gcc.mak install", but it install nothing into
> +Q4.1 I tried "make -f gcc.mak install", but it installs nothing into
>  /usr/local/. How I can install headers into /usr/local/include and
>  libs into /usr/local/lib?
>  
> @@ -328,16 +328,16 @@
>  Q5.0 I found a bug, how I can report about it?
>  
>  A5.0 
> -  0. Ensure that this is a really bug (standard violation, incorrect
> +  0. Ensure that this is really a bug (standard violation, incorrect
>       behaviour with correct usage).
>    1. Ensure that bug is in STLport, not in your code (you can use _STLP_DEBUG
>       for that, see stlport/stl_user_config.h).
> -  2. Ensure that you correctly build STLport---build and run unit tests
> +  2. Ensure that you correctly built STLport---build and run unit tests
>       (build/test/unit) first with default settings, then with your settings
> -     (if you change ones).
> -  3. Write short test that demonstrate this bug.
> -  4. Make sure that this test case really new, i.e. not covered by unit tests
> -     (test/unit/*).
> +     (if you changed any).
> +  3. Write a short test that demonstrates the bug.
> +  4. Make sure that this test case is really new, i.e. not covered by unit 
> +     tests (test/unit/*).
>    5. Compare your results with reported runs of unit tests (build/test/unit/STATUS).
>    6. Write bug description and test here
>       
> @@ -350,13 +350,13 @@
>         - STLPORT VERSION
>         - RESULT OF UNIT TESTS
>  
> -     Keep in mind, that bug MUST be reproduced by other people, so give
> +     Keep in mind, that your bug MUST be reproduced by other people, so give
>       enough information (but compactly, give only essential information).
>  
>  ========================================================================
>  
> -Q6.0 In STLport present files like locale.h, setjmp.h, stdlib.h, etc.,
> -that do nothing except include native headers. Why this files present in STLport?
> +Q6.0 In STLport files like locale.h, setjmp.h, stdlib.h, etc., do 
> +nothing except include native headers. Why are these files present in STLport?
>  
>  A6.0 Sometimes native C headers was using C++ one or was refering
>  to the std namespace. That's why, if stddef whould absent in STLport, then
> @@ -382,22 +382,23 @@
>  
>  A6.1 In general no. In any case C++ language support from compiler is required
>  for STLport (operators new, delete, RTTI, exceptions support). STLport also
> -use 'native' headers and libraries to take interface to system functions and
> +uses 'native' headers and libraries to take interface to system functions and
>  variables.
>  
>  ========================================================================
>  
> -Q6.2 My tool detect memory leaks in application with STLport. Is this leak
> +Q6.2 My tool detects memory leaks in application with STLport. Is this leak
>  from STLport?
>  
> -A6.2 In most cases this are 'pseudo memory leaks' that some tools wrongly
> -supports.
> +A6.2 In most cases these are 'pseudo memory leaks' that some tools 
> +wrongly detect.
>  
>  In the default compile of STLport, the node allocator is used to allocate
>  internal memory. The node allocator works by pre-allocating a large chunk of
> -memory and handing out small memory blocks out. The memory chunk is not freed
> -during running an application that uses STLport (i.e. it don't returned to system,
> -but reused inside application). See also http://www.sgi.com/tech/stl/alloc.html
> +memory and handing out small memory blocks. The memory chunk is not freed
> +during running an application that uses STLport (i.e. it is not returned to 
> +the system, but reused inside application). 
> +See also http://www.sgi.com/tech/stl/alloc.html
>  
>  There are tools like BoundsChecker, Purify or Valgrind that check for memory
>  leaks, for memory that isn't freed when no longer used. These tools may report
> @@ -408,8 +409,8 @@
>  uses STLport internally and are statically link to it. If memory is allocated in
>  a dll and released in an other then the STLport node allocator will keep the
>  released memory for a future use. If you do not use this memory then your
> -application global memory consumtion will grow until the appli crash even if there
> -is no realy memory leak. This is why you should always use a coherent configuration
> +application global memory consumtion will grow until the app crash even if there
> +is no real memory leak. This is why you should always use a coherent configuration
>  everything in dll or everything in static lib.
>  
>  There are ways to remove the pseudo memory leaks (since the memory is properly
> Index: doc/README.evc4
> ===================================================================
> --- doc/README.evc4	(revision 938)
> +++ doc/README.evc4	(working copy)
> @@ -19,13 +19,14 @@
>  =============
>  To build and use the STLport you will need following tools and libraries:
>   - eMbedded Visual C++ 4.0 SP4
> - - Microsoft RTTI patch, to enable C++ exception handling, available at http://support.microsoft.com/default.aspx?scid=kb;[LN];830482
> - - lastest CVS version of the STLport, use info from page 'http://stlport.sourceforge.net/CVS.shtml' to get it
> + - an SDK for your target platform with RTTI support
>  
>  ================
>  Building STLport
>  ================
> -First, make sure that the RTTI patch is properly installed if required for your SDK - not all SDKs come without builtin support for C++ RTTI.
> +First, make sure that RTTI is available. Not all SDKs that come with eVC4 also include
> +the necessary libs, but there is a patch for the PPC2003 SDK, available at
> +http://support.microsoft.com/default.aspx?scid=kb;[LN];830482. 
>  
>  Second, open command line and set proper system variables.
>  This can be done by using batch files under your 'eMbedded Visual C++' directory(use either WCEemulator.BAT if you want to build STLport for the emulator or WCEARMV4.BAT if you intend to aim an ARM device).
> @@ -40,7 +41,9 @@
>  If anything goes wrong check if you met all prerequisities and if you set system vars accordingly to the makfile you are using.
>  At the end of build process you should have some libs installed in STLport/lib/evc4-arm or STLport/lib/evc4-x86 and dynamic libs in STLport/bin directory.
>  
> -You might want to repeat all those steps if you would like to have both ARM and x86 emulator binaries, just don't forget to do 'nmake /f nmake-evc4.mak clobber' before new build.
> +You might want to repeat all those steps if you would like to have 
> +e.g. both ARM and x86 emulator binaries, just don't forget to do 
> +'nmake /f nmake-evc4.mak clobber' before new build.
>  
>  Note: MIPS platform is also available for build, but it may not compile or work properly. Use with caution!
>  
> @@ -50,7 +53,7 @@
>  When you successfuly build STLport libs, you should go to STLport/test/unit directory build and run the STLP test suite.
>  Use 'nmake /f nmake-evc4.mak' and keep in mind that you still have to have proper system variables set!
>  Once test build has finished upload and run stlp_unit_test.exe to your emulator or device.
> -Wait for a while (aprox. 2mins) untill all tests are done.
> +Wait for a while (aprox. 2mins) until all tests are done.
>  You should see two files next to your binary now.
>  Check stlp_test.txt for any errors. If all tests passed you are ready to deploy STLport.
>  If some test fails don't worry and check the STLport forum if it's already reported bug or you have found a new one.
> @@ -58,12 +61,14 @@
>  =============
>  Using STLport
>  =============
> +Setting up the IDE:
>  Before you start using STLport you have to set proper include and libraries search paths.
>  Go to 'Tools'>'Options' menu in your eVC 4.0 and then to 'Directories' tab.
>  For every platform you want to use STLport add STLport/stlport directory to the FIRST place in 'Include Files'
>  and STLport/lib directory in 'Library files' section.
> +
> +Setting up projects:
>  When using STLport together with MFC, you have to define _STLP_USE_MFC to properly include and use STLport.
> -Now you should be ready to use STLport.
>  
>  By default, exception support is not activated. You can detect this via _CPPUNWIND and activate this via /GX.
>  Without exception support, e.g. std::bad_alloc is not available, causing compile errors for some code.
> @@ -75,4 +80,5 @@
>  ============
>  Known issues
>  ============
> -none
> +- The compilers that come with eVC4 are almost bug-to-bug compatible with 
> +the one from VC6, so most workarounds for that compiler apply here, too.
> Index: doc/README.msvc
> ===================================================================
> --- doc/README.msvc	(revision 938)
> +++ doc/README.msvc	(working copy)
> @@ -25,7 +25,7 @@
>  ===================
>  Configuring STLport
>  ===================
> -This is an optionnal step for the MSVC++ compilers, if you don't want to pass
> +This is an optional step for the MSVC++ compilers, if you don't want to pass
>  throught it just move to the 'Building STLport' section.
>  
>  Go to the STLport build/lib folder. Run
> @@ -58,11 +58,11 @@
>  5. Run the following command:
>  	nmake /fnmake-vc6.mak install
>  
> -	nmake is the make utility from microsoft. /f is an nmake option
> +	nmake is the make utility from Microsoft. /f is an nmake option
>  telling it which make file script to use. You have of course to grant the 
>  closer make file to your effective compiler.
>  
> -	Once the command return you will have all the necessary libraries within
> +	Once the command returns, you will have all the necessary libraries within
>  the STLport lib folder. For a description of the generated libraries check the README
>  file within the src folder. You can also set special make process options, you will 
>  find a list of those in the README.options file once again in the build/lib folder.
> Index: doc/stlport_namespaces.txt
> ===================================================================
> --- doc/stlport_namespaces.txt	(revision 938)
> +++ doc/stlport_namespaces.txt	(working copy)
> @@ -74,9 +74,9 @@
>  to native headers. If you include a C++ native headers that indirectly define for instance
>  the vector class it is going to conflict with the STLport vector definition.
>  
> -  Moreover this solution just do not work for a very simple reason. C++ Standard allow users
> -to specialized some of the Standard algorithm. This specialization has to be done in the
> -same namespace as the main template declaration:
> +  Moreover this solution just does not work for a very simple reason. The C++ Standard 
> +allows users to specialized some of the Standard algorithms. This specialization has to 
> +be done in the same namespace as the main template declaration:
>  
>  //In an STLport header:
>  namespace stlport
> Index: INSTALL
> ===================================================================
> --- INSTALL	(revision 938)
> +++ INSTALL	(working copy)
> @@ -1,5 +1,5 @@
>  **********************************************************************
> -* 	INSTALL file for STLport 5.0                                 *
> +* 	INSTALL file for STLport 5.0                                   *
>  *                                                                    *
>  **********************************************************************
>  
> @@ -81,7 +81,7 @@
>          make -f sunpro.mak clean install
>  
>  
> -    Note: 'install' taget work slightly different from ordinal---it installs libraries into
> +    Note: 'install' target work slightly different than usual - it installs libraries into
>      <STLport root dir>/lib and bin catalog, NOT IN SYSTEM CATALOG. You can do the system
>      install by just copying stlport and lib folder to the destination of your choise. For
>      example on UNIX-like platforms this can be done with the following commands:
> @@ -94,15 +94,15 @@
>        chown -R root:root /usr/local/lib/libstlport*
>        exit
>  
> -    Note: System install is optionnal, most of compilers/linkers support searching for includes
> -    and libs throught out the whole filesystem, just check your documentation on how to acheive
> +    Note: System install is optional, most of compilers/linkers support searching for includes
> +    and libs throught out the whole filesystem, just check your documentation on how to achieve
>      this.
>  
> -    If you use cross-compiler, you can find libraries in the <STLport root dir>/lib/<taget platform>
> +    If you use cross-compiler, you can find libraries in the <STLport root dir>/lib/<target platform>
>      catalog.
>  
>  6)  If build fails, you may choose to :
> -     - try fixing the build ;
> +     - try fixing the build ;)
>       - wait until somebody else will submit corresponding changes to be incorporated in next STLport 
>         release/snapshot.
>  
> @@ -134,25 +134,30 @@
>  8) Supply the "lib" subdirectory to the library search path and add desired 
>     library to the list of libraries to link with.
>     Examples (imagine you have mytest.cpp in the same directory as this file is):
> -	With gcc     : gcc -pthread -I./stlport mytest.cpp -L./lib/ -lstlport
> +	With GCC     : g++ -pthread -I./stlport mytest.cpp -L./lib/ -lstlport
>  	With DEC CC  : cxx -I./stlport mytest.cpp -L./lib/ -lstlport
>  	With SUN CC  : CC -mt -I./stlport mytest.cpp -L./lib/ -lstlport
>  	.....
> -   [ Visual C++ specific ] For VC++, you do not have to specify "stlport_XXX.lib" explicitly,
> -   as it is being choosen and forced to link automatically by "#pragma"'s in compiler config
> -   file in stlport/config/stl_msvc.h.
> -   Appropriate version is being selected based on /MD[d] vs /MT[d] options and _STLP_DEBUG setting.
> -   All you have to do is to set library search path for the linker.
> +   [ Visual C++ specific ] For (embedded) VC++, you do not have to specify 
> +   "stlport_XXX.lib" explicitly, as it is being choosen and forced to link 
> +   automatically by "#pragma"'s in compiler config file in 
> +   stlport/config/stl_msvc.h. Appropriate version is being selected based on 
> +   /MD[d] vs /MT[d] options and _STLP_DEBUG setting. All you have to do is 
> +   to set library search path for the linker.
>  	Example :
>             cl.exe /I.\stlport mytest.cpp /link /libpath:.\lib /MD
>  
> -9) If you linked your application with shared STLport library (.so or .dll), please make your .so or
> -   .dll's to be found in PATH at runtime. On Windows, the simplest way to do it
> -   is to copy all .dll's next to the executable. Or, you might choose to add bin directory
> -   containing STLport dlls to the PATH environment string.
> +9) If you linked your application with shared STLport library (.so or .dll), please 
> +   make your .so or .dll can be found by the dynamic linker. 
> +   Under Windows, the paths searched depend on the particular flavor, see the MSDN 
> +   documentation for LoadLibrary at http://msdn.microsoft.com. Easiest ways are to
> +   either modify the PATH environment variable or copy all .dll's next to the 
> +   executable. 
> +   Under Linux, the environment variable LD_LIBRARY_PATH can be adjusted to point
> +   to the dir containing. See the manpage for ld.so for more info.
>  
> -10) STLport build only multithreaded libraries, so your application should be compiled
> -   as multithreaded too. Use -pthread (or -pthreads on Solaris) option for gcc, -mt for SunPro,
> +10) STLport builds only multithreaded libraries, so your application should be compiled
> +   as multithreaded, too. Use -pthread (or -pthreads on Solaris) option for GCC, -mt for SunPro,
>     /MT for VC, and so on. Sometimes you should define _REENTRANT or something else, depends
>     upon platform/compiler. See compiler's and linker's options on command line when you build
>     unit tests (build/test/unit) for reference. The last is useful for ANY platform (special
> Index: README
> ===================================================================
> --- README	(revision 938)
> +++ README	(working copy)
> @@ -1,9 +1,9 @@
>  **********************************************************************
> -* 	README file for STLport 5.0                                  *
> +* 	README file for STLport 5.0                                    *
>  *                                                                    *
>  **********************************************************************
>  
> -This directory contains STLport-5.0 release.
> +This directory contains the STLport-5.0 release.
>  
>  What's inside :
>  
> @@ -18,7 +18,8 @@
>  build/test/unit  - build directory for regression (unit) tests
>  build/test/eh    - build directory for exception handling tests
>  stlport          - main STLport include directory
> -src              - source for iostreams implementation
> +src              - source for iostreams implementation and other parts
> +                   that aren't pure template code
>  lib              - installation directory for STLport library (if you
>                     use STLport iostreams and/or locale only);
>                     it may contain more subdirs, if you use
> Index: stlport/config/stl_msvc.h
> ===================================================================
> --- stlport/config/stl_msvc.h	(revision 938)
> +++ stlport/config/stl_msvc.h	(working copy)
> @@ -103,8 +103,8 @@
>   * instanciated to be exported. There is a workaround, seperate the non template methods
>   * from the template ones within 2 different classes and only export the non template one.
>   * It is implemented for basic_string and locale at the writing of this note. 
> - * This problem has finally been concidered as not important enough to not use this feature. 
> - * Moreover boost (www.boost.org) required it to be granted.
> + * This problem has finally been considered as not important enough to not use this feature. 
> + * Moreover Boost (www.boost.org) required it to be granted.
>   * The workaround is activated thanks to the _STLP_USE_MSVC6_MEM_T_BUG_WORKAROUND macro defined
>   * later in this config file.
>   */
>