Ben Hutchings wrote: ...
I grabbed the CVS instead of using the 1.33.0 package I was working with before. I assume this was what you intended?
Did you also apply the patch I attached? I won't commit that change to CVS unless and until you confirm that it works in an ILP32 configuration.
This was with the patch already applied. I wasn't very specific in what I wrote--I meant I applied the patch to what I got from CVS as opposed to applying it to 1.33.0. Sorry.
As an aside, do I gather correctly from the presence of "-D_REENTRANT -pthread" the smart pointer code is multithreaded?
It's intended to be thread-safe if necessary. The purpose of the assembly-language code is to do reference-counting in a thread-safe and efficient way (use of mutexes for reference-counting is quite expensive).
Anything I write using smart pointers, regardless of whether or not my code is multithreaded, will require the flags?
If BOOST_DISABLE_THREADS is defined then you will get a non-thread-safe and more efficient version of sp_counted_base. You must ensure that all translation units that use sp_counted_base get a consistent definition (the One Definition Rule). So you should choose either "-D_REENTRANT -pthread" or "-DBOOST_DISABLE_THREADS" and use it consistently.
Okay. I'm thinking right now I'll end up using BOOST_DISABLE_THREADS since I don't intend to spawn multiple threads myself--my project is a serial numerical analysis code. Once I was doing a project involving Java and I read a Java programer still had to consider thread safety regardless of whether or not the program code explicitly spawned multiple threads because, while the program's code might not explicitly spawn many threads, Java class library methods could spawn multiple threads when called. I think this came up in particular when I was doing Java-C++-Fortran cross-language programming. David