Re: [jamboost] nocygwin toolset (was: Re: Contributing new toolset support)

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-05-07 16:01:47

----- Original Message -----
From: "Raoul Gough" <raoulgough_at_[hidden]>

> > 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 has nothing to do with it. You only need to recompile it once per
platform you're running it on. The toolset files handle the rest.

> 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).

Hmm. Easily fixed...
done in CVS.

> > > 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.

This kind of thing is going to stay very hack-ish until we get Boost.Build
v2 out; it's one of the problems we're trying to address with the
re-design.

The thing to be sure of when making your hack is that your system works
when there are multiple toolsets in use. IOW

-sTOOLS="gcc-stlport gcc-nocygwin gcc"
-sTOOLS="gcc-nocygwin gcc-stlport gcc"
-sTOOLS="gcc-stlport gcc gcc-nocygwin"
-sTOOLS="gcc-nocygwin gcc gcc-stlport"
-sTOOLS="gcc gcc-stlport gcc-nocygwin"
-sTOOLS="gcc gcc-nocygwin gcc-stlport"

should all work.

> 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.

There's always the <cxxflags>-fvtable-thunks property for tweaks like this.
Else you can define your own special-purpose feature.

> 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?

Python compiles and runs that's my baby.

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

I don't know anymore. It seemed to be needed for some versions at least...
ah, now I remember. The Boost.Python library used to use declspecs with
Cygwin, but at least some versions of Cygwin failed to build it properly in
that configuration, so I had to go to the Unix export model.

-Dave