[Boost-users] Re: Building boost threads with MinGW

From: Raoul Gough (RaoulGough_at_[hidden])
Date: 2003-09-27 05:58:35

"Jeremy Godfrey" <jngcomp_at_[hidden]> writes:

> Hi Raoul,
>
> Here's my compiler details:
>
> $ g++ -v
> Reading specs from C:/msys/1.0/mingw/bin/../lib/gcc-lib/mingw32/3.2.3/specs
> Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
> --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads
> --disable-nls --enable-languages=c++,f77,objc --disable-win32-registry
> --disable-shared --enable-sjlj-exceptions
> Thread model: win32
> gcc version 3.2.3 (mingw special 20030504-1)
>
> Anyway, I have now managed to get a build of boost threads that
> depends on mingwm10.dll by editing gcc-tools.jam to compile and link
> with -mthreads. My guess is that there's a jam option to do that
> anyway but I'm not very familiar with jam.

Are you building with -sTOOLS=mingw? That activates the mingw-specific
Jamfile that tells it (among other things) that multi-threaded
libraries need -mthreads (have a look at
tools/build/mingw-tools.jam). Here's the batch file that I use to
rebuild when necessary:

rem --- for use in the /CVS/boost/boost directory ---
set PYTHON_ROOT=f:/Python22
set PYTHON_VERSION=2.2
tools\build\jam_src\bin.ntx86\bjam -d2 -sTOOLS=mingw -sALL_LOCATE_TARGET=d:\build\boost

The -d2 option is very handy - it dumps the raw commands before
execution, so you can see exactly what compiler options are being
used.

>
> I took a look at your bug report and it strikes me that it could be an
> undefined behaviour issue because initialization of the reference fails.

That's an interesting view point. I would think that the reference
doesn't actually exists until the initializer has finished execution
(which it doesn't because of the exception). I can't find anything
explicit to this effect in the standard, but section 3.8 (object
lifetime) is probably relevant - the temporary object never comes into
existence, because its constructor doesn't complete, and [hands waving
in the air here] well, the reference binding never starts.

Using an analogy, you wouldn't except undefined behaviour from the
following:

void foo() {
  throw 1;
  int const &ref = 4; // Never reached
}

Getting slightly off-topic here, of course. Follow-ups to
comp.lang.c++.moderated?

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)