Alo Sarv
lead developer

Donate via

Latest Builds

version 0.3
tar.gz tar.bz2
Boost 1.33.1 Headers
MLDonkey Downloads Import Module Development
Payment completed
Development in progress.
Developer's Diary

Wednesday, February 09, 2005

Compiler problems, misc stuff

Apparently, the new PartData, along with the usage of Boost.MultiIndex library turned out to be a compiler-killer. At current state, I have MSVC 7.1 [win32] crashing on me, GCC 3.3.5 and GCC 3.4.3 [linux] giving crapload of linker warnings (GNU ld bug, resolved in GCC 4.0 branch), GCC 3.3 crashing when debug symbols (-g, -ggdb) are enabled (compiler bug related to very long symbol names inherent from hardcore template metaprogramming used by the multiindex lib), and GCC 3.3 [darwin] crashing on OSX even when debug symbols are disabled.

On MSVC side, I investigated the issues, and have narrowed the list of problems down somewhat (they seem to be related to tags usage), but actual fixes are still not there yet. There also seems problems with MSVC handling the new Range API code (it can't handle some constructs there), so more work is needed towards that end too. I still have no extended information on what's causing the GCC [linux] linker warnings (except for bunch of compiler patches), and one or two possible workarounds for the GCC 3.3 debug symbols handling issues (I currently disabled debug symbols generation when compiling with 3.3 automatically). As for GCC crashing on darwin, I'm not sure yet whether it's compiler bug, or the fact that my iMac is too old and simply runs out of resources - perhaps someone with faster Mac could try compiling current CVS ?

On other news, next few days I need to take care of some real life stuff, so I might be offline for long hours. I hope to be able to return to coding near the end of the week at latest - we'r SOO close to finally having stable downloading capabilities, so can't wait to get other things out the way so I can return to coding.

Madcat, ZzZz


I've been following your experiences with Boost.MultiIndex. Seems like your current problem has to do, as you point out, with the huge lengths of symbol names generated by the definition of ChunkMap. The following technique effectively reduces those lengths, so you might want to give it a try. Instead of defining ChunkMap as:

typedef boost::multi_index_container<
// indices
> ChunkMap;

do it as follows:

struct ChunkMapIndices:
// indices
typedef boost::multi_index_container<
> ChunkMap;

The trick lies in that ChunkMapIndices is not a typedef but a real type definition, and "ChunkMapIndices" is so much shorter than "boost::multi_index::indexed_by<...>". Hope this helps.

Another way to reduce symbol lengths is to avoid tags altogether; you could then define ID_Pos, ID_Verified, etc. to be enums to the appropriate index (this is less maintainable than real tags, but anyway.)

If this doesn't do it or you have another Boost.MultiIndex-related problems I'd be glad to try to help. My email address is joaquin at

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
Thanks, this information was very useful. After applying the above tricks, it now compiles again (at least on MSVC). Thanks :)

Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?