Re: [boost] Re: como toolset failures
----- Mensaje original ----- De: Bronek Kozicki <brok@rubikon.pl> Fecha: Sábado, Abril 23, 2005 9:50 pm Asunto: Re: [boost] Re: como toolset failures
Rene Rivera wrote:
Is this specific files?
I ask because there's already a facility in the como-win32 toolset for removing the --a option by specifying that certain files with <no-warn>file.cpp
I'd say that this problem seems to cripple most test results. But not all. The flag you mention should be set for all files that directly or indirectly include any of Windows headers. Which I suppose is rather large set of files. Maybe it would be good to temporarily (for one or two days) remove --a globally and then see results; my computer is running tests continously. This would give some idea how many errors might be due to Windows headers included in strict mode. Obviously this will not resolve all problems ;) as como does not support DLLs, which also means that boost.thread won't work anyway.
Before you do that, let me comment on this: the situation is probably not as bad as it seems --many libs are actually completely Windows-unaware and its associated tests fail only because they use Boost.Test, which internally includes some Windows headers. These libs are: algorithm/minmax algorithm/string assign crc disjoint_sets format functional/hash io iostreams lambda logic (tribool) math multi_array multi_index numeric/conversion numeric/interval pool property_map ptr_container random range regex serialization tokenizer tuple variant So, if we fix the problem with Boost.Test we'll get a much higher success rate. In its turn, the problem with Boost.Test seems to lie in that it includes (directly or indirectly, I don't know) the file boost/detail/interlocked.hpp, which fails as shown in http://tinyurl.com/73vvo. So I'd say fixing boost/detail/interlocked.hpp would drastically lower the failure count and would give us a much clearer view of where we really are wrt to Comeau support. Just my 2c. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
JOAQUIN LOPEZ MU?Z wrote:
Before you do that, let me comment on this: the situation is probably not as bad as it seems --many libs are actually completely Windows-unaware and its associated tests fail only because they use Boost.Test, which internally includes some Windows headers. These libs are:
iostreams
Iostreams uses windows.h a little bit, for file descriptors and memory mapped files. Jonathan
On Sat, 23 Apr 2005 14:46:18 -0600, Jonathan Turkanis wrote
JOAQUIN LOPEZ MU?Z wrote:
Before you do that, let me comment on this: the situation is probably not as bad as it seems --many libs are actually completely Windows-unaware and its associated tests fail only because they use Boost.Test, which internally includes some Windows headers. These libs are:
iostreams
Iostreams uses windows.h a little bit, for file descriptors and memory mapped files.
Just piling on....date-time uses windows.h for the high precision clocks so some things may fail as a result... Jeff
JOAQUIN LOPEZ MU?Z wrote:
So, if we fix the problem with Boost.Test we'll get a much higher success rate. In its turn, the problem with Boost.Test seems to lie in that it includes (directly or indirectly, I don't know) the file boost/detail/interlocked.hpp, which fails as shown in http://tinyurl.com/73vvo.
Indirectly. interlocked.hpp is included by shared_ptr.hpp on Windows. Comeau doesn't compile it even without --a, because it doesn't seem to recognize __stdcall. And since the functions that interlocked.hpp attempts to import from the Windows kernel are indeed __stdcall, this makes it impossible for interlocked.hpp to do its job. This can be fixed by defining BOOST_SP_DISABLE_THREADS for the Comeau toolset.
Peter Dimov wrote:
Indirectly. interlocked.hpp is included by shared_ptr.hpp on Windows. Comeau doesn't compile it even without --a, because it doesn't seem to recognize __stdcall. And since the functions that interlocked.hpp attempts to import from the Windows kernel are indeed __stdcall, this makes it impossible for interlocked.hpp to do its job.
This can be fixed by defining BOOST_SP_DISABLE_THREADS for the Comeau toolset.
Are you sure? I tried very simple program using shared_ptr and it's OK in non-strict mode, but does not compile in strict mode. The only difference is --a switch. In strict mode it chokes on interlocked.hpp header, but apparently the very same header is accepted in non-strict mode. Which would mean that without --a switch Comeau knows how to deal with __stdcall. Actually I'm pretty sure that wihout --a como can compile program than includes Windows headers, I tried it more than once. Or maybe I misunderstood something and some different experiment would be relevant (but not the one shown below)? Regards B. PS. experiment details: MSYS>cat T680.cpp #include <boost/shared_ptr.hpp> struct A {}; int main() { boost::shared_ptr<A> a = new A(); } MSYS>como -IG:\boost T680.cpp Comeau C/C++ 4.3.3 (Jan 13 2004 11:29:09) for MS_WINDOWS_x86 Copyright 1988-2003 Comeau Computing. All rights reserved. MODE:non-strict warnings microsoft C++ MSYS>como --a -IG:\boost T680.cpp Comeau C/C++ 4.3.3 (Jan 13 2004 11:29:09) for MS_WINDOWS_x86 Copyright 1988-2003 Comeau Computing. All rights reserved. MODE:strict warnings C++ "G:\boost\boost/detail/interlocked.hpp", line 52: error: identifier "dllimport" is undefined extern "C" __declspec(dllimport) long __stdcall InterlockedIncrement( long volatile * ); ^ "G:\boost\boost/detail/interlocked.hpp", line 52: warning: omission of explicit type is nonstandard ("int" assumed) extern "C" __declspec(dllimport) long __stdcall InterlockedIncrement( long volatile * ); ^ "G:\boost\boost/detail/interlocked.hpp", line 52: error: expected a "{" extern "C" __declspec(dllimport) long __stdcall InterlockedIncrement( long volatile * ); ^
Bronek Kozicki wrote:
Peter Dimov wrote:
Indirectly. interlocked.hpp is included by shared_ptr.hpp on Windows. Comeau doesn't compile it even without --a, because it doesn't seem to recognize __stdcall. And since the functions that interlocked.hpp attempts to import from the Windows kernel are indeed __stdcall, this makes it impossible for interlocked.hpp to do its job.
This can be fixed by defining BOOST_SP_DISABLE_THREADS for the Comeau toolset.
Are you sure? I tried very simple program using shared_ptr and it's OK in non-strict mode, but does not compile in strict mode. The only difference is --a switch. In strict mode it chokes on interlocked.hpp header, but apparently the very same header is accepted in non-strict mode. Which would mean that without --a switch Comeau knows how to deal with __stdcall. Actually I'm pretty sure that wihout --a como can compile program than includes Windows headers, I tried it more than once. Or maybe I misunderstood something and some different experiment would be relevant (but not the one shown below)?
No, you are right, como does compile interlocked.hpp without --a/--A. I was mistaken. However:
#include <boost/shared_ptr.hpp> struct A {}; int main() { boost::shared_ptr<A> a = new A(); }
your program is broken and should fail to compile, but doesn't. That's why I still think that it's better to define BOOST_SP_DISABLE_THREADS instead of omitting --a globally (and I'd even suggest --A.) There isn't much point testing with Comeau otherwise; the idea is to use its strictness to find bugs that other compilers miss.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov
deal with __stdcall. Actually I'm pretty sure that wihout --a como can compile program than includes Windows headers, I tried it more than once. Or maybe I misunderstood something and some different experiment would be relevant (but not the one shown below)?
No, you are right, como does compile interlocked.hpp without --a/--A. I was mistaken. However:
Note that Comeau can link together object files that were compiled in strict and non-strict modes. So it is possible to make non-__stdcall jumpers in another translation unit that call the __stdcall (etc.) Windows API functions. Non-strict mode is *considerably* less strict. It isn't just strict mode + calling convention keywords. Using non-strict mode effectively defeats the purpose of using Comeau in most cases. Regards, Paul Mensonides
Paul Mensonides wrote:
Note that Comeau can link together object files that were compiled in strict and non-strict modes. So it is possible to make non-__stdcall jumpers in another translation unit that call the __stdcall (etc.) Windows API functions.
And this is how I managed to use strict mode in Windows programs. Just use WinAPI in separate TUs.
Non-strict mode is *considerably* less strict.
Yes, I even accidentally demonstrated this :-S B.
Daniel James wrote:
Peter Dimov wrote:
There isn't much point testing with Comeau otherwise; the idea is to use its strictness to find bugs that other compilers miss.
Would intel in strict mode serve the same purpose?
I do not think so; but (assuming current Intel toolsets are not running in strict mode) I think that it could be beneficial to have one more toolset for Intel, recent version, running in strict mode. The more compilers see the code, the better chance to find a bug. But this opens question - who will run regression tests for this toolset? B.
Daniel James <daniel@calamity.org.uk> writes:
Peter Dimov wrote:
There isn't much point testing with Comeau otherwise; the idea is to use its strictness to find bugs that other compilers miss.
Would intel in strict mode serve the same purpose?
Not on Windows; they keep lots of non-conformances enabled for MS compatibility purposes, even in strict mode AFAIK. It's a bit of a mess and it's difficult to tell what you're actually getting when you start to enable the /Qwhatever switches. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Peter Dimov wrote:
your program is broken and should fail to compile, but doesn't. That's why I still think that it's better to define BOOST_SP_DISABLE_THREADS
You are right and I agree with your conclusion. But then, any test program that needs Windows API will need to compile in separate TU without --a. Threads are basically useless in como 4.3.3, because any program that depends on Boost.Threads will not compile, anyway. Below you will find another experiment B. MSYS>como --a -DBOOST_SP_DISABLE_THREADS -IG:\boost T680.cpp -oT680 Comeau C/C++ 4.3.3 (Jan 13 2004 11:29:09) for MS_WINDOWS_x86 Copyright 1988-2003 Comeau Computing. All rights reserved. MODE:strict warnings C++ "T680.cpp", line 7: error: no suitable constructor exists to convert from "A *" to "boost::shared_ptr<A>" boost::shared_ptr<A> a = new A(); ^ 1 error detected in the compilation of "T680.cpp".
Peter Dimov wrote:
This can be fixed by defining BOOST_SP_DISABLE_THREADS for the Comeau toolset.
Peter could you pls. develop fix for como-win32-tools.jam? I agree with your conclusion; probably just adding -DBOOST_SP_DISABLE_THREADS in CFLAGS (line 68) will serve the purpose. I do not want to touch it because: 1. I do not know bjamfiles and anything I do with them is just gestwork 2. I do not have access write to CVS Regards B.
Bronek Kozicki wrote:
Peter Dimov wrote:
This can be fixed by defining BOOST_SP_DISABLE_THREADS for the Comeau toolset.
Peter
could you pls. develop fix for como-win32-tools.jam? I agree with your conclusion; probably just adding -DBOOST_SP_DISABLE_THREADS in CFLAGS (line 68) will serve the purpose. I do not want to touch it because: 1. I do not know bjamfiles and anything I do with them is just gestwork 2. I do not have access write to CVS
Jamfiles are Greek to me, too. I think that what you need is to add this line: flags como-win32 CFLAGS <threading>single : -DBOOST_SP_DISABLE_THREADS ; above the <threading>multi line. Try it in your local copy, and if everything goes well and no bjam experts chime in, I'll commit it to the CVS (if approved by our release manager, of course).
Peter Dimov wrote:
Bronek Kozicki wrote:
Peter Dimov wrote:
This can be fixed by defining BOOST_SP_DISABLE_THREADS for the Comeau toolset.
could you pls. develop fix for como-win32-tools.jam? I agree with your
flags como-win32 CFLAGS <threading>single : -DBOOST_SP_DISABLE_THREADS ;
This sounds like something that should be fixed in smart_ptr, not in the build system. Would it not be better to have the smart_ptr config use BOOST_SP_DISABLE_THREADS in the case of como strict mode (assuming you can tell) so that it fixes it for everyone, not just people that use Boos.Build. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Bronek Kozicki <brok@rubikon.pl> writes:
Rene Rivera wrote:
BOOST_SP_DISABLE_THREADS in the case of como strict mode (assuming you can tell) ^^^^^^^ You can not. I asked Greg Comeau for that some time ago.
In that case shouldn't we be setting BOOST_NO_THREADS or some such macro instead of one that's particular to the smart ptr library? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Bronek Kozicki <brok@rubikon.pl> writes:
Rene Rivera wrote:
BOOST_SP_DISABLE_THREADS in the case of como strict mode (assuming you can tell) ^^^^^^^ You can not. I asked Greg Comeau for that some time ago.
In that case shouldn't we be setting BOOST_NO_THREADS or some such macro instead of one that's particular to the smart ptr library?
BOOST_DISABLE_THREADS is already being set, but shared_ptr ignores it when it detects Windows. This is because it is very common for people to link single-threaded libraries (that are thread-agnostic except for their use of shared_ptr under the covers) against a multithreaded program and vice versa. (Or it has been common in the past; the new auto link feature may fix that for Boost libraries at least.) This scheme works on every Windows compiler except como in strict mode.
In that case shouldn't we be setting BOOST_NO_THREADS or some such macro instead of one that's particular to the smart ptr library?
We do: both BOOST_DISABLE_THREADS and BOOST_DISABLE_WIN32 are set, but shared_ptr does it's own thing... John.
flags como-win32 CFLAGS <threading>single : -DBOOST_SP_DISABLE_THREADS ;
This sounds like something that should be fixed in smart_ptr, not in the build system. Would it not be better to have the smart_ptr config use BOOST_SP_DISABLE_THREADS in the case of como strict mode (assuming you can tell) so that it fixes it for everyone, not just people that use Boos.Build.
Or maybe if the threading API's are inaccessible in that build mode we should define BOOST_DISABLE_THREADS, and turn off all threading support (it's not just shared_ptr that has it's own lightweight threading support). John.
Or maybe if the threading API's are inaccessible in that build mode we should define BOOST_DISABLE_THREADS, and turn off all threading support (it's not just shared_ptr that has it's own lightweight threading support).
IMHO it's not really justified. Comeau does support multithreaded Win32 applications, even in strict mode, it just does not support including windows headers in strict mode; but then one can factor out all Win32 dependent stuff to separate TU (which is good practice, anyway) and use threads. Como compiler (current version) does not support DLLs, and this is what makes Boost.Thread inacessible to como toolset. I have a reason to believe that next version of como compiler (due soon) will support DLLs. B. -- Bronek Kozicki brok@rubikon.pl http://b.kozicki.pl/
At 11:09 AM 4/26/2005 +0100, Bronek Kozicki wrote:
....Como compiler (current version) does not support DLLs, and this is what makes Boost.Thread inacessible to como toolset. I have a reason to believe that next version of como compiler (due soon) will support DLLs.
Yes, there's a few kind of catch-22 situations going on. In short, yes, we've finally(!) begun official support of Windows programming and some minimal support has been added for use with VC++ as a backend, but does not yet include support of DLLs. Whether that can get into the next release or not is still up in the air. Existing licensees can get an alpha version of what is currently available. The plan is: minimal support, then full support incl DLLs, then some still to be determined special strict mode / Windows mode combo, then said for as many additional backends as possible/makes sense. - Greg ------- Comeau C/C++ 4.3.3: Watch for our Mac port Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90. Comeau C/C++ with Dinkumware's Libraries. Have you tried it? comeau@comeaucomputing.com http://www.comeaucomputing.com
Comeau Computing wrote:
At 11:09 AM 4/26/2005 +0100, Bronek Kozicki wrote:
....Como compiler (current version) does not support DLLs, and this is what makes Boost.Thread inacessible to como toolset. I have a reason to believe that next version of como compiler (due soon) will support DLLs.
Yes, there's a few kind of catch-22 situations going on. In short, yes, we've finally(!) begun official support of Windows programming and some minimal support has been added for use with VC++ as a backend, but does not yet include support of DLLs. Whether that can get into the next release or not is still up in the air. Existing licensees can get an alpha version of what is currently available. The plan is: minimal support, then full support incl DLLs, then some still to be determined special strict mode / Windows mode combo, then said for as many additional backends as possible/makes sense.
For shared_ptr in particular, I'd appreciate if "minimal support" includes recognizing __stdcall (and optionally __declspec(dllimport) but I think that this is not required) in strict mode so that it can import InterlockedIncrement and friends from the Windows kernel. Another alternative would be to pass the _InterlockedIncrement intrinsic to the underlying VC++ backend as-is, if possible.
At 06:04 PM 4/26/2005 +0300, Peter Dimov wrote:
Comeau Computing wrote:
At 11:09 AM 4/26/2005 +0100, Bronek Kozicki wrote:
....Como compiler (current version) does not support DLLs, and this is what makes Boost.Thread inacessible to como toolset. I have a reason to believe that next version of como compiler (due soon) will support DLLs.
Yes, there's a few kind of catch-22 situations going on. In short, yes, we've finally(!) begun official support of Windows programming and some minimal support has been added for use with VC++ as a backend, but does not yet include support of DLLs. Whether that can get into the next release or not is still up in the air. Existing licensees can get an alpha version of what is currently available. The plan is: minimal support, then full support incl DLLs, then some still to be determined special strict mode / Windows mode combo, then said for as many additional backends as possible/makes sense.
For shared_ptr in particular, I'd appreciate if "minimal support" includes recognizing __stdcall (and optionally __declspec(dllimport) but I think that this is not required) in strict mode so that it can import InterlockedIncrement and friends from the Windows kernel. Another alternative would be to pass the _InterlockedIncrement intrinsic to the underlying VC++ backend as-is, if possible.
The minimal support mentioned above was for non-strict mode. Anyway, we're favoring the former for now for a new combo strict mode when that bridge is crossed. - Greg ------- Comeau C/C++ 4.3.3: Watch for our Mac port Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90. Comeau C/C++ with Dinkumware's Libraries. Have you tried it? comeau@comeaucomputing.com http://www.comeaucomputing.com
Comeau Computing wrote:
At 06:04 PM 4/26/2005 +0300, Peter Dimov wrote:
For shared_ptr in particular, I'd appreciate if "minimal support" includes recognizing __stdcall (and optionally __declspec(dllimport) but I think that this is not required) in strict mode so that it can import InterlockedIncrement and friends from the Windows kernel. Another alternative would be to pass the _InterlockedIncrement intrinsic to the underlying VC++ backend as-is, if possible.
The minimal support mentioned above was for non-strict mode. Anyway, we're favoring the former for now for a new combo strict mode when that bridge is crossed.
There is also the option of introducing #pragma backend ... that simply injects #pragma ... in the generated C code. This would enable me to use #pragma backend intrinsic( _InterlockedIncrement ) for como-win32-vc*. I have verified that this results in generated C code that compiles fine with the VC backend (by inserting the above #pragma manually at the appropriate location).
At 08:55 PM 4/29/2005 +0300, Peter Dimov wrote:
Comeau Computing wrote:
At 06:04 PM 4/26/2005 +0300, Peter Dimov wrote:
For shared_ptr in particular, I'd appreciate if "minimal support" includes recognizing __stdcall (and optionally __declspec(dllimport) but I think that this is not required) in strict mode so that it can import InterlockedIncrement and friends from the Windows kernel. Another alternative would be to pass the _InterlockedIncrement intrinsic to the underlying VC++ backend as-is, if possible.
The minimal support mentioned above was for non-strict mode. Anyway, we're favoring the former for now for a new combo strict mode when that bridge is crossed.
There is also the option of introducing
#pragma backend ...
that simply injects
#pragma ...
in the generated C code.
This would enable me to use
#pragma backend intrinsic( _InterlockedIncrement )
for como-win32-vc*.
I have verified that this results in generated C code that compiles fine with the VC backend (by inserting the above #pragma manually at the appropriate location).
This seems familiar and believe that although you are correct that the C code will compile fine, there were still some link problems or something to work out... exactly what alludes me at the moment, but I should have notes on that somewhere, so will revisit this especially in light of other progress. - Greg ------- Comeau C/C++ 4.3.3: Watch for our Mac port Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90. Comeau C/C++ with Dinkumware's Libraries. Have you tried it? comeau@comeaucomputing.com http://www.comeaucomputing.com
IMHO it's not really justified. Comeau does support multithreaded Win32 applications, even in strict mode, it just does not support including windows headers in strict mode; but then one can factor out all Win32 dependent stuff to separate TU (which is good practice, anyway) and use threads. Como compiler (current version) does not support DLLs, and this is what makes Boost.Thread inacessible to como toolset. I have a reason to believe that next version of como compiler (due soon) will support DLLs.
Actually it's defining BOOST_DISABLE_THREADS and BOOST_DISABLE_WIN32 already, so scrub that request. I understand what you're saying about putting threading in the another TU, but the point is that the code we're compiling right now (this TU) can't include any threading API's (as far as Boost is concerned anyway). John.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock
Actually it's defining BOOST_DISABLE_THREADS and BOOST_DISABLE_WIN32 already, so scrub that request. I understand what you're saying about putting threading in the another TU, but the point is that the code we're compiling right now (this TU) can't include any threading API's (as far as Boost is concerned anyway).
Is there any reason why we can't change all direct calls to Windows API functions to calling convention thunks in another translation unit? E.g. // shared_ptr.hpp #include "boost/windows/ccthunk.hpp" windows::interlocked_increment(p); // ccthunk.hpp namespace windows { long interlocked_increment(long* volatile p); } // ccthunk.cpp #include "windows.h" namespace windows { long interlocked_increment(long* volatile p) { return InterlockedIncrement(p); } } We wouldn't to do this for the entire Win32 API, and it seems like an inversion of principles to disable functionality on a compiler because it rejects non-standard syntax (calling convention keywords). Calling convention keywords don't even fit into the C++ grammar (such information should properly be handled by pragmas--whose explicit purpose is to pass extra-linguistic information or instructions to the compiler). Regards, Paul Mensonides
John Maddock wrote:
flags como-win32 CFLAGS <threading>single : -DBOOST_SP_DISABLE_THREADS ;
This sounds like something that should be fixed in smart_ptr, not in the build system. Would it not be better to have the smart_ptr config use BOOST_SP_DISABLE_THREADS in the case of como strict mode (assuming you can tell) so that it fixes it for everyone, not just people that use Boos.Build.
Or maybe if the threading API's are inaccessible in that build mode we should define BOOST_DISABLE_THREADS, and turn off all threading support (it's not just shared_ptr that has it's own lightweight threading support).
To cut down support calls ;-) shared_ptr ignores the absence of BOOST_HAS_THREADS when it recognizes the platform. But maybe it should honor BOOST_DISABLE_THREADS in addition to BOOST_SP_DISABLE_THREADS. I need to think about it.
Peter Dimov wrote:
John Maddock wrote:
To cut down support calls ;-) shared_ptr ignores the absence of BOOST_HAS_THREADS when it recognizes the platform. But maybe it should honor BOOST_DISABLE_THREADS in addition to BOOST_SP_DISABLE_THREADS. I need to think about it.
OK back to the build system. How about adding a define that tells us that the --a option was added, like BOOST_COMO_STRICT. At least that way we can: Do some handling for that case; If users run into problems we can easily tell them to define that as needed; In the future when como decides to add a detection macro of it's own we already have code to handle it and we just make config detect it. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera wrote:
OK back to the build system. How about adding a define that tells us that the --a option was added, like BOOST_COMO_STRICT. At least that way we can: Do some handling for that case; If users run into problems we can easily tell them to define that as needed; In the future when como decides to add a detection macro of it's own we already have code to handle it and we just make config detect it.
sounds like good idea. B.
Bronek Kozicki wrote:
Rene Rivera wrote:
OK back to the build system. How about adding a define that tells us that the --a option was added, like BOOST_COMO_STRICT. At least that way we can: Do some handling for that case; If users run into problems we can easily tell them to define that as needed; In the future when como decides to add a detection macro of it's own we already have code to handle it and we just make config detect it.
sounds like good idea.
And following on Peter's heels I just added the above. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera wrote:
Peter Dimov wrote:
Bronek Kozicki wrote:
Peter Dimov wrote:
This can be fixed by defining BOOST_SP_DISABLE_THREADS for the Comeau toolset.
could you pls. develop fix for como-win32-tools.jam? I agree with your
flags como-win32 CFLAGS <threading>single : -DBOOST_SP_DISABLE_THREADS ;
This sounds like something that should be fixed in smart_ptr, not in the build system. Would it not be better to have the smart_ptr config use BOOST_SP_DISABLE_THREADS in the case of como strict mode (assuming you can tell) so that it fixes it for everyone, not just people that use Boos.Build.
I'd have fixed it from shared_ptr's side, but this would mean that when you mix strict and non-strict translation units you'd have half of them use SP_DISABLE_THREADS (and there would be no indication that this happened). I'm not sure whether this would be a good thing. It seems to me that it is preferable to let people know that there might be a problem and leave the final decision of defining SP_DISABLE_THREADS versus disabling strict mode to them.
On 4/26/05, Peter Dimov <pdimov@mmltd.net> wrote:
I'd have fixed it from shared_ptr's side, but this would mean that when you mix strict and non-strict translation units you'd have half of them use SP_DISABLE_THREADS (and there would be no indication that this happened).
I smell violation of ODR in the air. Better not go this path. B. -- Bronek Kozicki brok@rubikon.pl http://b.kozicki.pl/
Peter Dimov wrote:
flags como-win32 CFLAGS <threading>single : -DBOOST_SP_DISABLE_THREADS ;
above the <threading>multi line. Try it in your local copy, and if everything goes well and no bjam experts chime in, I'll commit it to the CVS (if approved by our release manager, of course).
OK; we will see results tomorrow morning. If everything goes well (enough), I will upload results as Bronek_A.zip B.
flags como-win32 CFLAGS <threading>single : -DBOOST_SP_DISABLE_THREADS ;
above the <threading>multi line. Try it in your local copy, and if everything goes well and no bjam experts chime in, I'll commit it to
Ok, results are available at http://www.meta-comm.com/engineering/boost-regression/cvs-head/developer/sum... Indeed, your fix does the job. There is large number of other faulires, though. Do you think that it's possible to develop more general solution? As to remaining failures, some are little strange, e.g. http://tinyurl.com/9cssj (no diagnostic message). I do not know what can be done with them :-/ (maybe just another run?) B. -- Bronek Kozicki brok@rubikon.pl http://b.kozicki.pl/
Bronek Kozicki wrote:
As to remaining failures, some are little strange, e.g. http://tinyurl.com/9cssj (no diagnostic message). I do not know what can be done with them :-/ (maybe just another run?)
It appears that the Boost.Test library didn't get built for some reason.
On 4/26/05, Peter Dimov <pdimov@mmltd.net> wrote:
Bronek Kozicki wrote:
As to remaining failures, some are little strange, e.g. http://tinyurl.com/9cssj (no diagnostic message). I do not know what can be done with them :-/ (maybe just another run?)
It appears that the Boost.Test library didn't get built for some reason.
Oh, then I guess it includes windows headers and is compiled under strict mode. Which obviously fail. B. -- Bronek Kozicki brok@rubikon.pl http://b.kozicki.pl/
As to remaining failures, some are little strange, e.g. http://tinyurl.com/9cssj (no diagnostic message). I do not know what can be done with them :-/ (maybe just another run?)
It appears that the Boost.Test library didn't get built for some reason.
I don't know why there's no message in that one, but if you look here: http://tinyurl.com/9v8c4 you'll see it's failing to build because it's including shared_ptr.hpp. BTW why are there two sets of Como results? It's confusing to know which we should be looking at. Thanks, John.
John Maddock wrote:
BTW why are there two sets of Como results? It's confusing to know which we should be looking at.
Bronek_A is the one with patch proposed by Peter, ie. added flags como-win32 CFLAGS <threading>single : -DBOOST_SP_DISABLE_THREADS ; ... to como-win32-tools.jam . It allows shared_ptr to compile. I will remove "Bronek_A" as soon as "Bronek" provides at least as good results, that is some fix for shared_ptr is in CVS. B.
Bronek Kozicki wrote:
John Maddock wrote:
BTW why are there two sets of Como results? It's confusing to know which we should be looking at.
Bronek_A is the one with patch proposed by Peter, ie. added flags como-win32 CFLAGS <threading>single : -DBOOST_SP_DISABLE_THREADS ; ... to como-win32-tools.jam . It allows shared_ptr to compile. I will remove "Bronek_A" as soon as "Bronek" provides at least as good results, that is some fix for shared_ptr is in CVS.
I've just committed this fix to the CVS. Ideally como+vc should allow us to pass a #pragma intrinsic statement to the VC backend. Maybe some day. :-)
Bronek Kozicki <brok@rubikon.pl> wrote:
I will remove "Bronek_A" as soon as "Bronek" provides at least as good results, that is some fix for shared_ptr is in CVS.
removed now; next refresh of regression tests results will show "Bronek" alone. B.
participants (12)
-
Bronek Kozicki -
Bronek Kozicki -
Comeau Computing -
Daniel James -
David Abrahams -
Jeff Garland -
JOAQUIN LOPEZ MU?Z -
John Maddock -
Jonathan Turkanis -
Paul Mensonides -
Peter Dimov -
Rene Rivera