nocygwin toolset (was: Re: Contributing new toolset support)

From: Raoul Gough (raoulgough_at_[hidden])
Date: 2002-05-07 14:00:01

"David Abrahams" <david.abrahams_at_[hidden]> wrote in message
news:13f201c1f1cc$cc15fce0$6401a8c0_at_boostconsulting.com...
(originally on the boost developers list)

> ----- Original Message -----
> From: "Raoul Gough" <RaoulGough_at_[hidden]>
[snip stuff about doing -mno-cygwin support]
> > Turning on this option also means providing a replacement standard
> library,
> > in my case STLport,
>
> Hmm, I didn't know that. Why won't the usual one work?

Firstly my apologies for the late follow-up. Partly caused by getting to
grips with CVS for the first time, so that I'm working on the latest
versions.

The problem is that the gcc library binaries were not compiled with
the -mno-cygwin option, and are therefore dependant on the cygwin
Unix-compatability layer (cygwin.dll or some such). I guess you might be
able to use the cygwin-gcc standard library by explicitly linking to the
cygwin dll, but this kind of defeats the whole idea of having a native Win32
executable :-)

>
> > and seems to make building a working boost jam pretty
> > difficult.
>
> You don't need to rebuild jam for every compiler you want to use it
> with...

Yes, I see now that there are precompiled-binaries available. That could
have saved me some fun earlier on :-) The cygwin jam build seems to be
broken, because it attempts to use bison as a yacc substitue without using
the -y compatability flag (so bison doesn't produce yacc-style output file
names).

>
> > I think the best way to go is to introduce a new toolset name
> > (e.g. NOCYGWIN) which does all the necessary stuff.
>
> I'm reluctant to make changes to Boost.Build v1, but a new toolset
> doesn't seem like a big problem. However, I hope you are using the
> "extends-toolset" rule as with gcc-stlport-tools.jam.

I'm now trying to do that, but am having some difficulties. What I've got so
far is a new gcc-nocygwin-tools.jam which contains the following:

-------------------
GCC_STLPORT_LIB_ID = mingw32 ;

extends-toolset gcc-stlport ;

flags gcc-nocygwin CFLAGS : -mno-cygwin ;
flags gcc-nocygwin C++FLAGS : -fvtable-thunks ; # Note 1
flags gcc-nocygwin LINKFLAGS : -mno-cygwin ;
flags gcc-nocygwin LINKFLAGS <threading>multi : -mthreads -v ;
-------------------

I had to hack the gcc-stlport-tools.jam to prevent it overwriting the value
in GCC_STLPORT_LIB_ID (and set it before doing extends-toolset). I guess
this is not the right way to do it, but naively trying something like

flags gcc-nocygwin GCC_STLPORT_LIB_ID : mingw32 ;

didn't seem to have any effect. I'm open to better informed suggestions.

Note 1. -fvtable-thunks is how I build STLport and all executables. This
provides compatability with COM and DirectX. Some users probably do this,
others probably don't. I'm not sure how to make this configurable.

Also, I haven't been able to confirm completely that the build works. Parts
of the regex test suite don't compile* and other parts seem to hang**. Parts
of the python tests also don't compile***. The thread tests work, but only
because I hacked my libgcc.a to include thread-safe versions of _eh.o and
frame.o *and* removed the "-Wl,--export-all-symbols" from gcc-tools.jam, in
line with the flags used by mingw-tools.jam (otherwise the shared libraries
that jam produces export libgcc symbols, causing multiple definitions during
final linking).

So I have a number of questions, and any help would be appreciated:

Do the regex and python test suites currently compile, or are they broken
for everyone?

Is the export-all-symbols really needed for cygwin, and (if so) how should I
override it for the special case?

Thanks,
Raoul Gough.

* example regex test build error:

g++ -c -Wall -ftemplate-depth-100 -DBOOST_REGEX_NO_LIB=1 -DTEST_UNICODE=1
-DBOOST_RE
GEX_STATIC_LINK=1 -D_STLP_DEBUG -g -O0 -fno-inline -D_STLP_USE_DYNAMIC_LIB
-mno-cygwin -
mno-cygwin -fvtable-thunks -I"..\..\..\libs\regex\test" -I"." -I"..\..\.."
-isystem "f:/
stlport/STLport-4.5.3\stlport" -o
"..\..\..\libs\regex\test\bin\wregress.exe\gcc-nocygwin
\debug\runtime-link-dynamic\tests.obj" "regress\tests.cpp"

