[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
GNU Common C++ platform notes
From: |
David Sugar |
Subject: |
GNU Common C++ platform notes |
Date: |
Fri, 25 Apr 2003 09:29:46 -0400 |
User-agent: |
KMail/1.5 |
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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- GNU Common C++ platform notes,
David Sugar <=