Hi, The following libraries show fails across almost all platforms in the 1.34 regression tests concept_check io mpl ptr_container python wave I would be thankful for a short update on the reason and plans for mitigation. AFAICS this has to be dealt with before we even think about a Beta release. Thanks Thomas Release Manager -- Thomas Witt witt@acm.org
Thomas Witt <witt@acm.org> writes:
Hi,
The following libraries show fails across almost all platforms in the 1.34 regression tests
concept_check io mpl ptr_container python wave
I would be thankful for a short update on the reason and plans for mitigation.
As far as I can tell from http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/py... the Python failures are all due to configuration problems on the part of the tester, or bugs in BBv2 -- they just have that smell about them. But it's hard to tell much because the "fail" squares don't like through to any diagnostics ("Page not found!"). I'm surprised to see the asterix in many of these squares. What does that mean? It doesn't appear to be covered in the legend. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Thomas Witt <witt@acm.org> writes:
Hi,
The following libraries show fails across almost all platforms in the 1.34 regression tests
concept_check io mpl ptr_container python wave
I would be thankful for a short update on the reason and plans for mitigation.
As far as I can tell from http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/py... the Python failures are all due to configuration problems on the part of the tester, or bugs in BBv2 -- they just have that smell about them.
Could you work with the testers to solve this issue? But it's hard to tell much because the "fail" squares don't
like through to any diagnostics ("Page not found!"). I'm surprised to see the asterix in many of these squares. What does that mean? It doesn't appear to be covered in the legend.
Not all of them seems like the asterix indicates missing links. So here is a question for the test list. Where does the asterix come from and how do we fix it? Thanks in advance Thomas -- Thomas Witt witt@acm.org
[folowups to testing] Thomas Witt <witt@acm.org> writes:
David Abrahams wrote:
Thomas Witt <witt@acm.org> writes:
Hi,
The following libraries show fails across almost all platforms in the 1.34 regression tests
concept_check io mpl ptr_container python wave
I would be thankful for a short update on the reason and plans for mitigation.
As far as I can tell from http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/py... the Python failures are all due to configuration problems on the part of the tester, or bugs in BBv2 -- they just have that smell about them.
Could you work with the testers to solve this issue?
I'll give it a shot. what about it, people? Doug and Volodya: http://tinyurl.com/qwz7n and http://tinyurl.com/nv8by seem to indicate that the Python libraries aren't in the regular paths. Is that correct? In principle that should be okay; it's an indication that BBv2 isn't correctly propagating all the library's usage requirements to the executable. But your runs with earlier GCC versions are all working, which seems to indicate some other kind of problem. I'm without a clue here. Martin: I get lots of "page not found!" results for your Python failures. Do you have any insight into what causes that? COMSOFT (whoever you are): I have no clue about the linker failures for GCC. They appear to be saying that the file it's trying to creat can't be found. Is it possible to build shared libs on this compiler at all? The HP compiler failures all appear to be due to an inability to handle its own standard library. Do you get _anything_ to compile with that compiler? Hmm, apparently you do. I'm at a loss. Maybe Python is causing a redefinition of fpos_t? Are we somehow running into this problem? http://mail.python.org/pipermail/python-bugs-list/2005-November/030900.html Aleksey and Volodya: it's hard to imagine what could cause these vc-6.5 failures, since they worked elsewhere. Okay, here's one weird possibility: I note there's no call to vcvars32.bat. Maybe "cl" doesn't refer to vc-6 in the PATH. I suggest fixing the configuration so that vcvars32.bat gets called. I'm actually surprised it's getting missed. Volodya, can you explain why? I don't know why any failures are showing up for Borland. Isn't this library marked unusable for Borland? Stefan and Volodya, the one failure here looks like the same problem Doug is seeing.
So here is a question for the test list. Where does the asterix come from and how do we fix it?
Agreed. Anyone? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote: [...]
COMSOFT (whoever you are):
That's me.
I have no clue about the linker failures for GCC. They appear to be saying that the file it's trying to creat can't be found. Is it possible to build shared libs on this compiler at all?
I have no idea about the failures here, but I will have a look at this. Shared libs work in principal for gcc, and boost.python worked on gcc/v1.
The HP compiler failures all appear to be due to an inability to handle its own standard library. Do you get _anything_ to compile with that compiler? Hmm, apparently you do. I'm at a loss. Maybe Python is causing a redefinition of fpos_t? Are we somehow running into this problem? http://mail.python.org/pipermail/python-bugs-list/2005-November/030900.html
No, it's a problem discussed before, and my last conclusion was that basically boost.python is unusable for this compiler version. See this long thread for explanation: http://archives.free.net.ph/thread/20050614.231346.3c5551ae.en.html#20050614... and especially http://archives.free.net.ph/message/20050619.184208.22450dd2.en.html Markus
David Abrahams writes:
Aleksey and Volodya: it's hard to imagine what could cause these vc-6.5 failures, since they worked elsewhere. Okay, here's one weird possibility: I note there's no call to vcvars32.bat. Maybe "cl" doesn't refer to vc-6 in the PATH.
That would be my guess as well.
I suggest fixing the configuration so that vcvars32.bat gets called. I'm actually surprised it's getting missed. Volodya, can you explain why?
[...]
So here is a question for the test list. Where does the asterix come from and how do we fix it?
Agreed. Anyone?
I will look into this ASAP. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
David Abrahams writes:
Aleksey and Volodya: it's hard to imagine what could cause these vc-6.5 failures, since they worked elsewhere. Okay, here's one weird possibility: I note there's no call to vcvars32.bat. Maybe "cl" doesn't refer to vc-6 in the PATH.
That would be my guess as well.
Then, what it does refer to? Is there any other command called "cl"? Can you send me your user-config.jam? Can you pass additional "--debug-configuration" option to bjam when running tests? - Volodya
Thomas Witt wrote:
The following libraries show fails across almost all platforms in the 1.34 regression tests
concept_check io mpl ptr_container python wave
I would be thankful for a short update on the reason and plans for mitigation.
AFAICS this has to be dealt with before we even think about a Beta release.
I did some Wave performance optimizations lately which gcc seemed to dislike :-P. I hope to have it fixed now, but we'll have to wait for a couple of days for the fix to propagate... Sorry for the problems Regards Hartmut
Thanks
Thomas
Release Manager
-- Thomas Witt witt@acm.org
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Thomas Witt wrote:
Hi,
The following libraries show fails across almost all platforms in the 1.34 regression tests
ptr_container
For hp_cxx- 65_042_tru64, all tests seems to crash the compiler. So I should mark this unuable. For sun-5.8, some of it could probably be imrpoved if somebody has time. I think that in general the library is usable, the major problems seems to be partual ordering of overloads of insert() and transfer(). As long as those functions are not called, it should work. I should mark this usable with a conservative interface. VC7: needs wok by someone. I will mark it unusable. Borland: not much have happened in the new compilers. I'll mark them unusable. Digital Mars: there still major problem with the test library which prevent us from getting any real result for this compiler. Should it be marked unusable anyway? CW 9.*. The library is large usable. This compiler has problems with auto_ptr and range-based overloads, but the core of the library compiled cleanly. Apart from that, there are some minor GCC bugs that needs to be fixed...I can probably manage that. As a general remark, I'm fairly unhappy with the fact that boost.test causes quite a few other regressions to fail. If there is one component that *needs* to be consertive/portable, it is the test library. -Thorsten
Thorsten Ottosen wrote:
Thomas Witt wrote:
Hi,
The following libraries show fails across almost all platforms in the 1.34 regression tests
ptr_container
For hp_cxx- 65_042_tru64, all tests seems to crash the compiler. So I should mark this unuable.
Yes, I don't think it's of any use that I try to find the problem there. But what do you think about the single failure on 7.1? Compiler problem, or maybe a 2-phase lookup problem? (This is just a guess as most problems on this compiler version haven been caused by 2-phase lookup, so far.) [...] Markus
Markus Schöpflin wrote:
Yes, I don't think it's of any use that I try to find the problem there.
But what do you think about the single failure on 7.1? Compiler problem, or maybe a 2-phase lookup problem? (This is just a guess as most problems on this compiler version haven been caused by 2-phase lookup, so far.)
you mean hp_cxx- 71_006_tru64 ? That error is of no practical importance -Thorsten
Thorsten Ottosen wrote:
Markus Schöpflin wrote:
Yes, I don't think it's of any use that I try to find the problem there.
But what do you think about the single failure on 7.1? Compiler problem, or maybe a 2-phase lookup problem? (This is just a guess as most problems on this compiler version haven been caused by 2-phase lookup, so far.)
you mean
hp_cxx- 71_006_tru64 ?
That error is of no practical importance
Which makes me question the purpose of the test, of course. But I'm sure you knew that I would ask this question... ;-) Markus
Markus Schöpflin wrote:
Thorsten Ottosen wrote:
Markus Schöpflin wrote:
Yes, I don't think it's of any use that I try to find the problem there.
But what do you think about the single failure on 7.1? Compiler problem, or maybe a 2-phase lookup problem? (This is just a guess as most problems on this compiler version haven been caused by 2-phase lookup, so far.)
you mean
hp_cxx- 71_006_tru64 ?
That error is of no practical importance
Which makes me question the purpose of the test, of course. But I'm sure you knew that I would ask this question... ;-)
Well, it does mean that ptr_map<Key,T>::pointer p = &*map.begin() won't work on that compiler. I still thinks such code is rare and therefore that it has no practical importance. -Thorsten
participants (7)
-
Aleksey Gurtovoy -
David Abrahams -
Hartmut Kaiser -
Markus Schöpflin -
Thomas Witt -
Thorsten Ottosen -
Vladimir Prus