We are using boost 1.27 (I know, I know) with the real-time operating system VxWorks, which ships with its own "special" version of gcc 2.96 (not that same as Red Hats - I know, I know).
Today I finally got around to providing a version of atomic_count.hpp for VxWorks. I had to play some games with #defines to get BOOST_HAS_THREADS and all the other things set up right before my implementation would get chosen. Once that was squared away, I put a cout in the constructor of my atomic_count class just be sure it was all working. I then stamped down a shared_ptr<int> and much to my surprise: no text output.
I traced it back to the constructor for counted_base_impl (a templated class). That constructor was being called, but it inherits from counted_base, and that constructor was just not getting called!
I searched your bug list on source forge but found no mention of
So in case anyone cares (are there any other VxWorks/Boost users out there?): The problem was of my own making. But I have upgraded to 1.29.0 so all was not lost. For VxWorks users: be careful with the -fmerge-templates option. I had this on to avoid code bloat. I then changed the lightweight_mutex class enabling pthread support and by adding a print statement to see if it really was making that pthread call. But I only recompiled just the test file that was testing shared_ptr. There was already another lightweight_mutex laying around in one of my libraries that I link with (and it was from the pre-pthread days). The muncher then picked that one instead of mine because of -fmerge-templates. So it crashed big time. Doing a "clean all" straightened that out. Duh. BTW, now that VxWorks has pthread support, boost works great without any custom mods. I can provide my user configuration file to anyone else who is trying to get boost running on VxWorks. Thanks, BN --- In Boost-Users@yahoogroups.com, "Brian" <bneal@z...> wrote: this.
But then again, its not really a boost bug!
I then took a look at boost 1.29 and noticed that lots of things had been reworked in this area, so now looks like the reason to start using 1.29. I'm afraid I am stuck with VxWorks and that compiler though...
So I'm just throwing this out in case anyone is remotely in the same situation as we are. I will start using 1.29 and see what happens. Hopefully its not too hard to customize the OS specific part in 1.29.
I also suggest a note get added to the shared_ptr documentation about this OS specific mutex stuff thats going on. I got curious about how that was done and decided to look. Had I not done this, my shared_ptr's reference count would not have been thread safe and I wouldn't have known this.
Also, is there a "what has changed in this new version of boost" file somewhere?
Thanks again everyone. BN