Vladimir Prus wrote:
I don't know if the current solution is right.
Nod. BTW I didn't ask for the current situation, it was rather foisted upon us by the change to build and install a single binary. We can fix up Boost.Config to behave any way we want, as long as everyone agrees! :-)
libstdc++ will work no matter if your application is ST or MT -- where "MT" application is defined as application that links to pthread and actually creates multiple threads. But I think it's result of explicit work. In particular:
- ABI is the same in ST and MT builds - if application is not linked to pthreads, then libstdc++ will use dummy functions for synchronisation, with almost zero overhead.
Boost, on the other hand, does not do anything special. The overhead of locking does not go away if application does not use threads.
Unless we're also linking to the dummy pthread lib? I thought that was what happened automatically on Linux at least anyway, unless you explicitly linked to -lpthread?
Therefore, it makes sense to control if that overhead exists -- by explicitly controlling if Boost should be built in ST or MT mode, as selected by 'threading' feature in Boost.Build or by -pthread command line option in gcc.
Just always building in MT mode is easy, but I don't know if that's the best solution.
Nod. As I say, just tell me what the solution is and we can go for it :-) John.