Hi, Following up on my crash of the serialization demo program in XCode I found its cause but I need help to fix it. It turns out that XCode defines _GLIBCXX_DEBUG=1 _GLIBCXX_DEBUG_PEDANTIC=1 in its debugging targets. This was the source of the crash. Googling for the reason was not straightforward, but I eventually found this, on the Gnu website:
To use the libstdc++ debug mode, compile your application with the compiler flag -D_GLIBCXX_DEBUG. Note that this flag changes the sizes and behavior of standard class templates such as std::vector, and therefore you can only link code compiled with debug mode and code compiled without debug mode if no instantiation of a container is passed between the two translation units.
This page is at http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt12ch30s03.html The standard build of Boost does not define _GLIBCXX_DEBUG I suppose and that explains the crash. So what's the best way to fix this? 1- As I have been suggested a couple times, removing the define from XCode's debugging target works, but I contend this is not the right way, as I do not wish to do without the debugging scaffolding provided by my tools, at least if there is a better way. 2- A better idea is to have a build of Boost compiled with _GLIBCXX_DEBUG defined. 3- Even better, have Boost works both with _GLIBCXX_DEBUG and without _GLIBCXX_DEBUG in the same build. The way the Gnu standard C++ Library achieves this is to conditionally compile code depending on _GLIBCXX_DEBUG not in the implementation files, but only in the headers. When the impact cannot be avoided in the implementation files, it defines two variations of the same standard class, a normal and a debug version, switching from one to the other in the header file. Could Boost evolve in that direction? My vote is in. But that's not for today. So coming back to idea #2, I started to dive into the Boost build system to achieve it, but my first try was not a success. I am really not very experienced with the Unix way, nor with the Boost build system, so maybe someone can save me from learning the intricacies. Here is what I did: 1- First build the standard Boost: sudo ./bjam release This worked. 2- Then build the debug Boost: sudo ./bjam debug define=_GLIBCXX_DEBUG=1 define=_GLIBCXX_DEBUG_PEDANTIC=1 This worked, but I could not confirm that both defines were used. Did I do it the right way? Does the debug target already define those two symbols? Could it? Also I'm not sure which object files are debug and release. To take as an example the serialization objects, I now have four files in my lib directory: $ ls -la *serial* -rw-r--r-- 1 root wheel 6616488 Sep 23 16:31 libboost_serialization.a -rwxr-xr-x 1 root wheel 807368 Sep 23 16:31 libboost_serialization.dylib -rw-r--r-- 1 root wheel 4871728 Sep 23 16:31 libboost_wserialization.a -rwxr-xr-x 1 root wheel 612296 Sep 23 16:31 libboost_wserialization.dylib What is this "w" prefix supposed to mean? 3- Install both builds: sudo ./bjam debug release install This fails with errors such as: error: Duplicate name of actual target:
libboost_date_time.dylib So did the the first two command also install Boost? Can the two build coexist? Again, the answers are possibly in the doc. I have started studying it, but this takes time. I guess I'd eventually find the answers to these questions on my own, but I'd appreciate some boost (hmmm...). Best regards, Jean-Denis Muys On Sep 20, 2009, at 22:29 , Robert Ramey wrote:
Jean-Denis Muys wrote:
Well, I spent a large number of hours since my original message, and while I learned a lot, I could not solve my problem and I am about to give up using Boost.
Here is what I managed to find out:
- first an foremost, the example works fine when compiled and run from the terminal using the following command:
c++ demo.cpp -o demo /usr/local/lib/libboost_serialization.dylib
- the crash happens when running the example from the XCode IDE. Since my real project is developed using XCode, this is a show-stopper.
Well, clearly it's a build issue. So this problem will likely come up using any boost library. I don't think that tracing into the serialization code is going to be very helpful.
The only thing I could suggest is to detemine what the command line XCode IDE is using and compare it to the one used above or with the one generated by bjam.
Robert Ramey