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
> the -y compatability flag (so bison doesn't produce yacc-style output
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
> 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
> 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
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.
> of the regex test suite don't compile* and other parts seem to hang**.
> of the python tests also don't compile***. The thread tests work, but
> 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,
> line with the flags used by mingw-tools.jam (otherwise the shared
> that jam produces export libgcc symbols, causing multiple definitions
> 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
> 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.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk