Intravision/reactos
1
0
Fork 0
mirror of https://github.com/reactos/reactos.git synced 2025-08-07 05:43:08 +00:00
Code Issues Projects Releases Packages Wiki Activity

Git conversion: Make reactos the root directory, move rosapps, rostests, wallpapers into modules, and delete rossubsys.

Browse source
This commit is contained in:
Colin Finck 2017-10-03 07:45:34 +00:00
parent b94e2d8ca0
commit c2c66aff7d
24198 changed files with 0 additions and 37285 deletions
Download patch file Download diff file Expand all files Collapse all files

554
sdk/lib/3rdparty/stlport/doc/FAQ vendored Normal file
View file

@ -0,0 +1,554 @@
Content
Q1 About STLport and availability
Q1.0 What is STLport?
Q1.1 What are the benefits from using STLport?
Q1.2 What versions of STLport are available?
Q1.3 Where is the documentation or user guide?
Q1.4 What is the version policy?
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 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?
Q3 Building
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?
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 Has anybody succeeded building STLport on OS Y with compiler K n.n?
Q3.4 Does STLport support cross-compilation?
Q4 Installation
Q4.1 I tried "make -f gcc.mak install", but it install nothing into
/usr/local/. How I can install headers into /usr/local/include and
libs into /usr/local/lib?
Q5 Bug report
Q5.0 I found a bug, how can I report about it?
Q6 Design
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 detects memory leaks in applications with STLport. Is this leak
from STLport?
Q6.3 When running unit tests, I have errors in LocaleTest test fixture, how bad
is it?
Q6.4 set or multiset iterators are immutable like const_iterators, why ?
Answers
========================================================================
Q1.0 What is STLport?
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 are the benefits from using STLport?
A1.1
- For multiplatform/multicompilers project a coherent Standard Library
implementation.
- An easy to use STL safe mode detecting bad use of containers and
iterators.
- Some original optimizations: template expression for string
concatenation, short string optimization, move semantic for STL containers
combination like vector of vector, an efficient std::allocator.
========================================================================
Q1.2 What versions of STLport are available?
A1.2
========================================================================
Q1.3 Where is the user guide?
A1.3 There is no real user guide for the moment. You can find some information
in README files in doc folder. As STLport is a C++ Standard library
implementation you might find information you need at the following
locations:
- The ISO/IEC 14882:2003 document you can buy for a very cheap price.
- For STL containers you can use SGI documentation (http://www.sgi.com/tech/stl/).
Beware however, STL described in this document is not identical to the
Standardized version described in ISO/IEC. This documentation can be very
useful for STLport extensions like hash containers (hash_map, hash_set...)
- You can also use the documentation coming with your compiler as most
of the information will also apply to STLport. Take care to description
reported as 'implementation specific'.
========================================================================
Q1.4 What is the version policy?
A1.4 STLport version information contains three numbers like '5.1.0'. '5'
is the major version number, '1' is the minor and '0' is the patch level.
Policy for this numbers are:
- changes in major version number: radical modification, new era.
- changes in minor version number: significant changes, new features,
changes in interface part; switching to an STLport library with a different
minor version require recompilation of all modules depending on it.
- changes in patch level: bugfixes; we keep in mind binary compatibility,
but really can't strongly guarantee it; switching to an STLport library
with different patch level do not require rebuild of modules---rebuilding and
installing the STLport libraries should work; however, as STLport contains
a lot of template code, you should pay attention to fact that all you modules
was build with SAME STLport headers---otherwise problems possible;
recompilation of one part with only rebuilding STLport might not be enough
to get all the fixes in your application so even in this case rebuilding
your modules is advised.
========================================================================
Q2.0 Do I need a C++ compiler?
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, 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 the C++ compiler.
========================================================================
Q2.2 Can I use containers and algorithms from STLport and iostreams from
the library that ships with my compiler?
A2.2 The short answer is 'No'.
Indeed co-existence of two implementations possible, but this required
a lot of knowledge as about both implementations, as about compiler and
linkage. This issues should be taken into account both within STL library and
during library usage. In common you can't use both implementation
in the same namespace. So you should separate STL implementations into
different namespaces. But due to absent of compilers that has full-featured
support of Argument Dependent Lookup (ADL) (aka Koenig Lookup), you have no
possibilty to select one or another implementation.
ADL problem.
In wrapper mode, all std references are replaced, thanks a simple macro,
by the stlp_std namespace. Everything from the native compiler std namespace
is injected to the stlp_std namespace with many using std::* directives.
The problem arise when you specialized a standard class for one of your
user types. You do it within the std namespace that, in wrapper mode
becomes the stlp_std namespace. Then this specialization is just invisible
from the native std namespace and won't be used.
Things are somewhat worse: the problem arises even without any explicit
specializations. It is not a bug, but the fact that old compilers just
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 implementation via library.
Let's reduce all the complexity of STLport to some very simple example:
namespace std {
class string
{
public:
class iterator { };
iterator begin();
iterator end();
};
template<class I, class T>
void find(I begin, I end, T value);
} // namespace std
namespace stlport {
using std::string;
template<class I, class T>
void find(I begin, I end, T value);
void gee()
{
string s;
find(s.begin(), s.end(), 10);
}
} // namespace stlport
When a compiler supporting ADL finds the call to `find' within gee() function
it should examine both namespace `stlport' and namespace `std' for
the presence of `find'. It is caused by the fact that s.begin() returns
object of type `std::string::iterator' which obviously defined in namespace
`std' and the heart of ADL is finding functions not only within namespaces
where the call is being made but also in the namespaces where the classes
of arguments are defined...
So, in our example compiler ends with two templates satisfying the call
`find(s.begin(), s.end(), 10)': `std::find' and `stlport::find'.
Since compiler can not choose any one of them it reports ambiguity.
There is another aspect of mix implementations.
Let's consider following code:
a.h:
#include <string>
class A {
public:
A() {}
void push( const string s );
string _str;
};
a.cpp:
#include "a.h"
void A::push( const string s )
{
_str = s;
}
b.cpp:
#include "a.h"
string s;
A a;
void gee()
{
a.push( s );
}
Now build library from a.cpp with string implementation Impl1;
then build application with b.cpp that use string implementation Impl2,
and link with mentioned above library. Compiler will pass. Linker may
pass too. But your application will crash (or randomly crash) either on
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 removed support
for it".
========================================================================
Q2.3 Can I mix STL implementations in my project?
A2.3 Yes you can but each implementations will rely in its own namespace
with no direct interaction between them. You will first need to correctly
configure STLport thanks to 2 macros in user_config.h file.
- _STLP_DONT_REDEFINE_STD tells STLport not to define the std macro that is
used to replace std reference in your code with STLport namespace.
- _STLP_WHOLE_NATIVE_STD tells STLport to always include native header each
time a Standard header is included in your code.
Here is a small code sample that do not require any modification in STLport
install:
#define _STLP_DONT_REDEFINE_STD
#define _STLP_WHOLE_NATIVE_STD
#include <string>
void foo()
{
std::string std_str("std");
stlport::string stlport_str("stlport");
stlport_str.append(std_str.begin(), std_str.end());
// Following is wrong because there is no assignment
// operator for stlport::string on std::string.
//std_str = stlport_str;
}
Note: You can use 'std' iterators from native implementation in STLport
template methods like in the 'stlport_str.append' method call above because
STLport is adding the necessary code to interpret native iterators like
STLport iterators. You won't be able however to do the opposite as native
implementation do not know anything about STLport iterators.
========================================================================
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 STLport WHITHOUT YOUR code:
- build STLport library
- build STLport unit tests
- run STLport unit tests
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 are sure, submit bug report here:
https://sourceforge.net/projects/stlport
Don't forget to describe your operational environment, compiler version and
STLport version.
========================================================================
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. paths from compiler origo).
Package maintainers can use any path by own taste---we can't satisfy
variety of distributions/packages.
So you can:
- fix path in stlport administration config file stlport/stl/config/host.h,
see _STLP_NATIVE_INCLUDE_PATH macro and related.
- create a link to the native compiler headers like expected by STLport
- make request to package maintainer
- build and install compiler
Note: Starting with version 5.2, STLport uses the include_next preprocessing
command to access native headers so you shouldn't experiment this problem
anymore when this feature is supported by your compiler preprocessor.
========================================================================
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.
========================================================================
Q3.2 During library compilation with MS VC++ 6.0 I see following error report:
C:\Program Files\Microsoft SDK\Include\.\winbase.h(1123) : error C2733: second C linkage of overloaded function 'InterlockedIncrement' not allowed
C:\Program Files\Microsoft SDK\Include\.\winbase.h(1121) : see declaration of 'InterlockedIncrement'
C:\Program Files\Microsoft SDK\Include\.\winbase.h(1130) : error C2733: second C linkage of overloaded function 'InterlockedDecrement' not allowed
C:\Program Files\Microsoft SDK\Include\.\winbase.h(1128) : see declaration of 'InterlockedDecrement'
C:\Program Files\Microsoft SDK\Include\.\winbase.h(1138) : error C2733: second C linkage of overloaded function 'InterlockedExchange' not allowed
C:\Program Files\Microsoft SDK\Include\.\winbase.h(1135) : see declaration of 'InterlockedExchange'
A3.2 You have a Platform SDK installed. Uncomment line
#define _STLP_NEW_PLATFORM_SDK 1
in the file stlport/stl/config/user_config.h. There is no way to detect SDK
presence during preprocessor stage, which is why you have to make this
change manually.
========================================================================
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.
========================================================================
Q3.4 Does STLport support cross-compilation?
A3.4 In case of GCC, use something like following sequence:
(./configure --target=${CROSSTARGET}; cd build/lib; \
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',
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 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 installs nothing into
/usr/local/. How I can install headers into /usr/local/include and
libs into /usr/local/lib?
A4.1 Installation in any system-wide place is issue of either 'package builder'
or system administrator. He/she should be familiar with building package
procedure and/or understand where headers and libraries should be situated.
The place choice not issue of STLport.
You can just use
(cd ${STLPORT_SRC}/lib; tar cf - . ) | (cd ${TARGET_LIB_DIR}; tar xf - ); \
(cd ${STLPORT_SRC}; tar cf - stlport) | (cd ${TARGET_INCLUDE_DIR}; tar xf - )
Sometimes we will think about 'make install', but not now.
========================================================================
Q5.0 I found a bug, how I can report about it?
A5.0
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/config/user_config.h).
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 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
https://sourceforge.net/projects/stlport
DON'T FORGET TO DESCRIBE:
- OPERATIONAL ENVIRONMENT
- COMPILER VERSION
- STLPORT VERSION
- RESULT OF UNIT TESTS
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 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 are using C++ ones or are refering
to the std namespace. That's why, if stddef was absent in STLport, then
#include <string>
#include <stddef.h>
may cause problem in following code, because std redefined in the end of
<string> header, and std may be used in stddef.h:
__BEGIN_NAMESPACE_STD
....
__END_NAMESPACE_STD
where __BEGIN_NAMESPACE_STD is defined as 'namespace std {'.
To avoid this, STLport has stddef.h header and provide correct masquerade
for std.
========================================================================
Q6.1 Is STLport a replacement for headers and libraries that shipout
with compiler?
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
uses 'native' headers and libraries to take interface to system functions and
variables.
========================================================================
Q6.2 My tool detects memory leaks in application with STLport. Is this leak
from STLport?
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. 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
false memory leaks when one uses STLport's node allocator. The memory chunk is
normally freed at application end, but the memory checkers usually report memory
leaks before that point. Another memory problem might be reported when you use
shared libraries (e.g. DLL, this problem specific for Windows DLL model) that
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 consumption 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
freed at the end of the program, the leaks are just pseudo-ones). You could use
another allocator that is used in STLport. Open the file
"./stlport/stl/config/host.h" and uncomment either one of the following:
_STLP_USE_NEWALLOC enables a simple allocator that uses "new/delete"
_STLP_USE_MALLOC enables a simple allocator that uses "malloc/free"
The new/delete allocator has the advantage of giving an entry point to track
memory starvation, see set_new_handler in your compiler doc or the C++ Standard
for more information.
Alternatively you can define the following symbol, just uncomment it in
"./stlport/stl/config/host.h".
_STLP_LEAKS_PEDANTIC
The symbol forces freeing all memory chunks. Also see the comments around the
symbol in the config file.
Note that you have to recompile STLport AND your application and all of your
dependent libraries if you make any change to the file!
There are also some defines that help in debugging memory problems in STLport.
In _STLP_DEBUG mode, just also define the following symbols, either in
"./stlport/stl/config/user_config.h" or in your project settings:
_STLP_DEBUG_ALLOC
_STLP_DEBUG_UNINITIALIZED
You don't need to rebuild STLport for these options, but you have to rebuild
your application and all of your dependent libraries if you make any change to
the file.
========================================================================
Q6.3 When running unit tests, I have errors in LocaleTest test fixture, how bad
is it?
A6.3 Failures in LocaleTest tests do not mean that your platform/compiler is not
fully supported by STLport. Platform independant localization tests are very hard
to write as Standard localization API has not been design to make unit test easy.
In STLport unit tests suite we have hard coded some expected values. Those values
depends on your OS configuration explaining why sometimes the tests are failing.
========================================================================
Q6.4 set or multiset iterators are immutable like const_iterators, why ?
A6.4 With set or multiset associative containers or even newly introduced
tr1::unordered_set and tr1::unordered_multiset key is confuse with data. It
means that modifying the data is also modifying the key. Modifying the key
might corrupt the container internal data structure so STLport prefer to
make this problem obvious and only return a const access to the key with
immutable iterators. Your solutions are:
- prefer map/multimap and split the key and the data
- use const_cast when you want to change a set/multiset element.

154
sdk/lib/3rdparty/stlport/doc/README.borland vendored Normal file
View file

@ -0,0 +1,154 @@
==================================================
STLport README for Borland C++ compilers.
==================================================
by: Francois Dumont, dums@stlport.com, last edited 20 May 2006
============
Introduction
============
This document describes how STLport can be compiled and used with
Borland compilers.
For any further comments or questions visit STLport mailing lists
http://stlport.sourceforge.net/Maillists.shtml or forums
https://sourceforge.net/forum/?group_id=146814
=============
Prerequisites
=============
To build and use STLport you will need following tools and libraries:
- Borland C++ compiler package 5.5.1 or higher version.
In order to build STLport the Borland compiler and linker have to
be correctly configurated too. That is to say:
* For the Borland compiler bcc32:
In Borland's 'bin' directory (same directory as bcc32.exe), create a
bcc32.cfg file containing the compiler option giving it the path to
native Borland headers:
-I%BORLAND_PATH%\BCC55\include
* For the resource compiler brcc32:
Create an environment variable INCLUDE containing path to native Borland
headers and especially the windows.h file
set INCLUDE=%BORLAND_PATH%\BCC55\include
* For the Borland linker ilink32:
You need to give path to both the Borland libs and Borland PSDK libs.
For that you have to create, in the same directory as ilink32.exe, a
configuration file, ilink32.cfg, that contains:
-L%BORLAND_PATH%\BCC55\lib;%BORLAND_PATH%\BCC55\lib\PSDK
- A GNU make tool. You can get one from www.mingw.org or www.cygwin.com.
See README.mingw or README.cygwin for additional informations.
===================
Configuring STLport
===================
This is intended to be an optional step, if you want to use default
configuration simply jump to next chapter 'Building STLport'. Open a console
and go to the STLport build/lib folder. Run
configure --help
This command will present you the different available build options. Just follow
the instructions to set STLport configuration according your needs. For example,
to set the typical configuration for most Borland compilers, run
configure -c bcc
================
Building STLport
================
This is a step by step description of the actions to take in order to build
and install the STLport libraries:
1. Open a console, you can use a Msys, Cygwin or Windows console.
2. Go to the STLport build/lib folder:
cd C:\STLport\build\lib
3. Run the following command:
make -fbcc.mak install
Where 'make' is the GNU make utility you have installed. The name of
GNU make utility may differ, such as 'mingw32-make'. -f is a make option
telling it which makefile to use. You have of course to choose the
appropriate makefile for your compiler, 'bcc.mak' in our case.
Once the command returns you will have all the necessary import libraries
in STLport's 'lib' folder and DLLs in STLport's 'bin' folder. For a
description of the generated libraries check the FAQ file in the 'doc' folder.
For a quick start guide to the STLport make system, see the README file in the
'build/lib' folder.
===============
Testing STLport
===============
You can use the unit tests to verify STLport behaves correctly. Change into
STLport's 'build/test/unit' folder and type:
make -fbcc.mak install
This will build and install the unit tests with STLport dynamic libraries.
Once the unit tests are built you just need to run them. They can be found
in STLport's bin, bin-g or bin-stlg folders. To rebuild the unit tests
with STLport static libraries, type:
make -fbcc.mak clean
make -fbcc.mak install-static
=============
Using STLport
=============
Adjust your include and link paths in Borland IDE or in the command line config
files. In the include files add the path to STLport's 'stlport' folder. Make sure
it is the first directory listed there. Add STLport's 'lib' folder for the library
files (order of paths doesn't matter here).
Now you should be ready to use STLport.
============
Known limitations
============
1. If you extend a locale facet based on a Standard facet definition you will
have to grant your own facet id defition. Ex extracted from
test/unit/fstream_test.cpp:
#include <locale>
using namespace std;
struct my_state {
char dummy;
};
struct my_traits : public char_traits<char> {
typedef my_state state_type;
typedef fpos<state_type> pos_type;
};
class my_codecvt : public codecvt<char, char, my_state>
{};
// Mandatory locale facet id definition:
template <>
locale::id codecvt<char, char, my_state>::id;
2. If you get a linker memory error, e.g. LME351, it probably means that full
source debugging is enabled and Borland's .TDS file has exceeded the memory
capacity of Borland's linker (ilink32.exe). To resolve this error, check
Borland's website for the latest patch for ilink32.exe. In the alternative,
disable full source debugging in build\Makefiles\gmake\bcc.mak by deleting
the -v option in the OPT settings.
3. For "'uname' is not recognized . . .", see "Configuring STLport" above.

43
sdk/lib/3rdparty/stlport/doc/README.cygwin vendored Normal file
View file

@ -0,0 +1,43 @@
The cygwin platform is used to build STLport with different compilers.
- gcc (native compiler):
Makefile : gcc.mak
Notes:
1. Static builds (archive)
If you use the static version of the STLport libraries you have
to define the _STLP_USE_STATIC_LIB macro in order to have your
executable linked correctly.
2. Link
Under this platform STLport is complete replacement for libstdc++.
It means that when you were linking with libstdc++ (-lstdc++) you only
have to replace it with STLport (-lstlport.5.2 for instance). However
default gcc behavior is to automatically link libstdc++ and a number of
other system libs. To avoid this behavior you have to use the -nodefaultlibs
compiler option and explicitely give all libraries by yourself. See build of
unit tests to see what library you might need, here is the list when this
note was written:
without -mnocygwin option:
-lstlportg.5.2 -lgcc -lm -lc -lpthread -lkernel32
with -mno-cygwin option:
-lstlportg.5.2 -lgcc -lmingw32 -lmingwex -lmsvcrt -lm -lmoldname
-lcoldname -lkernel32
3. No cygwin
To build STLport libraries that do not depend on cygwin1.dll
making them freely redistributable pass the following option to
the configure script:
./configure --with-extra-cflags=-mno-cygwin --with-extra-cxxflags=-mno-cygwin
- Borland C++ compiler

81
sdk/lib/3rdparty/stlport/doc/README.dmc vendored Normal file
View file

@ -0,0 +1,81 @@
==================================================
STLport README for Digital Mars C++ compilers.
==================================================
Build of STLport with Digital Mars C++ compiler is very similar
to the one for Microsoft Visual Studio compiler (see README.msvc).
Below are some additional hints. [DMC users are encouraged to
contribute additional information.]
=============
Prerequisites
=============
- Digital Mars C++ 8.49 or above
- A GNU environment with make tool. Prefer MinGW/MSys to Cygwin because the
latter contains a link command that is also the name of the Digital Mars linker
and you might experiment collision between both commands.
See README.mingw for additional information.
===================
Installing STLport
===================
- STLport directory can be almost anywhere EXCEPT native dm\include directory.
===================
Configuring STLport
===================
- In a console window go to the STLport build\lib folder. Run
configure -c dmc
================
Building STLport
================
- To build STLport libraries:
cd [STLport dir]\build\lib
[mingw32-make] -f dmc.mak install
- To build STLport (dynamic) unit tests:
cd [STLport dir]\build\test\unit
[mingw32-make] -f dmc.mak install
============
Known issues
============
1. typeinfo.h
DMC forces inclusion of typeinfo.h header at the begining of any
translation unit. This breaks the STLport include schema, especially
when building the library. As a workaround STLport typeinfo.h simply
include native DMC header not performing any internal STLport work as
importing things to STLport namespace. As a result typeinfo.h should
never be reference in user code, as it is neither a C nor a C++ header
this is not considered as a major limitation. The C++ Standard header
is typeinfo.
2. link.exe and lib.exe
STLport makefiles for DMC use dm_link and dm_lib instead of link and lib to
avoid conflicts with other vendors' linkers and archivers. To build STLport
with DMC, please copy or rename the following files:
copy dm\bin\link.exe dm\bin\dm_link.exe
copy dm\bin\lib.exe dm\bin\dm_lib.exe
3. Free online version.
If DMC's free online version reports compiler or linker errors, the
solution may be in a free online CD update. Download and unzip all free
CD patches for versions 8.30 and above, in consecutive order, overwriting
previous files. Then install free online version 8.49 or above, overwriting
previous files.

157
sdk/lib/3rdparty/stlport/doc/README.evc3 vendored Normal file
View file

@ -0,0 +1,157 @@
========================================
STLport README for eMbedded Visual C++ 3
========================================
by: Michael Fink, vividos@users.sourceforge.net, last edited 2005-11-15
============
Introduction
============
This document describes how STLport can be compiled and used with Microsoft
eMbedded Visual C++ 3.
For any further comments or questsion visit STLport mailing lists
http://stlport.sourceforge.net/Maillists.shtml or forums
https://sourceforge.net/forum/?group_id=146814
=============
Prerequisites
=============
To build and use STLport you will need following tools and libraries:
- eMbedded Visual C++ 3.0
- latest CVS version of STLport, use info from page
'http://stlport.sourceforge.net/CVS.shtml' to get it.
Note that you may have to get a different branch, please check out the
STLport forum "Announcements" which sourcecode is being worked on.
================
Building STLport
================
Note: if you don't plan to use the iostreams part of STLport (via the define
_STLP_NO_IOSTREAMS), you don't have to build the library. You can skip straight
to the "Using STLport" section.
If you want to compile for the Pocket PC 2002 SDK (which in most cases you want)
be sure to set the PLATFORM environment variable to "Pocket PC 2002", e.g. with
this command:
set PLATFORM=Pocket PC 2002
Open a command line prompt and execute the batch file that sets up compiling
for ARM or x86 processors. These files usually are in a folder like
'C:\Program Files\Windows CE eMbedded Tools\EVC\WCE300\BIN\' and are called
WCEARM.bat and WCEx86.bat. Check if the environment variables are set up
properly after that call. You can also adjust the batch files to have the
PLATFORM variable set automatically.
Go into STLport's 'build\lib' folder and type:
configure.bat -c evc3
The makefiles are configured with the given settings. Call configure.bat with
the --help option to see all options. The program automatically tells you which
command line to use. If you want to install the libraries, add the "install"
target as follows:
nmake /fmsvc.mak install
All libraries (debug, stldebug, release) are now built, static and shared
ones. Import libraries (.lib files) are put in the 'lib\evc3-arm' folder, DLLs
are put in the 'bin\evc3-arm' folder. If you use another target platform, the
name of the folder is changed accordingly, e.g. evc3-x86 for emulator files.
Once STLport is built you can decrease the size of the STLport folder by
removing intermediate build files. This is done with the following command:
nmake /fmsvc.mak clobber
Note: MIPS platform is also available for build, but it may not compile or work
properly. Use with caution!
===============
Testing STLport
===============
You can use the unit tests to verify STLport behaves correctly. Change into
STLports 'build\test\unit' folder and type:
nmake /fmsvc.mak install
If you want to build the unit tests for the emulator, you have to reconfigure
STLport with the configure.bat, as described above.
Once the unit tests are built, upload the binary (found in the 'bin\evc3-arm'
folder) to your device or emulator and start it (the test runs for about 30
seconds, depending on the speed of the device). The file 'stlp_test.txt' is
created in the root folder of the device, which contains the unit test
results. It should report no errors.
=============
Using STLport
=============
Adjust your include and link paths in eVC3 in 'Tools -> Options -> Directories'
and add the paths for all platforms and CPUs on which you want to use STLport.
In the include files add the path to STLport's 'stlport' folder. Make sure it
is the first directory listed there. Add STLport's 'lib\evc3-arm' or
'lib\evc3-x86' (depending on what target you use) folder for the library files
(order of paths doesn't matter here).
There are some preprocessor defines that control usage of the STLport in evc3
projects:
Define the symbol _STLP_USE_STATIC_LIB when you want to statically link against
STLport. The linker will remove unused classes and methods then, saving some
space in the executable.
If you don't want to use the iostreams part of the library, you can specify the
define _STLP_NO_IOSTREAMS. In this mode there is no need to link against the
library.
STLport uses automatic linking to find the proper .lib file. If you want to see
what import library STLport is going to use, define _STLP_VERBOSE_AUTO_LINK.
When not using automatic linking (by specifying _STLP_DONT_USE_AUTO_LINK), you
have to specify the proper .lib file in the Project Settings, on the "link" tab.
The .lib names have the following syntax:
stlport(d|stld)[_static].<STLport-Version>.lib
Examples:
stlport_static.5.0.lib - static release version, Version 5.0.0
stlportd_50.lib - dll debug version, Version 5.0.0
Note that usage of the _STLP_DEBUG mode is currently not recommended for
eMbedded Visual C++ builds using the ARM compiler, due to a compiler bug.
When using STLport together with MFC, be sure to include the MFC headers first,
then include STLport headers, e.g. in your Stdafx.h. This way STLport correctly
recognizes MFC usage. You also can define the macro _STLP_USE_MFC, either in
your project settings or in stlport/stl/config/user_config.h.
Now you should be ready to use STLport.
============
Known issues
============
- Unit Tests in _STLP_DEBUG mode (target 'stldbg-shared') fails in
__stl_debug_engine::_M_detach() for several tests due to unknown reasons.
A compiler bug in the ARM compiler is suspected.
There is currently no workaround for this bug. It is recommended to not use
_STLP_DEBUG mode.
- Resource compiler issue:
The resource compiler is not a C++ compiler, it is a compiler that translates
resource files, i.e. files that describe dialogs, strings, version information
and other parts of the GUI on MS Windows systems.
The problem is that it includes files from the C/C++ include path, and
STLport uses mechanisms the resource compiler can't handle, e.g. using macro
names longer than 31 characters.
The workaround is to guard all affected headers (stdio.h, string.h, stdarg.h,
stdlib.h, ctype.h) against this. The resource compiler is detected by the
macro RC_INVOKED.
- See also README.evc4 issues.

126
sdk/lib/3rdparty/stlport/doc/README.evc4 vendored Normal file
View file

@ -0,0 +1,126 @@
========================================
STLport README for eMbedded Visual C++ 4
========================================
by: Zdenek Nemec, zero@mapfactor.com, last edited 2005-10-17
============
Introduction
============
This document should provide step-by-step guidance for installing, testing and using the STLport library under Windows CE .NET 4.x
(aka Windows Mobile 2003 aka Pocket PC 2003).
For any further comments or questions visit the STLport mailing lists
http://stlport.sourceforge.net/Maillists.shtml or forums
https://sourceforge.net/forum/?group_id=146814
=============
Prerequisites
=============
To build and use the STLport you will need following tools and libraries:
- eMbedded Visual C++ 4.0 SP4
- an SDK for your target platform with RTTI support
================
Building STLport
================
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).
NOTE: If you are using Microsoft's batch files to set system variables check if both WCEROOT and SDKROOT vars are set to correct locations. example:
WCEROOT=C:\Program Files\Microsoft eMbedded C++ 4.0
SDKROOT=C:\Program Files\Windows CE Tools
Third, when you are 100percent sure you've set correctly systems variables go to the STLport/build/lib dir and run the configure.bat with
proper -c option (ie. "-c evc4"),
then invoke following command: 'nmake /fmsvc.mak install' to build the library.
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
e.g. both ARM and x86 emulator binaries, just don't forget to do
'nmake /fmsvc.mak clobber' before new build.
Note: MIPS platform is also available for build, but it may not compile or work properly. Use with caution!
===============
Testing STLport
===============
When you successfuly build STLport libs, you should go to STLport/test/unit directory build and run the STLP test suite.
Use 'nmake /fmsvc.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) 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.
=============
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.
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.
Also, there is only one runtime available but the IDE doesn't add the corresponding switch to the command line.
The right switch (selecting a dynamically linked runtime) is IMHO /MD or /MDd. This then also switches STLport to dynamic linking.
Alternatively, you can #define _DLL for your project, which achieves the same but, again IMHO, is a less clean solution.
============
Known issues
============
- 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.
- There is a bug in the MIPS compiler that comes with eVC4 which only surfaces
under certain conditions:
* in release mode with global optimizations on (#pragma optimize("g", on))
* a baseclass has (at least) two pointer members
* a derived class adds no data members
* the derived class' cctor defers to the basclass' compiler-generated cctor
* it is passed as template parameter to a function
The smallest testcase I could come up with is this:
struct base {
void* ptr1;
void* ptr2;
};
struct derived: public base {
derived() {}
derived(const derived& __x): base(__x) {}
};
template<typename SomeType> void function( SomeType st1, SomeType st2) {}
struct test {
derived tmp;
~test() { function(tmp, tmp); }
};
test test;
..which causes an internal compiler error. Removing the base::ptr1, adding data
to derived, making function() a normal function, or turning off optimization
(#pragma optimize("g", off)) all causes the code to compile. This bug affects
iterators of deque and vector<bool>.
- Because of interdependancy between STLport and native Standard library headers
STLport headers should always be included first in your translation unit (.cpp
file). That is to say that:
//Wrong headers order:
#include <windows.h>
#include <cstdlib>
// Correct headers order
#include <cstdlib>
#include <windows.h>

98
sdk/lib/3rdparty/stlport/doc/README.evc8 vendored Normal file
View file

@ -0,0 +1,98 @@
setup VC8 for CE:
------------------
- VC8 doesn't have any setup batchfiles that prepare the environment for compiling
with CE. You can take those from eVC4 and adapt them or write your own. This snippet
should get you going:
rem you need to adapt at least these three
set OSVERSION=WCE500
set PLATFORM=MY_OWN_PLATFORM
set TARGETCPU=MIPSII
rem the compiler is always cl.exe, different compilers are in different paths
set CC=cl.exe
rem obviously, these need to be adjusted to where you installed VS2005 and the SDKs
set VSINSTALLDIR=C:\Programme\Microsoft Visual Studio 8
set SDKROOT=C:\Programme\Windows CE Tools
set PATH=%VSINSTALLDIR%\VC\ce\bin\x86_mips;%VSINSTALLDIR%\VC\bin;%VSINSTALLDIR%\Common7\IDE;%PATH%
set PLATFORMROOT=%SDKROOT%\%OSVERSION%\%PLATFORM%
rem add libs and includes from the SDK
set INCLUDE=%PLATFORMROOT%\include\%TARGETCPU%;%PLATFORMROOT%\MFC\include;%PLATFORMROOT%\ATL\include
set LIB=%PLATFORMROOT%\lib\%TARGETCPU%;%PLATFORMROOT%\MFC\lib\%TARGETCPU%;%PLATFORMROOT%\ATL\lib\%TARGETCPU%
rem add libs that came with VC8
rem Note: there are more libs and includes under ce\atlmfc, not sure if these are needed.
set LIB=%LIB%;%VSINSTALLDIR%\VC\ce\lib\%TARGETCPU%
- The snippet below can be used to build STLport for Pocket PC 2003 (using the
Pocket PC 2003 SDK shipped with Visual Studio 2005, this is the SDK used when
compiling programs from within the IDE):
set OSVERSION=WCE420
set PLATFORM=POCKET PC 2003
set TARGETCPU=ARMV4
rem the compiler is always cl.exe, different compilers are in different paths
set CC=cl.exe
rem obviously, these need to be adjusted to where you installed VS2005
set VSINSTALLDIR=C:\Program Files\Microsoft Visual Studio 8
set SDKROOT=%VSINSTALLDIR%\SmartDevices\SDK
set PATH=%VSINSTALLDIR%\VC\ce\bin\x86_arm;%VSINSTALLDIR%\VC\bin;%VSINSTALLDIR%\Common7\IDE;%PATH%
set PLATFORMROOT=%SDKROOT%\PocketPC2003
rem add libs and includes from the SDK
set INCLUDE=%PLATFORMROOT%\include
set LIB=%PLATFORMROOT%\lib\%TARGETCPU%
rem add libs that came with VC8
set INCLUDE=%INCLUDE%;%VSINSTALLDIR%\VC\ce\atlmfc\include
set LIB=%LIB%;%VSINSTALLDIR%\VC\ce\lib\%TARGETCPU%;%VSINSTALLDIR%\VC\ce\atlmfc\lib\%TARGETCPU%
You should now be able to run cl.exe for the target you expected.
- The cross compilers of VC8 are the same version as for the native target, i.e. MSC14.
- The cross compiler for MIPS has the same bug as mentioned in doc/README.evc4 and
the same workaround applies. However, using 'whole program optimization', it results
in an error in the link phase.
- In order for STLport to recognize which target you are compiling for, you need to have
some macros defined, e.g. for the target architecture. The compilers do that partially on
their own, but not sufficiently. Therefore, STLport requires these defines:
-- These are generally set for CE:
_UNICODE;UNICODE;_WIN32;WIN32;UNDER_CE;WINCE;
-- This one uses an environment variable to set the CE version:
_WIN32_WCE=$(CEVER);
-- These are used to help STLport recognise the target architecture:
$(ARCHFAM);$(_ARCHFAM_);$(INSTRUCTIONSET)
Note that the instructionset is not strictly needed for x86 but definitely for ARM. It
doesn't hurt for x86 though, so I'd always set these in any new project.
-- For release builds:
NDEBUG;
-- For debug builds:
DEBUG;_DEBUG;
-- For debug builds with additional STLport diagnostics:
DEBUG;_DEBUG;_STLP_DEBUG;
-- For MFC applications:
_AFXDLL;
- Further settings:
Code generation: Multithreaded [Debug] DLL
Language: enable RTTI
Optimization: maximise speed and enable whole program optimization for release builds
- Linker settings:
Ignore specific libraries: libc.lib;libcd.lib
Commandline: /SUBSYSTEM:WINDOWSCE
Optimisation: /LTCG for release builds
- Resource compiler:
Define: UNDER_CE;WINCE;_WIN32_WCE=$(CEVER)

95
sdk/lib/3rdparty/stlport/doc/README.evc9 vendored Normal file
View file

@ -0,0 +1,95 @@
setup VC9 for CE:
------------------
- VC9 doesn't have any setup batchfiles that prepare the environment for compiling
with CE. You can take those from eVC4 and adapt them or write your own. This snippet
should get you going:
rem you need to adapt at least these three
set OSVERSION=WCE500
set PLATFORM=MY_OWN_PLATFORM
set TARGETCPU=MIPSII
rem the compiler is always cl.exe, different compilers are in different paths
set CC=cl.exe
rem obviously, these need to be adjusted to where you installed VS2008 and the SDKs
set VSINSTALLDIR=C:\Programme\Microsoft Visual Studio 9.0
set SDKROOT=C:\Programme\Windows CE Tools
set PATH=%VSINSTALLDIR%\VC\ce\bin\x86_mips;%VSINSTALLDIR%\VC\bin;%VSINSTALLDIR%\Common7\IDE;%PATH%
set PLATFORMROOT=%SDKROOT%\%OSVERSION%\%PLATFORM%
rem add libs and includes from the SDK
set INCLUDE=%PLATFORMROOT%\include\%TARGETCPU%;%PLATFORMROOT%\MFC\include;%PLATFORMROOT%\ATL\include
set LIB=%PLATFORMROOT%\lib\%TARGETCPU%;%PLATFORMROOT%\MFC\lib\%TARGETCPU%;%PLATFORMROOT%\ATL\lib\%TARGETCPU%
rem add libs that came with VC9
rem Note: there are more libs and includes under ce\atlmfc, you need to add these
rem instead of the ones in the SDK if you want to use the newer version of ATL/MFC.
set LIB=%LIB%;%VSINSTALLDIR%\VC\ce\lib\%TARGETCPU%
- The snippet below can be used to build STLport for Pocket PC 2003 (using the
Pocket PC 2003 SDK shipped with Visual Studio 2008, this is the SDK used when
compiling programs from within the IDE):
set OSVERSION=WCE420
set PLATFORM=POCKET PC 2003
set TARGETCPU=ARMV4
rem the compiler is always cl.exe, different compilers are in different paths
set CC=cl.exe
rem obviously, these need to be adjusted to where you installed VS2008
set VSINSTALLDIR=C:\Program Files\Microsoft Visual Studio 9.0
set SDKROOT=%VSINSTALLDIR%\SmartDevices\SDK
set PATH=%VSINSTALLDIR%\VC\ce\bin\x86_arm;%VSINSTALLDIR%\VC\bin;%VSINSTALLDIR%\Common7\IDE;%PATH%
set PLATFORMROOT=%SDKROOT%\PocketPC2003
rem add libs and includes from the SDK
set INCLUDE=%PLATFORMROOT%\include
set LIB=%PLATFORMROOT%\lib\%TARGETCPU%
rem add libs that came with VC9
set INCLUDE=%INCLUDE%;%VSINSTALLDIR%\VC\ce\atlmfc\include
set LIB=%LIB%;%VSINSTALLDIR%\VC\ce\lib\%TARGETCPU%;%VSINSTALLDIR%\VC\ce\atlmfc\lib\%TARGETCPU%
You should now be able to run cl.exe for the target you expected.
- The cross compilers of VC9 are the same version as for the native target, i.e. MSC15.
- In order for STLport to recognize which target you are compiling for, you need to have
some macros defined, e.g. for the target architecture. The compilers do that partially on
their own, but not sufficiently. Therefore, STLport requires these defines:
-- These are generally set for CE:
_UNICODE;UNICODE;_WIN32;WIN32;UNDER_CE;WINCE;
-- This one uses an environment variable to set the CE version:
_WIN32_WCE=$(CEVER);
-- These are used to help STLport recognise the target architecture:
$(ARCHFAM);$(_ARCHFAM_);$(INSTRUCTIONSET)
Note that the instructionset is not strictly needed for x86 but definitely for ARM. It
doesn't hurt for x86 though, so I'd always set these in any new project.
-- For release builds:
NDEBUG;
-- For debug builds:
DEBUG;_DEBUG;
-- For debug builds with additional STLport diagnostics:
DEBUG;_DEBUG;_STLP_DEBUG;
-- For MFC applications:
_AFXDLL;
- Further settings:
Code generation: Multithreaded [Debug] DLL
Language: enable RTTI
Optimization: maximise speed and enable whole program optimization for release builds
- Linker settings:
Ignore specific libraries: libc.lib;libcd.lib
Commandline: /SUBSYSTEM:WINDOWSCE
Optimisation: /LTCG for release builds
- Resource compiler:
Define: UNDER_CE;WINCE;_WIN32_WCE=$(CEVER)

19
sdk/lib/3rdparty/stlport/doc/README.intel vendored Normal file
View file

@ -0,0 +1,19 @@
Build of STLport with Intel C++ compiler for Windows is identical
to the one for Microsoft Visual Studio compiler (see README.msvc).
Known issues:
1. If you have bind your Intel C++ compiler to the Visual Studio 6
install and build your application without the -Qvc6 option you might
experiement linking issue concerning 'std::unexpected' missing symbol.
The reason of this problem is that without -Qvc6, ICL adds necessary
code to invoke std::unexpected function when a raised exception is
different to the one specified in a function prototype. As VC6 library
do not contain this symbol ICL cannot find it anywhere.
As a workaround, STLport has its own std::unexpected implementation
that you will find in src/dll_main.cpp. ICL is looking for a static
symbol so if you use STLport static lib ICL will use its std::unexpected
implementation but if you use STLport dynamic lib then ICL won't find
it. You only need then to copy/paste the STLport implementation somewhere
in your implementation and ICL will be happy.

55
sdk/lib/3rdparty/stlport/doc/README.mingw vendored Normal file
View file

@ -0,0 +1,55 @@
The MinGW GNU make command can be used to build STLport with different
compilers
- gcc (native compiler):
Makefile : gcc.mak
Notes:
1. Static library (archive)
If you use the static version of the STLport libraries
you have to define the _STLP_USE_STATIC_LIB macro in order
to have your executable linked correctly.
2. Shell
You will need MSys in order to build STLport.
Be carefull about what make command you are using. STLport comes with a
GNU make build system design for unix like platforms, make files have not
been adapted for the Windows platform. So you have to use the make command
coming with the MinGW package 'mingw32-make' and not the one coming with MSys
that is a portage of the GNU make for Windows.
3. Threading configuration
STLport libraries are built per default in order to be used in a
multithreaded environment. Under MinGW it means that we use the '-mthread'
compiler option. Don't forget to add it to your compiler command line too
if you want to use STLport libraries. You can also ask for not thread
safe libraries using the --no-thread configure script option.
4. Linking
In this environment STLport is almost complete replacement for libstdc++.
It means that when you were linking with libstdc++ (-lstdc++) you only have
to replace it with STLport (-lstlport.5.2 for instance) and with libsupc++
containing language compiler support (lsupc++). However default gcc
behavior is to automatically link libstdc++ and a number of other system libs.
To avoid this behavior you have to use the -nodefaultlibs compiler option and
explicitely give all libraries by yourself. See build of unit tests to see what
library you might need, here is the list when this note was written:
-lstlportg.5.2 -lsupc++ -lgcc_s -lmingw32 -lmingwex -lmsvcrt -lm -lmoldname
-lcoldname -lkernel32
- Borland C++ compiler:
Makefile : bcc.mak
- Digital Mars C++ compiler:
Makefile : dmc.mak

186
sdk/lib/3rdparty/stlport/doc/README.msvc vendored Normal file
View file

@ -0,0 +1,186 @@
==================================================
STLport README for Microsoft Visual C++ compilers.
==================================================
by: Francois Dumont, dums@stlport.com, last edited 08/02/2005
============
Introduction
============
This document describes how STLport can be compiled and used with Microsoft
Visual C++ 6 SP5. It can also be used for the MSVC++ family.
For any further comments or questsion visit STLport mailing lists
http://stlport.sourceforge.net/Maillists.shtml or forums
https://sourceforge.net/forum/?group_id=146814
=============
Prerequisites
=============
To build and use STLport you will need following tools and libraries:
- Microsoft Visual C++ 6.0 with at least Service Pack 5 or any higher
version.
===================
Configuring STLport
===================
In a console window go to the STLport build/lib folder. Run
configure --help
This command will present you the different available build options. Just follow
the instructions to set STLport configuration according your needs. The only
mandatory configuration is to declare what is the compiler you are going to
use, for MSVC 6 it is:
configure -c msvc6
================
Building STLport
================
This is a step by step description of the actions to take in order to have
the STLport library built:
1. Open a console window. You can get it executing cmd or command depending
on your Windows OS.
2. Go to MSVC++ Bin directory with a default MSVC6 install it is
cd "C:\Program Files\Microsoft Visual Studio\VC98\Bin"
3. Run the vcvars32.bat script. This sets the environment variables required
to have the MSVC++ compiler run during the build process. The most important
one is the PATH variable so that you can call the cl.exe command which is the
MSVC++ command line compiler. [You may omit this step, if you chose 'Install paths
to access command-line tools' during Microsoft Visual Studio installation procedure.]
4. Go to the STLport build/lib folder:
cd C:\STLport\build\lib
5. Run the following command:
nmake /fmsvc.mak install
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, msvc.mak in our case.
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.
===============
Testing STLport
===============
You can use the unit tests to verify STLport behaves correctly. Change into
STLports 'build/test/unit' folder and type:
nmake /fmsvc.mak install
Once the unit test is built you just need to run it. They can be found
within the STLport bin folder.
=============
Using STLport
=============
Adjust your include and link paths in MSVC IDE (in 'Tools -> Options -> Directories'
for MSVC6 IDE). In the include files add the path to STLport's 'stlport' folder.
Make sure it is the first directory listed there. Add STLport's 'lib' folder for
the library files (order of paths doesn't matter here).
There are some preprocessor defines that control usage of the STLport in msvc
projects:
If you don't want to use the iostreams part of the library, you can specify the
define _STLP_NO_IOSTREAMS. In this mode there is no need to link against the
library.
STLport uses automatic linking to find the proper .lib file. If you want to see
what import library STLport is going to use, define _STLP_VERBOSE_AUTO_LINK.
When not using automatic linking (by specifying _STLP_DONT_USE_AUTO_LINK), you
have to specify the proper .lib file in the Project Settings, on the "link" tab.
The .lib names have the following syntax:
stlport[d|stld][_x,_static,_statix].<STLport-Version>.lib
d : debug build
stld: debug build with _STLP_DEBUG (STL safe) mode
_x: Build of STLport as a dll but statically link to the native runtime.
_static : build of a static library
_statix : build of a static library link dynamically to the native runtime.
Examples:
stlport_static.5.0.lib - static release version, Version 5.0.0
stlportd.5.0.lib - dll debug version, Version 5.0.0
When using STLport together with MFC, be sure to include the MFC headers first,
then include STLport headers, e.g. in your Stdafx.h. This way STLport correctly
recognizes MFC usage. You also can define the macro _STLP_USE_MFC, either in
your project settings or in stlport/stl/config/user_config.h.
In order to enhance debugging with STLport you can optionally add the content of
the etc/autoexp.dat file in the autoexp.dat file coming with your Visual Studio
install.
Now you should be ready to use STLport.
============
Known issues
============
1. InterlockedIncrement
If you experiment trouble with the InterlockedIncrement Win32 API function
like the following message:
C:\Program Files\Microsoft SDK\Include\.\winbase.h(1392) : error C2733: second C
linkage of overloaded function 'InterlockedIncrement' not allowed
C:\Program Files\Microsoft SDK\Include\.\winbase.h(1390) : see declaration of
'InterlockedIncrement'
It means that you are using the new Microsoft platform SDK. There is no
way to known it from STLport code so you have to signal it in the
stlport/stl/config/user_config.h file (uncomment _STLP_NEW_PLATFORM_SDK in this file).
2. Native C/C++ library headers location
If you experiment trouble with location of ctime and other Standard headers
while building or using STLport you might be using the compiler coming with a
platform SDK. If so please uncomment _STLP_USING_PLATFORM_SDK_COMPILER in
stlport/stl/config/user_config.h. If it still do not find native headers you will
perhaps need to change native headers relative path used by STLport. In this case use
_STLP_NATIVE_INCLUDE_PATH and associated macro in stlport/stl/config/host.h.
4. C symbols in std namespace
The compiler of MSVC++ 6 has a bug when dealing with symbols existant in both
the global namespace and symbols imported by a using-directive or a
using-declaration - it will report an ambiguous call to an overloaded
function (error C2668). Example:
void function();
namespace ns {
void function();
// or:
// using ::function;
}
using ns::function;
// or:
// using namespace ns;
void call() {
function();
}
Since we anticipate that using-declarations or even using-directives are common
use, STLport by default doesn't import or wrap functions that exist in both the
global namespace and namespace std, in particular those are functions with C
origin like fopen() or abs(). Also, it defines additional overloads for
functions like abs() (overloaded for int, long, float, double, long double) in
the global namespace.
In order to make STLport include them in the std namespace, you can define the
_STLP_DO_IMPORT_CSTD_FUNCTIONS macro. Doing so, you will have to explicitely
scope all your functions calls like std::abs() though - otherwise you only get
the global abs(int) from the C library.

51
sdk/lib/3rdparty/stlport/doc/README.utf8 vendored Normal file
View file

@ -0,0 +1,51 @@
Here is a description of how you can use STLport to read/write utf8 files.
utf8 is a way of encoding wide characters. As so, management of encoding in
the C++ Standard library is handle by the codecvt locale facet which is part
of the ctype category. However utf8 only describe how encoding must be
performed, it cannot be used to classify characters so it is not enough info
to know how to generate the whole ctype category facets of a locale
instance.
In C++ it means that the following code will throw an exception to
signal that creation failed:
#include <locale>
// Will throw a std::runtime_error exception.
std::locale loc(".utf8");
For the same reason building a locale with the ctype facets based on
UTF8 is also wrong:
// Will throw a std::runtime_error exception:
std::locale loc(locale::classic(), ".utf8", std::locale::ctype);
The only solution to get a locale instance that will handle utf8 encoding
is to specifically signal that the codecvt facet should be based on utf8
encoding:
// Will succeed if there is necessary platform support.
locale loc(locale::classic(), new codecvt_byname<wchar_t, char, mbstate_t>(".utf8"));
Once you have obtain a locale instance you can inject it in a file stream to
read/write utf8 files:
std::fstream fstr("file.utf8");
fstr.imbue(loc);
You can also access the facet directly to perform utf8 encoding/decoding operations:
typedef std::codecvt<wchar_t, char, mbstate_t> codecvt_t;
const codecvt_t& encoding = use_facet<codecvt_t>(loc);
Notes:
1. The dot ('.') is mandatory in front of utf8. This is a POSIX convention, locale
names have the following format:
language[_country[.encoding]]
Ex: 'fr_FR'
'french'
'ru_RU.koi8r'
2. utf8 encoding is only supported for the moment under Windows. The less common
utf7 encoding is also supported.

94
sdk/lib/3rdparty/stlport/doc/README.wince vendored Normal file
View file

@ -0,0 +1,94 @@
Programming under MS Windows CE with STLport
=============================================
This is supposed to give an overview for programming on MS Windows CE, with and
partially without STLport, what tools are available and what common pitfalls
exist. Note that for every supported compiler there is another readme file which
explains the specifics of that compiler.
Available compilers:
---------------------
- Embedded Visual C++ 3 (eVC3): this IDE/compiler is for the CE3 target platforms.
The included compiler is MSC12, the same as for VC6, so many workarounds for its
'features' apply here, too. STLport works out of the box with this.
- Embedded Visual C++ 4 (eVC4): basically the same as eVC3, but it can compile for
CE4.x and 5. Note that currently (2007-03-06) I haven't tested this with CE5,
because you can use a better compiler using VC8/VS2005. This compiler can be
downloaded for free from the MS website, including a product activation key.
STLport works out of the box with this.
- Visual C++ 8 (VC8) aka Visual Studio 2005 (VS2005): with this version (and
partially already version 7) the embedded and desktop IDEs have been merged again,
so it supports compiling for MS Windows CE, versions 5 and later. Note that the
freely downloadable express edition does not(!) allow compiling for CE. This IDE
uses MSC14 as compiler. STLport works out of the box with CE5.
- Platform Builders (PB): this tool is used to create a CE image. You can select the
modules (e.g. Explorer, but also C++ RTTI) you include in the image. These IDEs use
several different compilers (MSC12-14). STLport hasn't been tested with this
IDE, AFAIK.
- There used to be an addon for VC6(?) that allowed compiling for CE. This plugin
has been superceeded by eVC3/4 and support for it has been removed from STLport in
version 5.
- Others: some vendors (e.g. Intel) provide compilers that are able to generate
CE executables. I'm not aware of an attempt to compile STLport with them.
Environment specialties:
-------------------------
- In order to develop for a platform, the first thing you need is a so-called SDK.
This package includes headers and libraries that (more or less) resemble the APIs
available on the device. The IDEs come with a basic selection of SDKs, but in
general you need to retrieve an according SDK from the vendor. If you are the
vendor, you can generate an SDK for a platform with Platform Builder.
- The provided API is typically a subset of the 'normal' win32 API. Often, some
features are simply not supported, like security descriptors when opening files.
Also, these APIs are only supported for wchar_t strings, e.g. only CreateFileW()
and not CreateFileA().
- CE doesn't have a current directory, hence no relative paths to that dir. You can
have relative parts in global paths though.
- CE doesn't have environment variables, thus STLport can't support e.g.
setenv/getenv. It also doesn't attempt to provide workarounds.
- Since many features are optional (see the description of Platform Builder), it
is possible that you don't have e.g. a console that std::cout could write to. The
same applies to exceptions (see e.g. the add-on lib for RTTI for eVC4). Other
features might go amiss, too. This makes it hard for STLport to adapt to, in
particular because this information is not available outside PB, a header might
declare a function that in fact is not present. Keep this in mind when you get
linker errors.
- The supplied C++ standard library is extremely cut down, e.g. iostreams and
locales are missing completely.
- The supplied standard C API is at best rudimentary. Functions like e.g. time() or
clock() are declared but not defined. STLport doesn't include any workarounds for
these missing functions at present.
- All compilers are cross-compilers, i.e. you run them on a win32 host and they
produce executable code for the target platform. The same applies to the debugger,
which is connected via serial, USB or ethernet. Alternatively, there are emulators
that run on the host machine and simulate the target platform.
- The entrypoint for executables is generally WinMain. Normally, you would have
switched to a normal main() using /SUBSYSTEM:CONSOLE on the linker commandline.
The linkers for at least CE4 and 5 don't understand this switch, they claim it
conflicts with CE targets. Instead, set the entrypoint directly to
mainACRTStartup.
- The name of a DLL loaded via an import library can't be longer than 32 chars. If
this is not the case, the application will behave as if the DLL was not present or
couldn't be loaded for whatever other reason. This limitation applies to at least
CE 4 and 5.

55
sdk/lib/3rdparty/stlport/doc/README.windows vendored Normal file
View file

@ -0,0 +1,55 @@
Note for Windows users:
It is highly recommended to declare the Windows OS version you are
targetting when building the library as well as when using it. You can do so
thanks to the well known Microsoft macros WINVER, _WIN32_WINDOWS or
_WIN32_WINNT, see your platform SDK documentation for a description
of those macros and how to use them. To define it when building the
library, use the configure script --extra-cxxflag option. Here is the
configuration to build STLport using Visual Studio 2005 and targetting
Windows XP:
configure -c msvc8 --extra-cxxflag "/D_WIN32_WINNT=0x0501"
If you do not declare it at build time STLport will adapt to the PSDK in
use, windows.h gives a default value to WINVER. However, when using the
library, windows.h is not necessarily included, at least not by STLport
internally, so none of the macros are defined which will result in an
inconsistency in the build process which most of time will generate undefined
behavior at runtime.
Here is the main reason for following this advise, the Windows 95
compatibility issue:
Because of a modification in the behavior of the Win32 API functions
InterlockedIncrement and InterlockedDecrement after Windows 95, STLport
libraries built for Windows 95 cannot be used to generate an application
built for Windows XP for instance. So, if you build STLport with a Windows
95 PSDK, STLport will be ready for Windows 95. If you then use it without
defining _WIN32_WINDOWS to signal Windows 95 compatibility, STLport will
consider that it can use latest Windows OS features like the new
InterlockedIncrement and InterlockedDecrement functions which change the
memory footprint of some internal STLport objects making it incompatible
with the libraries built for Windows 95.
Normally, doing so wouldn't generate any compilation or link error, you
would only experiment undefined behavior at runtime. In order to make this
problem more obvious STLport forces a link time error in debug mode (_DEBUG
macro defined).
Unresolved symbol will be:
- 'building_for_at_least_windows98_but_library_built_for_windows95'
if you are trying to use STLport libraries built for Windows 98 or later
to generate an application targetting the Windows 95 platform.
- 'building_for_windows95_but_library_built_for_at_least_windows98'
if you are trying to use STLport libraries built for Windows 95 to generate
an appliation targetting the
Windows XP platform for instance.
Of course, targetting the latest Windows OS versions will give you the best
performance from STLport. This is why when none of the platform macros are
defined STLport consider that there is no minimum OS requirement and will
use the latest API functions. There is only one exception to this behavior,
the SwitchToThread function that is used only if you define _WIN32_WINNT to a
value higher or equal to 0X0400.

82
sdk/lib/3rdparty/stlport/doc/build_system.txt vendored Normal file
View file

@ -0,0 +1,82 @@
The STLport build system
========================
This is a basic overview of the STLport build system. At the moment, I'm only familiar
with the working of the nmake variant, i.e. for MSVC, eVC and ICC/win32, other variants
may differ.
Overview:
----------
There are three basic classes to consider while building:
1. The used make tool (currently that is make (GNU make) an nmake (Microsoft)).
2. The used compiler
3. The target type, either application or library
Other than that, there are three different settings corresponding to the three different
STLport modes, 'release', 'debug' and 'STLdebug' and each one has two modes for either
static or dynamic linking.
The whole build system lies under the build/ dir of the source tree. There, it first
branches to Makefiles/ (which contains the base of the build system) and to lib/ (which
contains files to build the STLport library) and test/ (which contains files to build
tests) (TODO: what is the misc/ folder for?).
Under Makefiles/, you see the initially mentioned branching according to the build tool.
Here is also where the configure.bat file puts the generated config.mak file. (TODO:
what are the other files in that folder?)
nmake:
-------
Under nmake/, you then find the common support files for the different compilers and
files that define generic rules. Here, it then splits into app/ and lib/, which are
structured similar to each other and to the common nmake/ dir. In each dir you have
files for the different compilers that are used to make application specific or library
specific settings.
The branching in the three STLport modes and the static/dynamic linking is not visible
in the file structure but only in the used nmake variables.
In order to make clear which file includes which other file, here an example when
compiling the STLport library for eVC4. The call issued is 'nmake /f evc4.mak' in the
build/lib folder. From there, the following include tree is created:
build/lib/evc.mak
build/Makefiles/config.mak ; generated by configure.bat
build/Makefiles/nmake/top.mak
build/Makefiles/config.mak
build/Makefiles/nmake/sysid.mak
build/Makefiles/nmake/sys.mak
build/Makefiles/nmake/evc4.mak ; evc4 from config
build/Makefiles/nmake/evc-common.mak
build/Makefiles/nmake/targetdirs.mak
build/Makefiles/nmake/extern.mak
build/Makefiles/nmake/targets.mak
build/Makefiles/nmake/rules-o.mak
build/Makefiles/nmake/clean.mak
build/Makefiles/nmake/lib/top.mak ; would be app/top.mak when building an application
build/Makefiles/nmake/lib/macro.mak
build/Makefiles/nmake/lib/evc4.mak ; evc4 from config
build/Makefiles/nmake/lib/evc-common.mak
build/Makefiles/nmake/lib/rules-so.mak
build/Makefiles/nmake/lib/rules-a.mak
build/Makefiles/nmake/lib/rules-install-so.mak
build/Makefiles/nmake/lib/rules-install-a.mak
build/Makefiles/nmake/lib/clean.mak
TODO: build/Makefiles/config.mak is included both by build/lib/evc.mak and by
build/Makefiles/nmake/top.mak.
Known issues:
--------------
- nmake: MSC doesn't support generating dependency information for makefiles. So, unless
you modify the direct source file for an object file, no recompilation is triggered! You
need to either delete all object files that need to be recompiled or 'make clean'
- There are targets to only install e.g. the shared STLdebug version but there is no
such thing for making clean. This would be useful in the context of above issue for
making a selective clean only.

90
sdk/lib/3rdparty/stlport/doc/pointer_specialization.txt vendored Normal file
View file

@ -0,0 +1,90 @@
********************************************************************
* This document describe the STLport container pointer *
* specialization feature. *
********************************************************************
What is it for:
The major problem of template code is the potentialy huge binary
size that can result from the compilation. Each template type
instanciation is a new type from the compiler point of view even if
the generated binaries are identicals. To avoid this binary duplication
STLport grant the partial pointer specialization for 4 containers:
- vector
- deque
- list
- slist
How does it work:
The pointer specialization consists in using a void* container
instanciation for any container of pointers, including pointers
to cv qualified types. So the container pointer specializations
are only bridges that forward all the method calls to the
underlying void* container instanciation. The bridge job is to
cast the pointer type to and from the void* type.
Why only those 4 containers:
Some of you might wonder why none of the associative containers
or hash containers has been specialized. Lets take the set container
as an example. Its declaration is
template <class _Tp,
class _Compare = less<_Tp>,
class _Alloc = allocator<_Tp> >
class set;
In a first thought you can imagine a partial specialization like
the following:
template <class _Tp, class _Compare, class _Alloc>
class set<_Tp*, _Compare, _Alloc>
What would be the underlying container for such a partial
specialization? The _Alloc type is supposed to have a rebind member
method so you can easily find the _VoidAlloc type. The _Compare type,
on the other hand, do not have this kind of Standard requirements.
So you need to wrap the _Compare type within a _WrapCompare type
that will take care of all the cast work. The underlying container
type will be:
set<void*, _WrapCompare<_Tp, _Compare>, _VoidAlloc>
The problem of such a type is that it is still dependent on the
original _Tp type for the _WrapCompare instanciation. So each set
instanciation will have a distinct underlying void* container and
we fall back on a binary duplication trouble.
On a second thought a possible solution is to limit the partial
specialization like that:
template <class _Tp, class _Alloc>
class set<_Tp*, less<_Tp*>, _Alloc>
We only specialized the set container if the comparison functor
is the Standard less struct. The underlying container would be:
set<void*, less<void*>, _VoidAlloc>
It looks fine but it is wrong. Actually a STL user is free to
specialized the less struct for any pointer type even the basic one.
In such a situation the client would think that the set is ordered
according its own functor but will finally have a set ordered according
the less<void*> functor. The less specialization issue also show that
the underlying cannot be a
set<void*, less<void*>, _VoidAlloc>
but will have to be a
set<void*, __less<void*>, _VoidAlloc>
where __less would be equivalent to the standard less functor but
would not be specializable because unreachable from the client code.
There is of course a solution for this specialization issue. We
need to be able to detect the less specialization. The partial set
specialization would have to be used only if the less functor is
the default STLport implementation based on the strict ordering operator.
No doubt that a solution to this problem will be soon found.

133
sdk/lib/3rdparty/stlport/doc/stlport_namespaces.txt vendored Normal file
View file

@ -0,0 +1,133 @@
This document present the STLport namespace schema and give additionnal
information about how STLport replace the native C++ Standard library
coming with your compiler.
1. What is the STLport namespace ?
As STLport is a C++ Standard library implementation the STLport namespace
is 'std'. In normal use this is all you need to know and you can stop reading
here.
2. How does STLport replace native C++ Standard library ?
STLport defines a macro 'std' that replaces all references of std in the
user code by a different name. This technique has has some drawback but also
advantages. The drawback is that you cannot declared Standard component like
that:
//foo.h
namespace std
{
template <class _Tp>
class allocator;
}
void f1(const std::allocator<int>&);
//foo.cpp
#include "foo.h"
#include <memory>
void f1(const std::allocator<int>& alloc)
{
//implementation
}
//bar.cpp
#include "foo.h"
#include <memory>
int main(int, char**)
{
std::allocator<int> alloc;
f1(alloc);
}
If you build this code you will surely have a compilation error as f1 is declared
as taking a std::allocator parameter but you are calling it using an STLport allocator
instance that is not in the std namespace. The good news is that this drawback is easy
to detect as it will generate compilation error or at least link time error. The only
workaround is to include an arbitrary Standard header before the allocator declaration.
Good candidates for that are <utility> or <cerrno> as they are small headers. Including
those headers will replace std with the STLport namespace.
The advantage of this macro replacement is that we can customize the STLport namespace
depending on the compilation options. For instance the STLport safe mode you can use by
defining _STLP_DEBUG is not binary compatible with a normal debug build. To ensure that
no one will ever build code without _STLP_DEBUG and link with STLport library built with
this option the namespace is different so that it will generate link time error rather
than random crashes during application execution.
3. Why not having use namespace injection ?
An other way to replace native Standard C++ library implementation would have been to
use namespace injection:
namespace std
{
using namespace stlport;
}
This solution has a first major drawback which is that STLport would be much more sensible
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 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
{
template <class _Tp>
struct less
{
bool operator () (const _Tp& x, const _Tp& y) const;
};
}
//User code:
struct MyStruct;
namespace std
{
template <>
struct less<MyStruct>
{
};
}
As you can see the specialization is not in the STLport less namespace and it
won't be used in associative containers for instance.
4. What is the STLport specific namespace ?
The official STLport namespace is: stlport. Once again this is not the real namespace
where all the Standard stuff are. As the real STLport namespace change depending on compilation
options you cannot use it directly. So stlport is an alias of the real STLport namespace.
5. What are the other STLport namespaces ?
Those names are given for information purpose and should never be used in any user code. The
default STLport namespace is: stlp_std. Here is the list of the customized namespaces:
- stlpd_std : when _STLP_DEBUG is defined
- stlpx_std : when you use STLport as a shared library linked to the static version of the native
runtime or when you build the static STLport library linked with the dynamic version. This option
is only supported by a limited number of compilers.
- stlpmtx_std : when building STLport as not thread safe.
You can also have combination of those extension like stlpdxmtx_std or stlpdmtx_std...
There is also an other STLport namespace for STLport internal functions or struct/class: priv.
namespace stlport
{
namespace priv
{
}
}