PDB files missing from Windows binaries
First, I want to give a big thank for the streamlined availability of precompiled Windows binaries. The "Windows binaries" link from the Boost download webpage significantly lowers the barriers for Boost usage on the Windows platform. That said, there seem to be an issue with missing PDB files from the most recent Boost 1.55 binaries. This makes it difficult to debug applications, since debug information is missing. I suspect that the reason for the missing PDBs is that the build script doesn't install them to the target folder, which have previously been reported on [1]. Unfortunately, there has been little response to this problem. Would if be possible for someone to look into this problem, and improve the build script? [1] http://lists.boost.org/boost-build/2013/08/26894.php Thanks in advance, Fredrik
On Thu, Nov 21, 2013 at 12:32 AM, Fredrik Orderud <forderud@gmail.com>wrote:
First, I want to give a big thank for the streamlined availability of precompiled Windows binaries. The "Windows binaries" link from the Boost download webpage significantly lowers the barriers for Boost usage on the Windows platform.
That said, there seem to be an issue with missing PDB files from the most recent Boost 1.55 binaries. This makes it difficult to debug applications, since debug information is missing.
I suspect that the reason for the missing PDBs is that the build script doesn't install them to the target folder, which have previously been reported on [1]. Unfortunately, there has been little response to this problem.
Would if be possible for someone to look into this problem, and improve the build script?
Does anyone know if there is a bjam option to stage PDBs with the libraries? Even if there is a simple solution for that, I'm not sure we'd want to put the PDBs into the binary packages on sourceforge. PDBs are often very large, and if it would double or triple the package size, that doesn't seem like it would be worth it. If you need PDBs I'd recommend just building yourself (but that still has the same problem with them not being staged). Tom
On Thu, Nov 21, 2013 at 07:32:22AM +0100, Fredrik Orderud wrote:
First, I want to give a big thank for the streamlined availability of precompiled Windows binaries. The "Windows binaries" link from the Boost download webpage significantly lowers the barriers for Boost usage on the Windows platform.
That said, there seem to be an issue with missing PDB files from the most recent Boost 1.55 binaries. This makes it difficult to debug applications, since debug information is missing.
If all you want is debug information and don't care overly much about distribution size, there's also always the good old /C7 flag to embed debug information in the libraries themselves. -- Lars Viklund | zao@acc.umu.se
On 21 Nov 2013 at 17:13, Lars Viklund wrote:
That said, there seem to be an issue with missing PDB files from the most recent Boost 1.55 binaries. This makes it difficult to debug applications, since debug information is missing.
If all you want is debug information and don't care overly much about distribution size, there's also always the good old /C7 flag to embed debug information in the libraries themselves.
I think you meant /Z7? I very much +1 this approach of embedding debug info straight into the DLLs. Sadly Microsoft appear to have removed the old /Zd flag for generation the absolute most smallest embedded debug info, so /Z7 is your only option remaining. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On 25/11/2013 10:00, Quoth Niall Douglas:
I very much +1 this approach of embedding debug info straight into the DLLs. Sadly Microsoft appear to have removed the old /Zd flag for generation the absolute most smallest embedded debug info, so /Z7 is your only option remaining.
There's a good reason for them being separate: DLLs tend to be mapped almost directly into the process memory space, and debug information tends to be about 10x the size of the DLL itself. (And typically accessed more rarely/randomly.)
On 25 Nov 2013 at 11:55, Gavin Lambert wrote:
On 25/11/2013 10:00, Quoth Niall Douglas:
I very much +1 this approach of embedding debug info straight into the DLLs. Sadly Microsoft appear to have removed the old /Zd flag for generation the absolute most smallest embedded debug info, so /Z7 is your only option remaining.
There's a good reason for them being separate: DLLs tend to be mapped almost directly into the process memory space, and debug information tends to be about 10x the size of the DLL itself. (And typically accessed more rarely/randomly.)
I can't say I care on 64 bit. Fair enough on 32 bit, hence my pain at the loss of /Zd in recent MSVCs. The extra debug info also makes the download quite a bit larger. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
participants (5)
-
Fredrik Orderud -
Gavin Lambert -
Lars Viklund -
Niall Douglas -
Tom Kent