Building boost threads with MinGW
Hi, When I build boost threads with bjam and MinGW, the resulting DLL is not dependent on mingwm10.dll like (as I understand things) all MinGW multithreaded binaries should be. This would indicate that the -mthreads compile/link option is not being used. Does anyone know how to fix this? Regards, Jeremy Godfrey --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.520 / Virus Database: 318 - Release Date: 18/09/2003
"Jeremy Godfrey"
Hi,
When I build boost threads with bjam and MinGW, the resulting DLL is not dependent on mingwm10.dll like (as I understand things) all MinGW multithreaded binaries should be. This would indicate that the -mthreads compile/link option is not being used. Does anyone know how to fix this?
I guess your analysis is correct - my copy of boost_thread.dll imports the function __mingwthr_key_dtor from mingwm10.dll. What does "g++ -v" report for you? $ f:/mingw/bin/g++ -v Reading specs from f:/mingw/bin/../lib/gcc-lib/mingw32/3.3.1/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,c++,f77,objc,ada,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization Thread model: win32 gcc version 3.3.1 (mingw special 20030804-1) One fix would be to download the same gcc 3.3.1 executable as I have from the mingw site (but be warned that I recently detected a bug with this compiler's sjlj exception handling - see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12298 for the gory details). If you're building gcc yourself, maybe you need to supply some of the configure options manually? -- Raoul Gough. (setq dabbrev-case-fold-search nil)
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. 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. Jeremy
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Raoul Gough Sent: 26 September 2003 12:05 To: boost-users@lists.boost.org Subject: [Boost-users] Re: Building boost threads with MinGW
"Jeremy Godfrey"
writes: Hi,
When I build boost threads with bjam and MinGW, the resulting DLL is not dependent on mingwm10.dll like (as I understand things) all MinGW multithreaded binaries should be. This would indicate that the -mthreads compile/link option is not being used. Does anyone know how to fix this?
I guess your analysis is correct - my copy of boost_thread.dll imports the function __mingwthr_key_dtor from mingwm10.dll. What does "g++ -v" report for you?
$ f:/mingw/bin/g++ -v Reading specs from f:/mingw/bin/../lib/gcc-lib/mingw32/3.3.1/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,c++,f77,objc,ada,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization Thread model: win32 gcc version 3.3.1 (mingw special 20030804-1)
One fix would be to download the same gcc 3.3.1 executable as I have from the mingw site (but be warned that I recently detected a bug with this compiler's sjlj exception handling - see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12298 for the gory details). If you're building gcc yourself, maybe you need to supply some of the configure options manually?
-- Raoul Gough. (setq dabbrev-case-fold-search nil)
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.520 / Virus Database: 318 - Release Date: 18/09/2003
"Jeremy Godfrey"
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)
participants (2)
-
Jeremy Godfrey
-
Raoul Gough