Porting State


My intention is to port the STLplus library to as many platforms as I can reasonably support.

SourceForge, which hosts STLplus, used to provide a Compile Farm so that I could test STLplus on different platforms. So in the past, the library collection has been extensively tested on a wide range of platforms. This enabled me, for example, to fix problems with data persistence on 64-bit CPUs and to provide a MacOS port. Unfortunately, the Compile Farm has now been withdrawn, so I can only test the library on my own Windows PC and on virtual machines for Free BSD and Gnu/Linux variants. However, this setup means that I can still test against a range of compiler/platform combinations, including gcc on Gnu/Linux and Free BSD, gcc on Windows using the Cygwin Unix emulator, Windows native builds using Visual Studio and Windows native builds using the MinGW version of the gcc compiler.

Porting Status

There are a number of porting issues to be overcome:

Different Operating Systems

One of the objectives of this library is to provide platform-independent access to operating system services that differ between platforms. The idea is to hide the implementation behind a common interface. By writing software to that interface, you automatically get portable software. At least, that is the theory.

STLplus has been built on the following Operating Systems:

  • Any modern version of Windows
    • NT
    • 2000
    • XP
    • 7
    • 8
    • 10
  • Any distribution of Gnu/Linux
    • gNewSense
    • Ubuntu
    • Cygwin (Gnu/Linux emulation on Windows)
    • Debian
    • RedHat
    • Suse
  • Any BSD derivative
    • Open BSD
    • Net BSD
    • Free BSD
  • other Unix-like OSs
    • Solaris
  • MacOS - which is also really a BSD derivative
    • X (Darwin)
Different CPU Architectures

Different CPUs have different word lengths, different byte ordering and different integer type definitions. The intention is that STLplus will work with all variations of these characteristics that I come across.

STLplus has been built on the following CPUs:

  • Intel Pentium 686 (32-bit)
  • Intel Pentium x86_64 (64-bit)
  • AMD Opteron (64-bit)
  • IBM OpenPower (32-bit)
  • DEC Alpha (64-bit)
  • Sun Sparc (32-bit)
  • Power PC (32-bit)
  • Power PC (64-bit)
Different Compilers

The concept of portability usually means portability between operating systems, not necessarily portability between compilers. However, to cater for different tastes in compilers, I have supported as many as I have access to.

It is also important that software will build with different versions of each compiler, because I have no control over which compiler you are using and there's a good chance that you don't either. The STLplus library should ideally work in whatever development environment you have chosen (within reason). So, STLplus works with different releases of these compilers, not just the latest one. On the other hand, STLplus requires a good implementation of templates and so this limits the range of compilers supported.

STLplus has been built on the following compilers:

  • Visual Studio
  • Gnu gcc
    • v2, v2.95 onwards - tried on v2.95
    • v3 - tried on v3.3, v3.4
    • v4 - tried on v4.3 to 4.9
    • v5 - tried on v5.2
  • Borland
    • v5.8 (Turbo C++ 2006 Explorer)

On each operating system there are a number of different combinations of development environments available:

  • Windows 32-bit build
    • Visual Studio (WIN32 target)
    • Native Windows (WIN32 target) using gnu gcc on MinGW
    • GNU/Linux emulation on Windows (WIN32 target) using gnu gcc on Cygwin
    • Borland
  • Windows 64-bit build
  • all Gnu/Linux - 32-bit and 64-bit
    • gnu gcc
  • all BSD derivatives
    • gnu gcc
  • MacOS X
    • gnu gcc

I refer to a "platform" as a particular combination of CPU, Operating System, Word Length (32 or 64 bit) and Compiler.

These requirements create some limitations on the extent of the library - the primary objective is for it to be portable such that it presents exactly the same interface on all platforms. This means that I do not have anything that cannot be implemented on all platforms with all supported compilers.

For example there's no Unicode support because some compilers have little or no support for Unicode and there are major differences in how Unicode is implemented on different operating systems. There are other libraries that deal with this issue better than I can and so I consider it beyond the scope of the STLplus library to resolve it.

Porting Testing

If you can confirm the library works on any other platform or compiler combination, please let me know the details - Compiler, Compiler version, OS, CPU etc.

The following table shows the platforms that STLplus3 has been tested on.

Porting State
Platform Build State
CPU Bits OS Compiler Version Name -D1 Tested Passed Notes
Intel 686 64 Ubuntu Gnu/Linux gcc 5.4.0 GNULINUX-x86_64 2017-01-13 27/27
Intel 686 32 Ubuntu Gnu/Linux gcc 4.6.3 GNULINUX-i686 2013-06-22 27/27
Intel 686 32 Windows 10 gcc 4.8.1 (MinGW) MINGW-i686 _WIN32 2015-11-05 27/27
Intel 686 64 Windows 10 gcc 5.1.0 MINGW-x86_64 _WIN64 2017-01-13 27/27 TDM 64-bit version of gcc
Intel 686 32 Windows 7 gcc 4.8.2 (Cygwin) CYGWIN-i686 CYGWIN 2014-04-28 27/27
Intel 686 64 Windows 10 gcc 5.4.0 (Cygwin64) CYGWIN-x86_64 CYGWIN 2017-01-13 27/27
Intel 686 64 Windows 10 Microsoft Visual Studio 2015 x64 _WIN64 2017-01-13 27/27
Intel 686 32 Windows 10 Microsoft Visual Studio 2015 Win32 _WIN32 2017-01-13 27/27
Intel 686 64 TrueOS gcc 4.9.4 FREEBSD-amd64 2017-01-13 27/27 TrueOS used to be PC-BSD which is a distro of FreeBSD, Built using Gnu compiler even though PC-BSD uses Clang by default.
Intel 686 32 PC-BSD v9 gcc 4.2.1 FREEBSD-i686 2015-12-04 26/27 One test failed because shared_ptr not supported on gcc 4.2.
Intel 686 32 Windows XP Borland 6.31 - Turbo C++ Builder N/A _WIN32 2011-02-15 27/27
Intel 686 64 gNewSense Gnu/Linux gcc 4.4.5 GNU-x86_64 2013-12-11 25/27 Old compiler so no support for shared_ptr. Dynalinker test failed, but only because no 64-bit DLL available to load

Note 1: The -D directive is a C macro that selects between different implementations of code for different platforms. For example, a Windows application will use different system calls to a Unix application. The correct directive for the platform must be defined for the STLplus library to build on the target platform. Typically this is set as an option to the compiler - for example with the gcc compiler you would specify "gcc -DSOLARIS" when building on Solaris. The _WIN32 value that selects the Windows native build is set automatically by the compilers so you don't have to do this. If no -D directive is shown, then the default build is a generic Unix build and needs no special rules. See the documentation on building the library for more on this.