[C++-sig] boost.python coredump in debug mode..?

[David Abrahams]

"Bjorn Pettersen" <BPettersen at NAREX.com> writes:

> There are several
> other interesting, and some not so interesting, differences from a
> default .dll workspace:
> 
>   bjam additions:
>   /Ob0 disable inlining (faulty optimizer? -- potentially important)

This is just the way we do our debug builds. If you build a release
version inlining will be fully enabled.

>   /GR  enable RTTI
>   /Z7  enable old style debug info (?)

You can choose Program Database debug info by adding
<debug-store>database to your BUILD variable.

>   default .dll workspace switches not in the bjam invocation:
>   /GZ  Enable runtime debug checking (at least it sounds potentially
> useful <wink>)

Not sure whether this would work or not, but you can always try adding
<cxxflags>-GZ to the BUILD, to see what happens.

>   A smattering of other (theoretically) semantically unimportant
> switches:
>   /W3  Warning level 3, /Gm  Enable minimal rebuild, /FD PDB file, ...

The incremental stuff is notoriously buggy...

> Is this worth filing as a documentation issue, if you think it is
> I'll write it up fully (would subscribing to and sending it to the
> Boost developers list be the right place to submit it?)

Why don't you submit a documentation patch to this list?

> While doing this, I also noticed that bjam was trying to call the wrong
> vcvars32.bat file, it's trying to find it in:
> 
>   CALL "C:\Program Files\Microsoft Visual C++\VC98\bin\VCVARS32.BAT"
> >nul
> 
> (and dropping the error on the floor/nul). If you have the full visual
> studio, however, vcvars32.bat is in:
> 
>   c:\Program Files\Microsoft Visual Studio\VC98\bin\vcvars32.bat
> 
> (got to love MS consistency :-) For Visual Studio.NET (vc7), bjam calls
> the correct file for Visual Studio (I don't have a standalone Visual
> C++, so I can't try that here...)
> 
> Should I send this to the same mailing list as above?

No, the jamboost list: jamboost at yahoogroups.com.

> Thanks again for spending so much time on something I really should
> have been able to figure out myself. Gives me a warm and fuzzy
> feeling when I can get persistent help with something like this
> though.
> 
> Oh, and thanks for such a great library (used to think I was a
> pretty good C++ programmer, even went to the ISO meeting in Dublin
> for my last job, but I'll definitely have to take a second look
> before I understand what's going on on the inside ;-)

That might be my fault ;-)
I need to make the implementation documentation available. I'm working
on it...

-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com