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

From: Raoul Gough (raoulgough_at_[hidden])
Date: 2002-05-08 10:41:41

> From: "David Abrahams" <david.abrahams_at_[hidden]>
>
>
> ----- 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.

Actually, it turns out not to be that simple on NT. The backslash path
separator causes enormous problems when jam runs things through the cygwin
shell. The easiest way is to get a native NT-style jam that runs things via
batch files. I managed to build jam.exe using -mno-cygwin and -DNT, but it
wasn't trivial IIRC.

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

Thanks for that - it fixes the jam.exe build. Unfortunately, it turns out
that jam_src/Jambase and allyourjambase.jam both set JAMSHELL as follows:

JAMSHELL ?= sh -c ;

For some reason, this ends up with execunix.c using "sh -c" as argv[0]
instead of splitting it into "sh" and "-c" in argv[1]. The obvious
consequence is that the bin.cygwinx86/jam.exe can't execute anything at all.
I fixed this by removing both JAMSHELL assignments, and the (correct)
default unix behaviour takes over. Then the gcc build actually works on
my cygwin installation. This lack of string splitting might indicate some
underlying problem, however I can't understand why the jam files would
set JAMSHELL to sh -c, seeing as this is what execunix does by default
anyway.

BTW, allyourjambase.jam also sets yacc incorrectly for CYGWIN, so it might
make sense to update this inline with jam_src/Jambase (even though it isn't
currently needed).

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

An admirable goal. I'd currently be happy if I could get gcc-nocygwin to
work in isolation :-)

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

I'm starting to think that almost nobody uses cygwin with boost at all, in
which case I'd be inclined to leave it hard-coded.

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

I've located the problem with the regex tests, which I'll detail on the
boost developers list. Re python, I'm having problems with includes from
the mpl subdirectory (seems that the stuff is now in detail/...) What am I
missing?

e.g.

f:/boost/CVS/boost/boost/python/detail/indirect_traits.hpp:11:
boost/mpl/select_type.hpp:
No such file or directory

Where select_type.hpp is actually in boost/detail

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

I guess if needs be, I can cut-and-paste a modified link action into
gcc-nocygwin-tools.jam (which is what seems to have happened with
mingw-tools.jam).

Regards,
Raoul Gough.

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