Alexandre Lision | ddd731e | 2014-01-31 11:50:08 -0500 | [diff] [blame] | 1 | Generic & Embedded Targets: |
| 2 | |
| 3 | By default, UCommon compiles with full support of C++ and the C++ ansi |
| 4 | library. For deeply embedded targets, the stdc++ library (libstdc++ for |
| 5 | gcc) can be disabled, along with exception handling and other C++ |
| 6 | features that may add to runtime overhead. This is done using the |
| 7 | --disable-stdcpp configure option. Any modern C++ compiler and posix |
| 8 | platform with basic pthread support should be able to build UCommon |
| 9 | successfully. |
| 10 | |
| 11 | Whether UCommon is compiled with or without c++ ansi library support, it |
| 12 | should still be possible to mix and match UCommon code with software |
| 13 | that is built with standard C++ runtimes. However, note that when std |
| 14 | c++ is disabled, in addition to stripping out some library routines |
| 15 | which depend on the C++ ansi library, exception handling and rtti is |
| 16 | also disabled for the ucommon library. |
| 17 | |
| 18 | When using only static linking, the c++ ansi libraries are also disabled |
| 19 | by default. This is to prevent bloat from static linkage of the ansi |
| 20 | C++ library and static linkage is most common on embedded targets. The |
| 21 | --enable-stdcpp option can be used to re-enable the full ansi c++ |
| 22 | library. |
| 23 | |
| 24 | Project Indiana/OpenSolaris specific notes: |
| 25 | |
| 26 | You need to install SUNWhea or configure will fail on the preprocessor. |
| 27 | You can use the Sun Studio 12 compiler as well as gcc. When building |
| 28 | without Sun std c++ support (--disable-stdcpp), -lCrun is added alone |
| 29 | without -lCstd. |
| 30 | |
| 31 | To make autogen.sh work (or svn checkout) requires a bunch of packages |
| 32 | and setting the AUTOMAKE_SUFFIX="-1.10". You need |
| 33 | SUNWgnome-common-devel, SUNWgm4, SUNWgmake, SUNWaconf, |
| 34 | SUNWautomake-1.10, and SUNWlibtool. |
| 35 | |
| 36 | Microsoft Windows & MingW32 specific notes: |
| 37 | |
| 38 | For Microsoft Windows targets, we primarily focus on using debian hosted |
| 39 | mingw32 cross-builds. Since libstdc++ is statically linked, we use the |
| 40 | c model and build the ucommon subset by default, as otherwise software |
| 41 | that uses plugins would be hugely bloated. Full libstdc++ support can |
| 42 | always be re-enabled explicitly using --enable-stdcpp. |
| 43 | |
| 44 | It should be possible to build ucommon using Microsoft native compilers, and if |
| 45 | people wish to submit patches for code changes based on using native Microsoft |
| 46 | compilers, they will be accepted so long as they do not break other build |
| 47 | environments. Native Microsoft Visual studio files may be generated using |
| 48 | cmake. We do not recommend the use of proprietary compilers on proprietary |
| 49 | operating systems, and we will continue to work to make the debian hosted mingw |
| 50 | build environment as effective for building our packages as we can. |
| 51 | |
| 52 | Support for older GCC (<3.x): |
| 53 | |
| 54 | UCommon, like GNU Common C++, is meant to compile anywhere a C++ |
| 55 | compiler exists. However, there are specific limitations in gcc < 3, |
| 56 | particularly in relation to namespace support. For this reason, we |
| 57 | disable libstdc++ support by default, although again it can be enabled |
| 58 | using --enable-stdcpp. |
| 59 | |
| 60 | QNX (Neutrino) Hosts & Targets: |
| 61 | |
| 62 | QNX distributes and uses both gcc 2.95.3 and 3.3.1, but the latter is |
| 63 | only with the latest 6.3.x series release. The userland build tools are |
| 64 | old and broken for svn checkout to automake build, including libtool |
| 65 | 1.4.x. Nontheless we are able to support direct hosting and builds of |
| 66 | ucommon on QNX. Those using tarballs from official distributions should |
| 67 | not have these problems. |
| 68 | |
| 69 | Since gcc 2.95 is the default, the default builds without stdc++. Even |
| 70 | worse, if you enable libstdc++ (--enable-stdcpp), the resulting |
| 71 | executables will compile and link, but will fail at runtime with symbol |
| 72 | link errors. However, executables built and linked with ucommon with |
| 73 | stdcpp disabled do link and run fine (and the "make check" tests will |
| 74 | pass). Strange. |
| 75 | |
| 76 | Minix and other non-pthread posix targets: |
| 77 | |
| 78 | Starting with 1.8.1, uCommon will optionally build with GNU pth. This |
| 79 | can be used to establish uCommon C++ threaded design architecture on |
| 80 | platforms which do not natively support true threading, such as Minix. |
| 81 | On platforms that attempt to simulate threading with user mode non |
| 82 | pre-emptive threading, it is recommended to use uCommon with GNU pth |
| 83 | even if there is a local library that simulates pthread functionality. |
| 84 | The reason is that uCommon also wraps and schedules I/O operations |
| 85 | through the pth I/O functions. |
| 86 | |
| 87 | Recent Platforms and Versions Tested: |
| 88 | |
| 89 | GNU/Linux gcc 6.0.0 x86, x86_64, arm, mipsel |
| 90 | GNU/Linux clang 6.0.0 x86_64 |
| 91 | OpenBSD4 6.0.0 i386 |
| 92 | NetBSD5 4.0.0 i386 |
| 93 | OpenSolaris sunwpro 6.0.0 x86_64 (double) conv of DateTime fails, |
| 94 | applog.cpp std::map failure |
| 95 | OS/X 6.0.0 ppc, x86 |
| 96 | QNX (gcc 2.95) 1.8.1 i386 |
| 97 | MingW/cross 6.0.0 i386, x86 ipv6 broken in wine unit tests |
| 98 | Cygwin 1.8.0 i386 |
| 99 | |