Re: shared_ptr 1.27 w/gcc 2.96 (VxWorks)

From: Brian (bneal_at_[hidden])
Date: 2003-03-06 13:32:15

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_at_[hidden], "Brian" <bneal_at_z...> wrote:
> 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 
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