since I am a newby here, I consider myself excused for behaving like one, and posting lengthy answers line by line. Here is one.
Nice work, Hamlet!
It looks like we've been trodding some of the same ground, unfortunately. I probably should have posted the patches I was using to make latest SVN build, but even though it built, it would not run. And I wasn't confident that some of the patches I'd applied were robust enough for all OSes, so I never published them. My apologies if that caused you any wasted time.
Let me stress one point: my "work" was with a totally amateur approach, aimed to "make it work".
I did "waste" some time, mostly due to my inability to find and/or understand the documentation (I went through compiling and installing DarkRadiant believing it was a newer version of The Dark Mod, I let you imagine my surprise when I started it... at least it explained the different style and level of the code). I am ashamed to admit, I actually quite enjoyed the process.
I think your 'inline.patch' accomplishes the same thing that my 2 DevIL imaging library patches (used against 2.04 source code in this case) did from this post. But it looks like we took different approaches. I haven't had a chance yet to see what the effect of the different approaches might be, but I'll take a closer look tomorrow.
Yes. I did not use yours because when I started that work, one week ago, I had no account on this forum and therefore I would be denied access to your attached files .
You decided to make the extern inline static inline, I just made them inline. It's a subtle difference, and I am used to a different pattern completely where those functions are either defined only in their library and only declared in the header, or defined in the header as inline. Anyway, I suggest you not to waste your time with this patch of mine.
I think Crinkelite and duzenko (both now, at least part-time, running 32-bit Ubuntu 16.10 with GCC 6.2.0, IIRC) will be able to use your 'pugi_strings.patch' to great advantage. I'm running GCC 5.3.0 compared to your 5.4.0, and I've never seen those errors. But I'll still apply your patch to make sure that it has no negative effect, as an extra datapoint for those who decide to apply it.
Note that that patch alone will not be enough. I believe the lack of a forwarding header for string as there is iosfwd for iostream is a known "problem" (cf. http://www.gotw.ca/gotw/034.htm), but that would not help neither.
My understanding of the problem is: the precompiled Boost libraries want the type of std::string that was where they were compiled (I grasped Ubuntu 10.10, maybe?), while the program uses the system ones. The code was declaring std::basic_string as in the distributed Boost, my patch as the system one; but the discrepancy is still there and will come out at link time.
Boost and C++ STL are very tightly bound, and the best option is rely on the system one for both. It comes with a price, since Boost interface is not exactly stable. Distributing both Boost and STL would be madness though. Which brings us to your comment that...
As for the Boost libraries, I've taken a different tack, which I had not yet discussed on the forum before now. Just a few days ago, I'd compiled and run TDM using the Boost headers and library that come with Slackware 14.2 (and probably a lot of other Linux distros these days), thereby dropping 124 MB (!!!) of header files and about 7 MB of static library files from the TDM source distribution. But I was waiting to bring that up until after the 2.05-beta hubbub died down. I just wanted to prove that I could compile and run TDM without the TDM-supplied Boost stuff and it worked perfectly. A lot of that other build stuff could stand some attention too, IMHO. It's all on my list, but I just don't have enough time ATM.
... if I read your text right, it's not a different tack at all, it's exactly the same. I have used Boost 1.62.0, and it worked amazingly well. But my "shell patch" hard-codes the path of the libraries in my system, so it's no good.
My best bet would be to tell the linker nothing about where they are, and expect them in the standard library directories which are always checked.
One comment on your 'build_tuning.patch'.... With my SCons patch, there should be no need to do the 'touch scons.signatures.dblite' step in the 'linuxBuild.sh' file at all now, which is why that patch eliminated it entirely. Did you find that it's still needed on your setup? Just curious. I'm pretty sure that if you deleted the signature file, SCons will still work, but as my post mentioned, that was not the case in the past, hence someone's addition of the 'touch' in the script as a less-than-optimal work-around.
The reason I added that was I saw a complaint "that file does not exist", and I though "why not to touch it in that case". But I admit I can't reproduce that message with the head version.
The number of jobs patch is good to go and I endorse its merging. The other is good for me and you, but not for a distributed binary. If the librarian builds the executable for the processor that has become available tomorrow, and my PC is five years old, I won't be able to run it. Ok, pentium3 is maybe a bit too conservative...
Thanks again for the patches! I hope that they'll be put to good use reasonably soon.
I stress one last time the "caveat emptor" message and the fact that they are not great stuff. But once a direction is chosen some of that stuff can be made well. I think especially to the decision about Boost.