From: Robert Ramey (ramey_at_[hidden])
Date: 2007-12-03 18:01:15
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
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 /
show message ulimit exceeded. This looks like a test artifact
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.
> 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.)
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk