[Boost-users] Build system: debug vs release, and both together?

Subject: [Boost-users] Build system: debug vs release, and both together?
From: Jean-Denis Muys (jdmuys_at_[hidden])
Date: 2009-09-24 07:33:52

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: <p/usr/local/ 
lib>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
>