[serialization] Clearing Intel/Windows errors?
A whole bunch of serialization tests are failing for Intel/Windows because of an apparent error in export.hpp. See below. What is the status of getting this fixed? ..\boost/serialization/export.hpp(131): error: redeclaration cannot add dllexport/dllimport to "boost::archive::detail::ptr_serialization_support<Archive, Serializable>::instantiate" (declared at line 131) BOOST_DLLEXPORT void ptr_serialization_support<Archive,Serializable>::instantiate() Thanks, --Beman
This module is extremely trick and has much compiler dependent code. I might be tempted to take a crack at it but without being able to test it, I'm afraid I might create more problems than I fix. FWIW I don't think the fix for the intel/win issue would be too hard, but it would have to be tested in release build as well as debug build as the offending code is required on some platforms to inhibit the linker from stripping what otherwise would be considered dead code. A similar situation exists with the same tests failing with gcc 4.1+ Its even more problematic there as it fails at runtime and I think it will take some serious sleuthing with the debugger to track it down. On the branch "serialization_next_release" I've got a version which has a fair amount of changes in this area. These changes were made in the course of making the serialization library thread safe and serialization code linkable at runtime (DLLS). The later in particular required a more thorough examination of issues related to instantiation implied by export. So it seems quite possible to me that this problem is already fixed in the "next release" If someone wanted to test the serialization library on this branch on the above platforms (gcc 4.1x and Intel/win 10.?) it might shed some light on the situation. Beman Dawes wrote:
A whole bunch of serialization tests are failing for Intel/Windows because of an apparent error in export.hpp. See below.
What is the status of getting this fixed?
..\boost/serialization/export.hpp(131): error: redeclaration cannot add dllexport/dllimport to "boost::archive::detail::ptr_serialization_support<Archive, Serializable>::instantiate" (declared at line 131) BOOST_DLLEXPORT void ptr_serialization_support<Archive,Serializable>::instantiate()
Thanks,
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
This module is extremely trick and has much compiler dependent code. I might be tempted to take a crack at it but without being able to test it, I'm afraid I might create more problems than I fix. FWIW I don't think the fix for the intel/win issue would be too hard, but it would have to be tested in release build as well as debug build as the offending code is required on some platforms to inhibit the linker from stripping what otherwise would be considered dead code.
A similar situation exists with the same tests failing with gcc 4.1+ Its even more problematic there as it fails at runtime and I think it will take some serious sleuthing with the debugger to track it down.
On the branch "serialization_next_release" I've got a version which has a fair amount of changes in this area. These changes were made in the course of making the serialization library thread safe and serialization code linkable at runtime (DLLS). The later in particular required a more thorough examination of issues related to instantiation implied by export. So it seems quite possible to me that this problem is already fixed in the "next release" If someone wanted to test the serialization library on this branch on the above platforms (gcc 4.1x and Intel/win 10.?) it might shed some light on the situation.
I've got Windows / Intel 10.x installed. I'll give it a try and contact you privately with the results. --Beman
Robert Ramey schrieb: [...]
On the branch "serialization_next_release" I've got a version which has a fair amount of changes in this area. These changes were made in the course of making the serialization library thread safe and serialization code linkable at runtime (DLLS). The later in particular required a more thorough examination of issues related to instantiation implied by export. So it seems quite possible to me that this problem is already fixed in the "next release" If someone wanted to test the serialization library on this branch on the above platforms (gcc 4.1x and Intel/win 10.?) it might shed some light on the situation.
I tried to test it on Tru64, but I stumbled over some file name issues of the files in the serialization test directory on the branch. For example, there is a file called A.cpp which is referenced from the Jamfile in lower case. This fails on case sensitive file systems. (There is a bunch of other single letter file names having the same problem.) There is also a missing file in the serialization library itself. (Can't remember the file name right now, but I'll have it tomorrow.) Markus
OK I think I was wrong about testing this branch on a *nix platform shedding light on the situation at hand. It was verying interesting to me personally, but a distraction from our current issues. I would like to be able to ask you to run another test like this in the future. Thanks for doing this. I've looked at the test results on the trunk and here is my summary and opinion on what will best help 1.35 out the door. gcc 4.1+ is failing test_exportable I believe that this is related to interaction between changes in export.hpp and changes in gcc. Code in this module is very compiler dependent and very tricky besides. I would ask Dave Abrahams to lend a hand with this if he has access to the gcc 4.1+ compiler. A couple of platforms don't seem to support shared libraries :HP-UX_pa_risc_gcc , pathscale- 3.0speedsnail-gcc-3.4.5 I can't fix this. I don't know if Jamfile can be tweaked to skip these tests. speedsnail-gcc-3.4.5 is run on a platform which doesn't support wide characters. Again, ideally a Jamfile trick might help or the failure can just marked up. Borland compilers are failing on binary archives. I believe this is related to enhancements for collections. I would ask Mathias Troyer and/or Nicolas Musetti to investigate these. demo portable_binary fails on big endian platforms. demo_portable_archive should be removed as it is out of sync with the current serialization implemenation. I can take care of that. It will required documentation changes and removing the files and Jamfile adjustments. Martin Wille x86_64 - serialization - test_array_binary_archive / gcc-3.4.6_linux_x86_64 show message ulimit exceeded. This looks like a test artifact of sort. Robert Ramey Markus Schöpflin wrote:
Robert Ramey schrieb:
[...]
On the branch "serialization_next_release" I've got a version which has a fair amount of changes in this area. These changes were made in the course of making the serialization library thread safe and serialization code linkable at runtime (DLLS). The later in particular required a more thorough examination of issues related to instantiation implied by export. So it seems quite possible to me that this problem is already fixed in the "next release" If someone wanted to test the serialization library on this branch on the above platforms (gcc 4.1x and Intel/win 10.?) it might shed some light on the situation.
I tried to test it on Tru64, but I stumbled over some file name issues of the files in the serialization test directory on the branch. For example, there is a file called A.cpp which is referenced from the Jamfile in lower case. This fails on case sensitive file systems. (There is a bunch of other single letter file names having the same problem.) There is also a missing file in the serialization library itself. (Can't remember the file name right now, but I'll have it tomorrow.)
Markus
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Dec 4, 2007, at 12:01 AM, Robert Ramey wrote:
Borland compilers are failing on binary archives. I believe this is related to enhancements for collections. I would ask Mathias Troyer and/or Nicolas Musetti to investigate these.
I can try to help with that if someone sends me the error messages. I don't see Borland results in the regression tables and don't have access to the compiler myself. Matthias
Robert Ramey wrote:
OK I think I was wrong about testing this branch on a *nix platform shedding light on the situation at hand. It was verying interesting to me personally, but a distraction from our current issues. I would like to be able to ask you to run another test like this in the future. Thanks for doing this.
[...] I now have a list of files that are missing on the branch, maybe you could check them in anyway, so that I at least can try a test run privately: - boost/serialization/factory.hpp - libs/serialization/src/bidirectional_map.hpp - libs/serialization/src/extended_type_info_no_rtti.cpp Markus
Thanks for offering to do this. I'll check in the changes, double check that every thing still builds and let you know when I'm ready to see some *nix results. You can't know how useful this is to me. Thanks again. Robert Ramey Markus Schöpflin wrote:
Robert Ramey wrote:
OK I think I was wrong about testing this branch on a *nix platform shedding light on the situation at hand. It was verying interesting to me personally, but a distraction from our current issues. I would like to be able to ask you to run another test like this in the future. Thanks for doing this.
[...]
I now have a list of files that are missing on the branch, maybe you could check them in anyway, so that I at least can try a test run privately:
- boost/serialization/factory.hpp - libs/serialization/src/bidirectional_map.hpp - libs/serialization/src/extended_type_info_no_rtti.cpp
Markus
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (5)
-
Beman Dawes -
Markus Schöpflin -
Markus Schöpflin -
Matthias Troyer -
Robert Ramey