GNU Common C++ platform notes

[David Sugar]

These were my platform specific notes on different targets, and where problems 
exist:

                working         shared c++      thread          can build
platform        c++ compiler    libs                    support         plugins

gnu/linux       y                       y                       pthread         
y
freebsd y                       y                       pthread         y
netbsd  y                       y                       (1.7+ pthread)  y
cygwin  y                       y                       pthread         ? no ?
mingw32 y                       y                       win32           unknown
win32   y                       y                       win32           untested
macosx  y                       glbl ctors fail pthread         y
solaris y                       (ver issues)    pthread         y

additional notes:

"can build plugins" means both support for dlopening (or equiv) of 
object modules, and the ability to actually compile and contruct 
C++ stand-alone plugin modules.

"thread support" at the moment means either pthread or win32.

"shared c++ libs" means it can build shared libraries from c++ without
any issues (note, macosx has issues...).

"working c++ compiler" means a generally functional standard conformant
compiler (since most of these use gcc, that is usually not an issue), 
AND the ability to complete the autoconf/automake tests we use.  It
generally means Common C++ configure produces a usable result.

platform specific notes:

macosx:

There are problems with building C++ shared libraries which have 
global objects that have contructors which must be executed when the 
library is loaded.  I have seen reference to the fact that C++ shared 
libraries are loaded in multiple sections rather than at once.  Perhaps
there is a linker option to fix this.

netbsd:

cvs current (and ?1.7? or ?2.0?) promise pthread support.

cygwin:

using the -module option for libtool seems broken in current cygwin; it 
fails to build a target dso plugin, but rather tries to build a .exe, 
and wants all link references resolved.

There may be other issues related to shortcommings of the OMF format, 
particularly related to relative relocations of sized objects in global 
space.

some thread unittest programs do not exit, so there may be issues in cygwin 
pthreads.

mingw32:

we use a seperate "makefile.gcc" to build things here rather than depend 
on autoconf/automake, and use dll tools expressedly.  The 
"makefile.gcc" is build for the mingw32 cross compiler supplied with
Debian.

There may be other issues related to shortcommings of the OMF format,
particularly related to relative relocations of sized objects in global
space.

win32:

There are native .dsp projects to build win32 targets rather than using 
automake/autoconf.  These are built with the native visual studio 
compiler.

Building a plugin through a .dsp has never been tested, but other things 
have generally been confirmed as working.

solaris:

There are odd issues that come up between SunOS/Solaris, and between 
specific Solaris releases, that autoconf/automake macros currently do 
not fully resolve.