* First time round I figured that the right place to unpack the zip archive was to the place I ultimately wanted the include files to be (say /usr/local/include), because it's only when you get to the build binaries stuff that the whole copy/build thing is mentioned. Ok, so I should have read all the instructions first, but maybe this could be made clearer earlier.
* Having come finally to step 5, the whole 'path/to/installation' thing appears, so I backtracked and put my zip expansion somewhere else. I'm keen to set this up so that I can support several boost versions, so am using the --prefix argument to bootstrap. I think I also need to supply this argument to bjam, at least it seemed to work that way. Boost build process is not different than that of *any other* linux autotools-based package: configure --prefix=, make, sudo make install In boost it is the quite same: booststrap.sh --prefix=,bjam, sudo bjam install I hope you don't build anything in /usr/local or /usr as root?!? Doing `make clean` (or `bjam clean`) will teach you not to do so '< '< '<
* Then I came to link the example regex program... what is all that stuff about library naming? I didn't seem to have libraries with names like that at all, my regex libraries were libboost_regex.{a,so,so.1.45.0}, so I used that, and I still don't know what all the stage stuff is about - it seemed to work without it, but maybe there's something that's going to bite me.
I believe you have right to report any compile-time or link-time issue during build process as full-weight PR to "Building Boost" component.
* Finally my link was failing with "`GLIBCXX_3.4.14' not found", which Googling seemed to suggest was because I need Fedora 14 libstdc++. So I installed that, and now it seems to work.. so far!
I don't know things about Fedora, but usually mixing different versions of libstdc++ in a single project is very wrong thing to do. Unless you're going to learn libstdc++ internals much better with gdb ;) Regards, Slava