Subject: Re: [boost] [serialization] Errors when testing withe mingw-64/gcc on Windows
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-08-03 15:45:02
On 8/3/15 11:58 AM, Edward Diener wrote:
> I don't know how "to run the whole serialization test suite" but here is
> what I have done:
It's just running all the tests via the normal boost build/bjam system.
I'm in the habit of mentioning this because it's quite common for
someone to post a "fix" that is "too trivial" to require testing and
it's helpful for me to avoid this.
> 1) I have created PR "Changes to fix serialization for gcc and clang on
> Windows #19". This fixes the building of the serialization library for
> mingw(-64)/gcc, both regular and wide character.
I will consider this shortly. I've been trying to catch up on other
stuff so I've got a few things pending with the serialization library
maintenance. I'll look at the PR soon.
> 2) For clang I have been told that the system of exporting/importing
> individual member functions as opposed to entire class does not work,
> since clang will not export a class's RTTI unless the entire class is
Hmmm - my problems showed up only when I enabled limited visibility. I
managed to get all tests passing on gcc, clang, and msvc (with a little
help from my friends). Then I got nailed by mingw which I couldn't
figure out the visibility system.
So while the build of the regular serialization library
> succeeds it is probably not usable from other clang code.
hmmm - all the tests passed on my system with both static and shared
This can be
> seen in the fact that using your current system of exporting/importing
> individual member functions of a visible class I can not build the wide
> character serialization library using clang because it refuses to link
> with the dependent regular character serialization library.
Again, I'm not seeing this - I've only had problems with mingw
> you want to change the way that export/import works for clang on Windows
> clang on Windows will not work with serialization.
I can't remember right now whether I originally had been exporting the
whole class or just function by function. It's been 6 months.
One reason that it's more complicated with the serialization library is
that there are two DLLS the core one and the wide character add-in. The
second exports functions of it's own while importing functions from the
core. This is doable, but confusing.
> 3) I have tested my changes with gcc and clang on Linux and with gcc,
> VC++, and clang on Windows. As explained above everything succeeds
> except clang on Windows, which also failed before my changes.
Hmmm - I'm not sure how this is different than the current status. As I
said, my pending issues were with mingw. Since mingw is also a relative
of windows - it wouldn't surprise me of clang for windows also has
issues. I am interested in getting this sorted out since I want to keep
the serialization library as widely applicable as possible and I
appreciate your help with this (and other people too). On the other
hand, I'm beginning to wonder. The problem with mingw has been there
since 1.58 and no one has complained. Same goes for clang on windows.
It's hard to get motivated to spend time making things work for
platforms which it doesn't seem anyone is using.
> If you could look at this PR and try it with your "whole serialization
> test suite" it would be appreciated.
I absolutely will, and soon.
As I said, the whole test suite is just the normal boost build test.
One thing that I do is run all the combinations of
shared/static/debug/release for gcc and clang - I don't have a windows
development system any more. This takes a while sucks up an incredible
amount of disk space.
> If you are willing to give the go ahead I can try changing clang on
> Windows so that the entire class is exported rather than individual
> member functions for that one-off case. It is pretty easy to test for
> clang on Windows using gcc at the preprocessor level. I do realize
> exporting the entire class in the one-off clang case changes your work
> in carefully honing visibility, for this single case, but I cannot
> change the way clang on Windows works. Changing for clang on Windows
> will not change any other compiler implementation but will make your
> code slightly messier.
LOL - you mean the serialization library is messy?
> PS. I also created PR "Delete recreated files. #18" which deletes some
> files from Git which were being regenerated by serialization tests each
Again I much appreciate your efforts. I just need to find the time to
give them attention they deserve.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk