boost/config/suffix.hpp: spurious BOOST_HAS_THREADS with g++ 3.4
While testing gcc 3.4 (on a x86 PC running Linux), I encountered linker errors due to missing pthread symbols, even though my program is single threaded. I found that some translation units using boost::shared_ptr included boost/detail/lwm_nop.hpp whereas other translation units included boost/detail/lwm_pthreads.hpp. I didn't observe any errors with gcc 3.3.x. The problem turns out to be that gcc 3.4 defines the preprocessor variable _REENTRANT if certain standard library headers are included even if the compiler is *not* called with the '-pthread' command line option. The following test exhibits this behavior and shows that it causes BOOST_HAS_THREADS to be erroneously defined in boost/config/suffix.hpp if, e.g., the standard header string is included: cludwig@lap200:~/C++/gcc3.4/tmp> g++ -v Lese Spezifikationen von /opt/gcc/gcc-3.4.0/lib/gcc/i686-pc-linux-gnu/3.4.0/specs Konfiguriert mit: ../gcc-3.4.0/configure --prefix=/opt/gcc/gcc-3.4.0 --enable-threads=posix --enable-version-specific-runtime-libs --enable-languages=c,c++ --enable-__cxa_atexit --enable-c-mbchar --enable-concept-checks --enable-libstdcxx-debug --enable-c99 --enable-libstdcxx-pch Thread-Modell: posix gcc-Version 3.4.0 cludwig@lap200:~/C++/gcc3.4/tmp> cat test-BOOST_HAS_THREADS.cc #if defined(WITH_STRING_HEADER) # include <string> #endif #include <boost/config.hpp> #if defined(__MT__) # warning "__MT__ defined" #endif #if defined(_MT) # warning "_MT defined" #endif #if defined(_REENTRANT) # warning "_REENTRANT defined" #endif #if defined(_PTHREADS) # warning "_PTHREADS defined" #endif #if defined(BOOST_HAS_THREADS) # warning "BOOST_HAS_THREADS defined" #endif cludwig@lap200:~/C++/gcc3.4/tmp> g++ -c -I ../boost_1_31_0/ test-BOOST_HAS_THREADS.cc cludwig@lap200:~/C++/gcc3.4/tmp> g++ -c -I ../boost_1_31_0/ -DWITH_STRING_HEADER test-BOOST_HAS_THREADS.cc test-BOOST_HAS_THREADS.cc:16:4: Warnung: #warning "_REENTRANT defined" test-BOOST_HAS_THREADS.cc:24:4: Warnung: #warning "BOOST_HAS_THREADS defined" I have no idea what the gcc developers recommend in order to detect multi-threading support or if this should be reported to the gcc developers as a bug. But it will certainly break many programs using Boost. A user can work around this problem by either including boost/config.hpp before any other headers (even Boost headers since boost/lexical_cast.hpp, for example, includes string before boost/config.hpp). Or the user builds everything with MT-support, even if the program itself is single threaded. Neither workaround is satisfying. Regards Christoph PS: FWIW, I could trace back the problem to a change in include/c++/i686-pc-linux-gnu/bits/gthr-default.h. This change was discussed in http://gcc.gnu.org/ml/gcc-patches/2003-07/msg01607.html. -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html
On Mon, May 10, 2004 at 12:14:59PM +0200, Christoph Ludwig wrote:
The problem turns out to be that gcc 3.4 defines the preprocessor variable _REENTRANT if certain standard library headers are included even if the compiler is *not* called with the '-pthread' command line option.
I believe this is only when GCC is configured with posix threads (either explicitly with --enable-threads=posix, or implicitly on POSIX systems where the default threading model is pthreads). If you explicitly configure with --enable-threads=single (or the equivalent --disable-threads) then _REENTRANT won't be defined, and boost/config.hpp correctly detects that threads are disabled. This doesn't help solve your problem, of course.
The following test exhibits this behavior and shows that it causes BOOST_HAS_THREADS to be erroneously defined in boost/config/suffix.hpp if, e.g., the standard header string is included:
[snip]
I have no idea what the gcc developers recommend in order to detect multi-threading support or if this should be reported to the gcc developers as a bug. But it will certainly break many programs using Boost.
I've been meaning to get around to asking that on the gcc list. Unfortunately gcc.gnu.org seems to be down today. GCC provides the inline __gthread_active_p() to tell if if the program is linked to the pthread library, but I don't know how to give the same info to the preprocessor at compile time.
A user can work around this problem by either including boost/config.hpp before any other headers (even Boost headers since boost/lexical_cast.hpp, for example, includes string before boost/config.hpp). Or the user builds everything with MT-support, even if the program itself is single threaded. Neither workaround is satisfying.
Or (as I've been doing) explicitly defining BOOST_DISABLE_THREADS when you know your program is single threaded.
PS: FWIW, I could trace back the problem to a change in include/c++/i686-pc-linux-gnu/bits/gthr-default.h. This change was discussed in http://gcc.gnu.org/ml/gcc-patches/2003-07/msg01607.html.
FWIW the google cache version of that is here: http://tinyurl.com/2xksr jon -- "He who joyfully marches to music in rank and file has already earned my contempt. He has been given a large brain by mistake, since for him the spinal cord would fully suffice." - Albert Einstein
On Mon, May 10, 2004 at 12:17:57PM +0100, Jonathan Wakely wrote:
On Mon, May 10, 2004 at 12:14:59PM +0200, Christoph Ludwig wrote:
I have no idea what the gcc developers recommend in order to detect multi-threading support or if this should be reported to the gcc developers as a bug. But it will certainly break many programs using Boost.
I've been meaning to get around to asking that on the gcc list. Unfortunately gcc.gnu.org seems to be down today.
It's up again. I posted the question to the gcc-help list (http://gcc.gnu.org/ml/gcc-help/2004-05/msg00099.html). Hopefully we will get an answer that enables us to make the BOOST_HAS_THREADS detection more reliable.
A user can work around this problem by either including boost/config.hpp before any other headers (even Boost headers since boost/lexical_cast.hpp, for example, includes string before boost/config.hpp). Or the user builds everything with MT-support, even if the program itself is single threaded. Neither workaround is satisfying.
Or (as I've been doing) explicitly defining BOOST_DISABLE_THREADS when you know your program is single threaded.
Well, I missed the most obvious workaround again! :-/ Thanks Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html
Christoph Ludwig wrote:
On Mon, May 10, 2004 at 12:17:57PM +0100, Jonathan Wakely wrote:
On Mon, May 10, 2004 at 12:14:59PM +0200, Christoph Ludwig wrote:
I have no idea what the gcc developers recommend in order to detect multi-threading support or if this should be reported to the gcc developers as a bug. But it will certainly break many programs using Boost.
I've been meaning to get around to asking that on the gcc list. Unfortunately gcc.gnu.org seems to be down today.
It's up again. I posted the question to the gcc-help list (http://gcc.gnu.org/ml/gcc-help/2004-05/msg00099.html). Hopefully we will get an answer that enables us to make the BOOST_HAS_THREADS detection more reliable.
Maybe, you should ask the question on the main gcc list, or maybe even file a bug. After all, the situation is with earlier gcc version, it was possible to reliably detect if -pthread is specified and enable MT code in Boost. Now it's not possible, so as far as Boost is concerned, it's a regression in 3.4. And BTW, you're not the only one which sees the problem. It seems that Neal Becker has the same problem with the program_options library. - Volodya
It looks as though _GLIBCXX_HAVE_GTHR_DEFAULT is defined by the std lib when it's in thread safe mode, so I'm leaning towards adding: #ifdef __GLIBCXX__ // gcc 3.4 and greater: #ifdef _GLIBCXX_HAVE_GTHR_DEFAULT #define BOOST_HAS_THREADS #else #define BOOST_DISABLE_THREADS #endif #endif To our libstdcpp3.hpp config file, which I think will take care of it, albeit not in a way that everyone will appreciate (it will force threading on whenever the std lib is also thread safe). Thoughts? John.
John Maddock wrote:
It looks as though _GLIBCXX_HAVE_GTHR_DEFAULT is defined by the std lib when it's in thread safe mode, so I'm leaning towards adding:
#ifdef __GLIBCXX__ // gcc 3.4 and greater: #ifdef _GLIBCXX_HAVE_GTHR_DEFAULT #define BOOST_HAS_THREADS #else #define BOOST_DISABLE_THREADS #endif #endif
To our libstdcpp3.hpp config file, which I think will take care of it, albeit not in a way that everyone will appreciate (it will force threading on whenever the std lib is also thread safe).
Ehm... I don't think Linux has single-threaded and multi-threaded versions of libstdc++ -- there's only one library installed and it's sure will be multi-threaded. So, for single threaded builds 1. Boost will think it's MT build and call pthread_* functions. 2. Toolset won't add '-pthread' to linker command line Bottom like: you'll get link failures for single-thread builds. - Volodya
On Wed, May 12, 2004 at 02:56:49PM +0400, Vladimir Prus wrote:
John Maddock wrote:
It looks as though _GLIBCXX_HAVE_GTHR_DEFAULT is defined by the std lib when it's in thread safe mode, so I'm leaning towards adding:
#ifdef __GLIBCXX__ // gcc 3.4 and greater: #ifdef _GLIBCXX_HAVE_GTHR_DEFAULT #define BOOST_HAS_THREADS #else #define BOOST_DISABLE_THREADS #endif #endif
To our libstdcpp3.hpp config file, which I think will take care of it, albeit not in a way that everyone will appreciate (it will force threading on whenever the std lib is also thread safe).
Ehm... I don't think Linux has single-threaded and multi-threaded versions of libstdc++ -- there's only one library installed and it's sure will be multi-threaded.
That's the default - but it is possible to configure the library without thread-safety (use --disable-threads or --enable-threads=single when compiling/configuring the library) in which case neither _REENTRANT nor _GLIBCXX_HAVE_GTHR_DEFAULT will be defined, and John's suggestion works. I'm in the middle of writing a longer reply. I think Boost's current configuration for GCC 3.4 will fail if libstdc++ is configured with non-default options or on platforms that don't use pthreads.
So, for single threaded builds 1. Boost will think it's MT build and call pthread_* functions. 2. Toolset won't add '-pthread' to linker command line
Bottom like: you'll get link failures for single-thread builds.
That's the current situation anyway, for GCC 3.4 Boost interprets _REENTRANT as meaning you're compiling a multithreaded app, but in 3.4 _REENTRANT is defined unconditionally if the compiler's thread model is "posix" (which you can see in the output of "gcc -v") jon -- "Keep away from people who try to belittle your ambitions. Small people always do that, but the really great make you feel that you, too, can become great." - Mark Twain
It looks as though _GLIBCXX_HAVE_GTHR_DEFAULT is defined by the std lib when it's in thread safe mode, so I'm leaning towards adding:
#ifdef __GLIBCXX__ // gcc 3.4 and greater: #ifdef _GLIBCXX_HAVE_GTHR_DEFAULT #define BOOST_HAS_THREADS #else #define BOOST_DISABLE_THREADS #endif #endif
To our libstdcpp3.hpp config file, which I think will take care of it, albeit not in a way that everyone will appreciate (it will force threading on whenever the std lib is also thread safe).
Ehm... I don't think Linux has single-threaded and multi-threaded versions of libstdc++ -- there's only one library installed and it's sure will be multi-threaded.
Not quite, it's determined by how you installed and configured the compiler whether it's thread safe or not, hense the check, at the very least if it's not thread safe then we'd better not turn on threading support whatever.
So, for single threaded builds 1. Boost will think it's MT build and call pthread_* functions. 2. Toolset won't add '-pthread' to linker command line
Bottom like: you'll get link failures for single-thread builds.
We can fix that: we already have platforms/toolsets where the default, in fact the *only* behaviour is for builds to be thread safe, even if you specify <threading>single. I think the problem here is that we have two options for the <threading> variant, but really we should have three: 1) threading must be on 2) threading must be off 3) whatever the default is for the compiler Most people actually want option (3) a lot of the time, and currently that's what <threading>single more or less gives you, ideally though we would map builds for option 3 to either 1 or 2 so we don't build libraries we've actually already built. This happens at the moment for example with MSVC where <runtime-link>dynamic implies <threading>multi, and any other option for the <threading> variant gets ignored. John.
John Maddock wrote:
Ehm... I don't think Linux has single-threaded and multi-threaded versions
of
libstdc++ -- there's only one library installed and it's sure will be multi-threaded.
Not quite, it's determined by how you installed and configured the compiler whether it's thread safe or not, hense the check, at the very least if it's not thread safe then we'd better not turn on threading support whatever.
That kind of check is okay.
So, for single threaded builds 1. Boost will think it's MT build and call pthread_* functions. 2. Toolset won't add '-pthread' to linker command line
Bottom like: you'll get link failures for single-thread builds.
We can fix that: we already have platforms/toolsets where the default, in fact the *only* behaviour is for builds to be thread safe, even if you specify <threading>single.
I really don't think we want to disable <threading>signle for such a popular platform.
I think the problem here is that we have two options for the <threading> variant, but really we should have three:
1) threading must be on 2) threading must be off 3) whatever the default is for the compiler
Most people actually want option (3) a lot of the time,
Actually, I just don't want to pay for MT, unless I really mean to use the code in MT environment.
and currently that's what <threading>single more or less gives you, ideally though we would map builds for option 3 to either 1 or 2 so we don't build libraries we've actually already built.
I don't really understand the problem. For example, are there any compilers which generate MT code by default? And, what's "default for the compiler"?
This happens at the moment for example with MSVC where <runtime-link>dynamic implies <threading>multi, and any other option for the <threading> variant gets ignored.
And what's the problem with that? - Volodya
On Thu, May 13, 2004 at 01:22:13PM +0400, Vladimir Prus wrote:
So, for single threaded builds 1. Boost will think it's MT build and call pthread_* functions. 2. Toolset won't add '-pthread' to linker command line
Bottom like: you'll get link failures for single-thread builds.
We can fix that: we already have platforms/toolsets where the default, in fact the *only* behaviour is for builds to be thread safe, even if you specify <threading>single.
I really don't think we want to disable <threading>signle for such a popular platform.
That's why we need G++ to define something whenever -pthread is given on the command line. There's currently nothing suitable in GCC 3.4. Ideally it would be defined for all platforms, since x86-linux isn't the only non-windows system :) Some platforms (e.g. NetBSD) automatically define _PTHREADS when -pthread is given. It might be possible to do that for all systems. But there might be good reasons not to.
I think the problem here is that we have two options for the <threading> variant, but really we should have three:
1) threading must be on 2) threading must be off 3) whatever the default is for the compiler
Most people actually want option (3) a lot of the time,
Actually, I just don't want to pay for MT, unless I really mean to use the code in MT environment.
I understand (3) to mean MT when -pthread is given, single otherwise.
and currently that's what <threading>single more or less gives you, ideally though we would map builds for option 3 to either 1 or 2 so we don't build libraries we've actually already built.
I don't really understand the problem. For example, are there any compilers which generate MT code by default? And, what's "default for the compiler"?
The problem is that boost (currently) assumes you're compiling a MT app if you use GCC 3.4, so the preprocessed output refers to the pthread_* functions (which means G++ 3.4 _with_boost_ compiles MT by default) which then causes linker errors if you didn't use -pthread. If you manually define BOOST_DISABLE_THREADS then Boost doesn't refer to the pthread_* functions and you don't need to give -pthread. jon -- "A foolish consistency is the hobgoblin of little minds..." - Ralph Waldo Emerson
I think the problem here is that we have two options for the <threading> variant, but really we should have three:
1) threading must be on 2) threading must be off 3) whatever the default is for the compiler
Most people actually want option (3) a lot of the time,
Actually, I just don't want to pay for MT, unless I really mean to use the code in MT environment.
and currently that's what <threading>single more or less gives you, ideally though we would map builds for option 3 to either 1 or 2 so we don't build
I understand that, but we have to decide how to handle this, so that it is actualy safe, and in particular boost headers should honor the compilers default setting. libraries
we've actually already built.
I don't really understand the problem. For example, are there any compilers which generate MT code by default? And, what's "default for the compiler"?
Yes, lots of them, MSVC when using a dll runtime, some Unix compilers I believe (though I forget which ones, can probably find out if it's important), gcc on some platforms as well. Actually with gcc you already "pay" for threading support in the standard lib, likewise with MSVC, if you really want it turned off in Boost, then defining BOOST_DISABLE_THREADS will do the trick. What I'm trying to say is that our default behaviour should be the same as the compiler and std lib in use, any thing else will lead to confusion IMO.
This happens at the moment for example with MSVC where <runtime-link>dynamic implies <threading>multi, and any other option for the <threading> variant gets ignored.
And what's the problem with that?
You build the same library twice - for example with MSVC the <threading>multi<runtime-link>dynamic and <threading>single<runtime-link>dynamic variants are the actually the same thing (as far as the binaries are concerned), but both get built separately by a Boost install. John.
John Maddock wrote:
Actually, I just don't want to pay for MT, unless I really mean to use the code in MT environment.
I understand that, but we have to decide how to handle this, so that it is actualy safe, and in particular boost headers should honor the compilers default setting.
I think I'm confused over what's "default setting" is, and if it important. I think the point is that 1. User should be able to specify if boost libraries should be thread-safe 2. He should do this with a minimum of effort. This is especially important for compile-only library So, if compiler has an option to tell if application should be build in MT mode, *that option* should affect thread safety of boost libraries. It's actually not very related to MT-safety of standard lib.
I don't really understand the problem. For example, are there any
compilers
which generate MT code by default? And, what's "default for the compiler"?
Yes, lots of them, MSVC when using a dll runtime,
Do you mean, when using /MD switch? But I believe default switch is /ML? So, there are two switches which mean "I'm building MT code": /MT and /MD, but none of those are default.
some Unix compilers I believe (though I forget which ones, can probably find out if it's important), gcc on some platforms as well.
Ok, on those platform we'd need to be thread-safe uncondionally.
Actually with gcc you already "pay" for threading support in the standard lib,
But that might be not so much, compared to say, locking in every place where shared_ptr is used in code.
likewise with MSVC, if you really want it turned off in Boost, then defining BOOST_DISABLE_THREADS will do the trick. What I'm trying to say is that our default behaviour should be the same as the compiler and std lib in use, any thing else will lead to confusion IMO.
Quite the contrary, I think we need to respect compiler switches, but not library settings. Anyway, this is only important if we can get gcc to reliable report -pthread presense.
This happens at the moment for example with MSVC where <runtime-link>dynamic implies <threading>multi, and any other option for the <threading> variant gets ignored.
And what's the problem with that?
You build the same library twice - for example with MSVC the <threading>multi<runtime-link>dynamic and <threading>single<runtime-link>dynamic variants are the actually the same thing (as far as the binaries are concerned), but both get built separately by a Boost install.
Ok, understood. - Volodya
On Tue, May 18, 2004 at 04:13:43PM +0400, Vladimir Prus wrote:
John Maddock wrote:
Actually, I just don't want to pay for MT, unless I really mean to use the code in MT environment.
I understand that, but we have to decide how to handle this, so that it is actualy safe, and in particular boost headers should honor the compilers default setting.
I think I'm confused over what's "default setting" is, and if it important. I think the point is that 1. User should be able to specify if boost libraries should be thread-safe 2. He should do this with a minimum of effort. This is especially important for compile-only library
So, if compiler has an option to tell if application should be build in MT mode, *that option* should affect thread safety of boost libraries. It's actually not very related to MT-safety of standard lib.
That's exactly what the previous config that relied on _REENTRANT was supposed to do. (It was imperfect since not all platforms defined the macro when -pthread was given - it only really worked for Linux and a few other platforms) And if a new macro such as __GXX_PTHREADS is added for GCC 3.4.1 then I assume it's exactly what the new Boost config will try to do too.
Quite the contrary, I think we need to respect compiler switches, but not library settings. Anyway, this is only important if we can get gcc to reliable report -pthread presense.
Which should happen for 3.4.1. In any case Boost should document that you need to explicitly define BOOST_DISABLE_THREADS if using GCC 3.4.0 and you don't want MT. jon -- "He who knows does not speak. He who speaks does not know." - Lao Tze
Jonathan Wakely wrote:
Quite the contrary, I think we need to respect compiler switches, but not library settings. Anyway, this is only important if we can get gcc to reliable report -pthread presense.
Which should happen for 3.4.1.
That's good. Did gcc developers decided to add this? Do you have link to email thread (if any)? - Volodya
On Tue, May 18, 2004 at 05:17:23PM +0400, Vladimir Prus wrote:
Jonathan Wakely wrote:
Quite the contrary, I think we need to respect compiler switches, but not library settings. Anyway, this is only important if we can get gcc to reliable report -pthread presense.
Which should happen for 3.4.1.
That's good. Did gcc developers decided to add this? Do you have link to email thread (if any)?
Only the bug tracker, which is here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953 Wolfgang Bangerth had no objection to the idea of a __GXX_PTHREADS macro defined when -pthread is given, and Andrew Pinski targeted the bug for GCC 3.4.1 - so it looks to me as though they're happy with it and a fix will land before the next compiler release. I've been meaning to prepare a patch myself (after digging through the relevant files and figuring out how they work) but all my GCC time in the last few days has been spent fixing libstdc++'s implementation of the boost concept checks (which were also broken in 3.4.0). jon -- "A thing is not necessarily true because a man dies for it." - Oscar Wilde
Jonathan Wakely wrote:
Only the bug tracker, which is here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953
Thanks for the link!
Wolfgang Bangerth had no objection to the idea of a __GXX_PTHREADS macro defined when -pthread is given, and Andrew Pinski targeted the bug for GCC 3.4.1 - so it looks to me as though they're happy with it and a fix will land before the next compiler release.
Ok, seems like the problem will be solved. - Volodya
On Wed, May 19, 2004 at 10:33:15AM +0400, Vladimir Prus wrote:
Jonathan Wakely wrote:
Only the bug tracker, which is here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953
Thanks for the link!
Wolfgang Bangerth had no objection to the idea of a __GXX_PTHREADS macro defined when -pthread is given, and Andrew Pinski targeted the bug for GCC 3.4.1 - so it looks to me as though they're happy with it and a fix will land before the next compiler release.
Ok, seems like the problem will be solved.
Unfortunately, Mark Mitchell postponed yesterday the resolution of PR#11953 until gcc 3.4.2. I think that it's therefore imperative that users of g++ 3.4.x are told about this problem and possible workarounds. I am unsure. though, where this information should go. If I am not mistaken then libs/config/config.htm is the only page that describes in detail what can go into boost/config/user.hpp. It seems most natural to mention there that users of g++ 3.4.x (on linux systems, at least) should define BOOST_DISABLE_THREADS if they don't build their programs with `-pthread'. But this page is somewhat hidden and the language on more/getting_started.html#Additional_Steps may stop many linux users from reading libs/config/config.htm at all. So we need a notice at a more prominent place. Any suggestions? Another idea: How about adding a #warning to boost/config/compiler/gcc.hpp if: * the compiler version is >= 3.4.0 * the platform is linux (maybe other platforms, too? I don't know how they are affected.) * _REENTRANT is defined * the user didn't explicitly define either BOOST_DISABLE_THREADS or BOOST_HAST_THREADS This could save boost users upgrading to gcc 3.4.x a lot of time chasing linker errors. Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html
Another idea: How about adding a #warning to boost/config/compiler/gcc.hpp if: * the compiler version is >= 3.4.0 * the platform is linux (maybe other platforms, too? I don't know how they are affected.) * _REENTRANT is defined * the user didn't explicitly define either BOOST_DISABLE_THREADS or BOOST_HAST_THREADS
Will do, the patch has gone into libstdcpp3.hpp (because it's the libstdc++ headers that cause the inconsistency). The behaviour should now be consistent, and there's a #warning to the effect that thread support is turned on (when it is that is). John.
On Sat, Jun 19, 2004 at 04:53:36PM +0200, Christoph Ludwig wrote:
Unfortunately, Mark Mitchell postponed yesterday the resolution of PR#11953 until gcc 3.4.2.
And 3.4.1 has now been released, which means both 3.4.0 and 3.4.1 have this problem.
I think that it's therefore imperative that users of g++ 3.4.x are told about this problem and possible workarounds.
I agree.
Another idea: How about adding a #warning to boost/config/compiler/gcc.hpp if: * the compiler version is >= 3.4.0 * the platform is linux (maybe other platforms, too? I don't know how they are affected.) * _REENTRANT is defined * the user didn't explicitly define either BOOST_DISABLE_THREADS or BOOST_HAST_THREADS
This could save boost users upgrading to gcc 3.4.x a lot of time chasing linker errors.
Personally I like this idea. I think the inconvenience of a warning is worth tolerating given the confusion this problem could cause. The problem is present on non-linux platforms. I first noticed it on FreeBSD. The warning could give the URL of the page that explains the problem, to avoid excessive output from the preprocessor. jon -- "He who joyfully marches to music in rank and file has already earned my contempt. He has been given a large brain by mistake, since for him the spinal cord would fully suffice." - Albert Einstein
On Wed, May 12, 2004 at 11:35:15AM +0100, John Maddock wrote:
It looks as though _GLIBCXX_HAVE_GTHR_DEFAULT is defined by the std lib when it's in thread safe mode, so I'm leaning towards adding:
#ifdef __GLIBCXX__ // gcc 3.4 and greater: #ifdef _GLIBCXX_HAVE_GTHR_DEFAULT #define BOOST_HAS_THREADS #else #define BOOST_DISABLE_THREADS #endif #endif
To our libstdcpp3.hpp config file, which I think will take care of it, albeit not in a way that everyone will appreciate (it will force threading on whenever the std lib is also thread safe).
That's the current behaviour anyway - if the library was configured to be threadsafe then _REENTRANT will be defined and threading is forced on by Boost. I think your fix is an improvement, since AFAICT _REENTRANT is not defined for all threading models in GCC 3.4 (only "posix") whereas _GLIBCXX_HAVE_GTHR_DEFAULT should be defined for any thread model except "single" (which is what we want). It might be that the only option for GCC 3.4 users is to either define BOOST_DISABLE_THREADS or add -pthread to the compiler flags. Looking at the GCC sources under gcc/config/ it appears that some platforms (e.g. Solaris2, NetBSD, Linux on certain architectures) define _PTHREADS when -pthread is used. x86-linux is not one of those platforms, nor is FreeBSD. It might be possible to get that macro, or something else, defined on all platforms when -pthread is given so Boost could check for that. Cristoph, did you ever ask about this issue on the "gcc" list, or just "gcc-help" ? jon -- Atilla The Hun's Maxim: "If you're going to rape, pillage and burn, be sure to do things in that order." - P. J. Plauger, Programming On Purpose
On Wed, May 12, 2004 at 01:05:11PM +0100, Jonathan Wakely wrote: [...]
Looking at the GCC sources under gcc/config/ it appears that some platforms (e.g. Solaris2, NetBSD, Linux on certain architectures) define _PTHREADS when -pthread is used. x86-linux is not one of those platforms, nor is FreeBSD. It might be possible to get that macro, or something else, defined on all platforms when -pthread is given so Boost could check for that.
Cristoph, did you ever ask about this issue on the "gcc" list, or just "gcc-help" ?
I did only ask on gcc-help. But I'll probably file a bug report today or tomorrow; even if the gcc developers don't agree that the definition of _REENTRANT in single threaded mode is a regression, there's at least a documentation bug: The -pthread option isn't documented at all for x86-Linux. It's therefore hard to tell which preprocessor definitions are correct and what behaviour you can count on (e.g., with respect to the initialization of local static variables). Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html
On Wed, May 12, 2004 at 04:18:05PM +0200, Christoph Ludwig wrote:
On Wed, May 12, 2004 at 01:05:11PM +0100, Jonathan Wakely wrote: [...]
Looking at the GCC sources under gcc/config/ it appears that some platforms (e.g. Solaris2, NetBSD, Linux on certain architectures) define _PTHREADS when -pthread is used. x86-linux is not one of those platforms, nor is FreeBSD. It might be possible to get that macro, or something else, defined on all platforms when -pthread is given so Boost could check for that.
Cristoph, did you ever ask about this issue on the "gcc" list, or just "gcc-help" ?
I did only ask on gcc-help.
But I'll probably file a bug report today or tomorrow; even if the gcc developers don't agree that the definition of _REENTRANT in single threaded mode is a regression, there's at least a documentation bug: The -pthread option isn't documented at all for x86-Linux. It's therefore hard to tell which preprocessor definitions are correct and what behaviour you can count on (e.g., with respect to the initialization of local static variables).
I entered a report in the gcc bug database: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15415 Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html
participants (4)
-
Christoph Ludwig -
John Maddock -
Jonathan Wakely -
Vladimir Prus