Opened 14 years ago
Closed 14 years ago
#2291 closed Bugs (fixed)
unregistered void cast in 1.35 for all test_exported* tests
| Reported by: | Dave Abrahams | Owned by: | Robert Ramey |
|---|---|---|---|
| Milestone: | Boost 1.37.0 | Component: | serialization |
| Version: | Boost 1.35.0 | Severity: | Problem |
| Keywords: | Cc: |
Description
I believe I am experiencing the same failures reported as unresolved issues against gcc-4.2.1 here: http://www.boost.org/development/tests/release-1_35_0/developer/issues_release_.html#serialization. I am using gcc-4.0.1 on SLES-10 Linux. It is well known that darwin-4.0.1 is not quite a normal gcc toolset, which may explain why it does not show the same failures in Boost-1.35. Unfortunately, for 1.36, it appears that we stopped testing on the platforms where the unresolved issues were coming up, so the problems were effectively masked.
Robert, I can test against 1.36.0 or the trunk on request. I can also give you access to the machine where these failures are occurring on request. If these issues were actually somehow fixed for 1.36, I'd like to know what the changes were.
Noel, are you still seeing those failures when you test on the same machines?
Thanks
Attachments (2)
Change History (9)
by , 14 years ago
| Attachment: | serialization-release.log added |
|---|
comment:1 by , 14 years ago
| Cc: | added |
|---|
follow-up: 3 comment:2 by , 14 years ago
note that between 1.35 and 1.36 there were a lot of changes related making the library thread safe. This sort of rippled through export and pretty much replaced ALL the hacky code required to get things instantiated and avoid code stripping on the wide variety of platforms. To the extent there is some of the hacky code left, its mostly concentrated in boost/serialization/singleton and a little bit in boost/serialization/export.
Given this, only a test of 1.36 or trunk would be of value to me.
Since I just checked in some changes to the trunk day before yesterday, the easiest would be to wait a week or so and test against the trunk. Or maybe even simpler, just add this combination to the normal trunk tests for at least one cycle. Now that I'm installed some changes, I'll be checking the trunk tests for the next week or so.
Robert Ramey
Robert Ramey
comment:3 by , 14 years ago
Replying to ramey:
Given this, only a test of 1.36 or trunk would be of value to me.
As I said, I'll be happy to test either or both. Just let me know what you would like.
Since I just checked in some changes to the trunk day before yesterday, the easiest would be to wait a week or so and test against the trunk.
Now, why would I want to wait?
Or maybe even simpler, just add this combination to the normal trunk tests for at least one cycle. Now that I'm installed some changes, I'll be checking the trunk tests for the next week or so.
Sorry, which combination? You lost me.
by , 14 years ago
| Attachment: | changeset_r43949_backport.patch added |
|---|
comment:4 by , 14 years ago
follow-up: 6 comment:5 by , 14 years ago
When I look at the current tests, I see gcc 4.01 passing all tests for darwin (both ppc and intel builds). I also see gcc 4.2.1 passing all tests. Do you still think that application of this patch to the trunk is necessary?.
comment:6 by , 14 years ago
| Cc: | removed |
|---|
Replying to ramey:
When I look at the current tests, I see gcc 4.01 passing all tests for darwin (both ppc and intel builds). I also see gcc 4.2.1 passing all tests.
Yes, that's all because of r43949
Do you still think that application of this patch to the trunk is necessary?.
No; that patch is the backport of r43949 to the 1.35 codebase. Was something unclear about that? I attached it in case Boost should ever do a 1.35.1 release or you would like to post a hotfix.
Again, I suggest looking at #1711 and seeing if you want to close it. In your place, I certainly would.
bjam testing log