Hi, would there be any problem in generating a .pdb file for libboost_thread? I'm using Boost 1.27.0 and VC.NET. Also, would it be possible to switch on generation of debug information for release builds as well? Regards // Johan
--- In Boost-Users@y..., "judoka1981" <johan.nilsson@e...> wrote:
Hi,
would there be any problem in generating a .pdb file for libboost_thread? I'm using Boost 1.27.0 and VC.NET.
The latest CVS snapshot will produce PDBs. The required updates are in the Boost.Build system, but there are some bug fixes in the Boost.Threads stuff as well, so I'd recommend updating both.
Also, would it be possible to switch on generation of debug information for release builds as well?
I don't think this would be a great idea. You can always create your own build process to do this, however. Bill Kempf
--- In Boost-Users@y..., "bill_kempf" <williamkempf@h...> wrote:
--- In Boost-Users@y..., "judoka1981" <johan.nilsson@e...> wrote:
Hi,
would there be any problem in generating a .pdb file for libboost_thread? I'm using Boost 1.27.0 and VC.NET.
The latest CVS snapshot will produce PDBs. The required updates are in the Boost.Build system, but there are some bug fixes in the Boost.Threads stuff as well, so I'd recommend updating both.
Also, would it be possible to switch on generation of debug information for release builds as well?
I don't think this would be a great idea. You can always create your own build process to do this, however.
Might not be a great idea, but it definitely is a good one. You don't have to redistribute the PDB files with your application, and who haven't been bitten by things that don't work in release mode that used to in debug? I'm aware that stepping through the source in release mode doesn't tell the entire truth due to compiler optimizations, but it still is _invaluable_ some times. (yes, of course I could generate them myself - if I just could spare some time to learn Boost.Build) Thanks for the answer though. I'm a bit reluctant to getting the latest CVS snapshot though - waiting for Boost 1.28 (or whatever it will be) instead. // Johan
Bill Kempf
--- In Boost-Users@y..., "judoka1981" <johan.nilsson@e...> wrote:
--- In Boost-Users@y..., "bill_kempf" <williamkempf@h...> wrote:
--- In Boost-Users@y..., "judoka1981" <johan.nilsson@e...> wrote:
Hi,
would there be any problem in generating a .pdb file for libboost_thread? I'm using Boost 1.27.0 and VC.NET.
The latest CVS snapshot will produce PDBs. The required updates are in the Boost.Build system, but there are some bug fixes in the Boost.Threads stuff as well, so I'd recommend updating both.
Also, would it be possible to switch on generation of debug information for release builds as well?
I don't think this would be a great idea. You can always create your own build process to do this, however.
Might not be a great idea, but it definitely is a good one. You don't have to redistribute the PDB files with your application, and who haven't been bitten by things that don't work in release mode that used to in debug? I'm aware that stepping through the source in release mode doesn't tell the entire truth due to compiler optimizations, but it still is _invaluable_ some times.
I don't agree. If it's a good idea, then I'd expect MS to do this by default for IDE generated builds. There's some overhead involved in generating this, there's compile time overhead (which is important to some), and there's the fact that many users will be confused by the presence of debug information and why "stepping" through the code behaves so strangely and unpredictably.
(yes, of course I could generate them myself - if I just could spare some time to learn Boost.Build)
You can create your own build process that doesn't use Boost.Build. There's not much that's unusual about building Boost.Threads. The only thing out of the ordinary is the need to create an additional DLL build for the threadmon stuff, but you shoud be able to figure this out by looking at the Jamfile even with out having any knowledge of Jam. If you have problems with this I can provide some help. Bill Kempf
From: "bill_kempf" <williamkempf@hotmail.com> [ Tue, 30 Apr 2002 15:53:38 -0000 ]
Might not be a great idea, but it definitely is a good one. You don't have to redistribute the PDB files with your application, and who haven't been bitten by things that don't work in release mode that used to in debug? I'm aware that stepping through the source in release mode doesn't tell the entire truth due to compiler optimizations, but it still is _invaluable_ some times.
I don't agree. If it's a good idea, then I'd expect MS to do this by default for IDE generated builds.
I personally wouldn't use MS as a shining example of what they consider "the best defaults" and stand by them on it :)
There's some overhead involved in generating this, there's compile time overhead (which is important to some), and there's the fact that many users will be confused by the presence of debug information and why "stepping" through the code behaves so strangely and unpredictably.
It is damn handy to have pdb info in a release build. More handier than having non at all and stepping into plain asm-code. I've not released a release-version of an exe/dll without having a pdb around since I learnt how to use them, and is a neck-saver in certain circumstances... ... but I was only really replying to your "MS default settings" comment which I feel is a bit dangerous :) Jim M -- @ Derbyshire
From: "bill_kempf" <williamkempf@h...> [ Tue, 30 Apr 2002 15:53:38 -0000 ]
Might not be a great idea, but it definitely is a good one. You don't have to redistribute the PDB files with your application, and who haven't been bitten by things that don't work in release mode
--- In Boost-Users@y..., Jim M <JimM@b...> wrote: that
used to in debug? I'm aware that stepping through the source in release mode doesn't tell the entire truth due to compiler optimizations, but it still is _invaluable_ some times.
I don't agree. If it's a good idea, then I'd expect MS to do this by default for IDE generated builds.
I personally wouldn't use MS as a shining example of what they consider "the best defaults" and stand by them on it :)
Sometimes yes, sometimes no. My opinion isn't solely based on the fact that this is the default set by MS. There are numerous reasons not to include debug symbols in release builds, and several to include them. In my experience, the reasons not to include them usually weigh heavier then the reasons to include them.
Dave Abrahams wrote:
You can create your own build process that doesn't use Boost.Build. There's not much that's unusual about building Boost.Threads. The only thing out of the ordinary is the need to create an additional DLL build for the threadmon stuff, but you shoud be able to figure this out by looking at the Jamfile even with out having any knowledge of Jam. If you have problems with this I can provide some help.
Why would anyone go to all the trouble?
myjam -sTOOLS=msvc "-sBUILD=release <debug-symbols>on"
works fine for me. This kind of stuff is what Boost.Build is good at.
Thanks. You learn something new everyday. Bill Kempf
"bill_kempf" <williamkempf@hotmail.com> wrote in message news:aamem2+94pb@eGroups.com... to learn Boost.Build)
You can create your own build process that doesn't use Boost.Build. There's not much that's unusual about building Boost.Threads. The only thing out of the ordinary is the need to create an additional DLL build for the threadmon stuff, but you shoud be able to figure this out by looking at the Jamfile even with out having any knowledge of Jam. If you have problems with this I can provide some help.
Why would anyone go to all the trouble? myjam -sTOOLS=msvc "-sBUILD=release <debug-symbols>on" works fine for me. This kind of stuff is what Boost.Build is good at. -Dave
--- In Boost-Users@y..., "David Abrahams" <david.abrahams@r...> wrote:
Why would anyone go to all the trouble?
myjam -sTOOLS=msvc "-sBUILD=release <debug-symbols>on"
works fine for me. This kind of stuff is what Boost.Build is good at.
Oh, whoops! To get a PDB you need to use the <debug-store>database feature as well: myjam -sTOOLS=msvc "-sBUILD=release <debug-symbols>on <debug- store>database" Otherwise, <debug-store> defaults to "object", which puts info in the object files(/Z7).
--- In Boost-Users@y..., "dave_abrahams" <david.abrahams@r...> wrote:
--- In Boost-Users@y..., "David Abrahams" <david.abrahams@r...> wrote:
Why would anyone go to all the trouble?
myjam -sTOOLS=msvc "-sBUILD=release <debug-symbols>on"
works fine for me. This kind of stuff is what Boost.Build is good at.
Oh, whoops! To get a PDB you need to use the <debug-store>database feature as well:
myjam -sTOOLS=msvc "-sBUILD=release <debug-symbols>on <debug- store>database"
Otherwise, <debug-store> defaults to "object", which puts info in the object files(/Z7).
Hmmm ... just tried this, but didn't quite work. I got libboost_threadmon built with .pdb in both release and debug builds, but not libboost_thread. Was the <debug-store> flag introduced after the 1.27.0 release? // Johan
"judoka1981" <johan.nilsson@esrange.ssc.se> wrote in message news:ab5tpi+31nh@eGroups.com...
--- In Boost-Users@y..., "dave_abrahams" <david.abrahams@r...> wrote:
--- In Boost-Users@y..., "David Abrahams" <david.abrahams@r...>
Hmmm ... just tried this, but didn't quite work. I got libboost_threadmon built with .pdb in both release and debug builds, but not libboost_thread.
In my bin directory I see: boost_threadmon.dll/msvc/release/debug-symbols-on/runtime-link-dynamic/threa ding-multi/boost_threadmon.pdb boost_threadmon.dll/msvc/release/debug-symbols-on/runtime-link-dynamic/threa ding-multi/vc60.pdb libboost_thread.lib/msvc/release/debug-symbols-on/runtime-link-dynamic/threa ding-multi/vc60.pdb Were you expecting something different?
Was the <debug-store> flag introduced after the 1.27.0 release?
Yes.
--- In Boost-Users@y..., "David Abrahams" <david.abrahams@r...> wrote:
"judoka1981" <johan.nilsson@e...> wrote in message news:ab5tpi+31nh@e...
--- In Boost-Users@y..., "dave_abrahams" <david.abrahams@r...>
wrote:
--- In Boost-Users@y..., "David Abrahams" <david.abrahams@r...>
Hmmm ... just tried this, but didn't quite work. I got libboost_threadmon built with .pdb in both release and debug
builds,
but not libboost_thread.
In my bin directory I see:
boost_threadmon.dll/msvc/release/debug-symbols-on/runtime-link- dynamic/threa ding-multi/boost_threadmon.pdb boost_threadmon.dll/msvc/release/debug-symbols-on/runtime-link- dynamic/threa ding-multi/vc60.pdb libboost_thread.lib/msvc/release/debug-symbols-on/runtime-link- dynamic/threa ding-multi/vc60.pdb
Were you expecting something different?
I expected the .pdb files for libboost_thread as well. The answer below explains why I didn't get them. Thanks // Johan
Was the <debug-store> flag introduced after the 1.27.0 release?
Yes.
--- In Boost-Users@y..., "David Abrahams" <david.abrahams@r...> wrote:
"bill_kempf" <williamkempf@h...> wrote in message news:aamem2+94pb@e... to learn Boost.Build)
You can create your own build process that doesn't use
There's not much that's unusual about building Boost.Threads. The only thing out of the ordinary is the need to create an additional DLL build for the threadmon stuff, but you shoud be able to
Boost.Build. figure
this out by looking at the Jamfile even with out having any knowledge of Jam. If you have problems with this I can provide some help.
Why would anyone go to all the trouble?
myjam -sTOOLS=msvc "-sBUILD=release <debug-symbols>on"
works fine for me. This kind of stuff is what Boost.Build is good at.
-Dave
participants (5)
-
bill_kempf -
dave_abrahams -
David Abrahams
-
Jim M -
judoka1981