In file included from regress\tests.cpp:27:
regress/regress.h:423: `w32_regex_traits' undeclared in namespace `boost'
regress/regress.h:423: parse error before `>'
regress\tests.cpp: In function `void run_tests()':
regress\tests.cpp:653: `re_type' undeclared (first use this function)
regress\tests.cpp:653: (Each undeclared identifier is reported only once
regress\tests.cpp:653: for each function it appears in.)
regress\tests.cpp:653: parse error before `('
regress\tests.cpp:654: `e' undeclared (first use this function)
...failed gcc-C++-action
..\..\..\libs\regex\test\bin\wregress.exe\gcc-nocygwin\debug\runt
ime-link-dynamic\tests.obj...

** e.g. posix_api_check hangs somewhere in
c_regex_traits<char>::sentry::sentry (possibly in re_message_update?). At
first glance with the debugger, it looks like BOOST_HAS_THREADS is defined,
which seems a bit odd, since the reentrant exception handler stuff didn't
get linked (probably no -mthreads during link).

*** example python test build problems:

g++ -c -Wall -ftemplate-depth-100 -DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHO
N_V2 -DBOO
ST_PYTHON_SOURCE -D_STLP_DEBUG -g -O0 -fno-inline -D_STLP_USE_DYNAMIC_LIB -
mno-cygwin -f
vtable-thunks -I"..\..\..\libs\python" -I"f:\boost\CVS\boost" -I"f:\Python2
1\include" -I"
f:\Python21\PC" -isystem "f:/stlport/STLport-4.5.3\stlport" -o
"..\..\..\libs\python\bin
\bpl.dll\gcc-nocygwin\debug\runtime-link-dynamic\class.obj"
"..\..\..\libs\python\src/obj
ect\class.cpp"

In file included from
f:/boost/CVS/boost/boost/python/converter/type_id.hpp:9,
from
f:/boost/CVS/boost/boost/python/converter/registry.hpp:8,
from ..\..\..\libs\python\src/object\class.cpp:6:
f:/boost/CVS/boost/boost/python/detail/indirect_traits.hpp:11:
boost/mpl/select_type.hpp:
No such file or directory
In file included from
f:/boost/CVS/boost/boost/python/converter/registry.hpp:8,
from ..\..\..\libs\python\src/object\class.cpp:6:
f:/boost/CVS/boost/boost/python/converter/type_id.hpp:13:
boost/mpl/select_type.hpp: No su
ch file or directory
...failed gcc-C++-action
..\..\..\libs\python\bin\bpl.dll\gcc-nocygwin\debug\runtime-link-
dynamic\class.obj...
gcc-C++-action
..\..\..\libs\python\bin\bpl.dll\gcc-nocygwin\debug\runtime-link-dynamic\fu
nction.obj

g++ -c -Wall -ftemplate-depth-100 -DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHO
N_V2 -DBOO
ST_PYTHON_SOURCE -D_STLP_DEBUG -g -O0 -fno-inline -D_STLP_USE_DYNAMIC_LIB -
mno-cygwin -f
vtable-thunks -I"..\..\..\libs\python" -I"f:\boost\CVS\boost" -I"f:\Python2
1\include" -I"
f:\Python21\PC" -isystem "f:/stlport/STLport-4.5.3\stlport" -o
"..\..\..\libs\python\bin
\bpl.dll\gcc-nocygwin\debug\runtime-link-dynamic\function.obj"
"..\..\..\libs\python\src/
object\function.cpp"

..\..\..\libs\python\src/object\function.cpp: In function `static void
boost::python::obje
cts::function::add_to_namespace(const boost::python::ref &, const char *,
const boost::pyt
hon::ref &)':
..\..\..\libs\python\src/object\function.cpp:93: `struct _typeobject' has no
member named
`tp_dict'
..\..\..\libs\python\src/object\function.cpp: At top level:
..\..\..\libs\python\src/object\function.cpp:207: excess elements in
aggregate initializer

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com