boost thread static library
Hi all, I just built boost 1.31.0 (windows, with mingw toolset), and I can't find the static thread library. Did I do something wrong or is it no longer supported (it was there at least in 1.29)? Thanks, Arkadiy _________________________________________________________________ Find and compare great deals on Broadband access at the MSN High-Speed Marketplace. http://click.atdmt.com/AVE/go/onm00200360ave/direct/01/
It is no longer supported: the tss class requires Boost.Thread to be in a dll to be able to clean up after itself properly (i.e. to prevent leaks). It would be possible to build a version that doesn't include support for this, but in a future version of Boost.Thread (currently in the thread_dev branch of CVS), I believe several new features depend on this support being available so it may not be worthwhile to do so. Mike "Arkadiy Vertleyb" <vertleyb@hotmail.com> wrote in message news:Law12-F123Sjddw75A00000fb8a@hotmail.com...
Hi all,
I just built boost 1.31.0 (windows, with mingw toolset), and I can't find the static thread library. Did I do something wrong or is it no longer supported (it was there at least in 1.29)?
Thanks,
Arkadiy
_________________________________________________________________ Find and compare great deals on Broadband access at the MSN High-Speed Marketplace. http://click.atdmt.com/AVE/go/onm00200360ave/direct/01/
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Michael Glassford wrote:
It is no longer supported: the tss class requires Boost.Thread to be in a dll to be able to clean up after itself properly (i.e. to prevent leaks). It would be possible to build a version that doesn't include support for this, but in a future version of Boost.Thread (currently in the thread_dev branch of CVS), I believe several new features depend on this support being available so it may not be worthwhile to do so.
Hi Michael, I realise this wouldn't be recommended practice, but would these leaks only occur when resources (by that I mean mutexes, threads, conditions etc) deleted? As I've said, I create all needed objects at application startup and free them at exit, so I'm not so worried about leaks as they wouldn't be happening while the application is running, only at the end when the OS should clean up anyway? If so, then I am willing to risk running the thread library as a static lib still. Thanks Russell
Michael Glassford wrote:
It is no longer supported: the tss class requires Boost.Thread to be in a dll to be able to clean up after itself properly (i.e. to
leaks). It would be possible to build a version that doesn't include support for this, but in a future version of Boost.Thread (currently in the thread_dev branch of CVS), I believe several new features depend on this support being available so it may not be worthwhile to do so.
Hi Michael, I realise this wouldn't be recommended practice, but would these leaks only occur when resources (by that I mean mutexes,
"Russell Hind" <rhind@mac.com> wrote in message news:c0v6vs$5mu$1@sea.gmane.org... prevent threads,
conditions etc) deleted?
In current versions of the library, the leaks I'm referring to would only happen if you actually used the boost::tss class.
As I've said, I create all needed objects at application startup and free them at exit, so I'm not so worried about leaks as they wouldn't be happening while the application is running, only at the end when the OS should clean up anyway? If so, then I am willing to risk running the thread library as a static lib still.
Yes, this is certainly possible. I do something very similar myself in one application I work on, and it works quite well.
Thanks
Russell
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Michael Glassford wrote:
It is no longer supported: the tss class requires Boost.Thread to be in a dll to be able to clean up after itself properly (i.e. to prevent leaks). It would be possible to build a version that doesn't include support for this, but in a future version of Boost.Thread (currently in the thread_dev branch of CVS), I believe several new features depend on this support being available so it may not be worthwhile to do so.
There's one more big "surprise": the need for the shared runtime libraries! I'm very frustrated at the moment because I don't know which strategy to choose for boost.thread at all: - IMO, it's not a 'little fish' to change the runtime libraries of all projects that use Boost.Thread. This and the necessity to ship an additional boost.thread dll is, at least for me and our company, at the moment an absolute showstopper for moving to a future release of boost! It is not easy to explain the costs for deploying the shared runtime library on some thousand machines. Personally, I'm very disappointed as it seems to be possible in boost, that a whole library becomes unusable for me in a future release. [Not the best example of backward compatibility!] - There is NO WORD about that in the whole documentation. If there is one, you hid it very well! What is even worse: there is no word about ANY CHANGES in boost thread in the release notes! Sorry for this critisism. I know about all your efforts and appreciate them very much. This time it seems that the need for new functionality broke too much of existing code for my taste! br, Stefan
Stefan Slapeta wrote:
- IMO, it's not a 'little fish' to change the runtime libraries of all projects that use Boost.Thread. This and the necessity to ship an additional boost.thread dll is, at least for me and our company, at the moment an absolute showstopper for moving to a future release of boost! It is not easy to explain the costs for deploying the shared runtime library on some thousand machines. Personally, I'm very disappointed as it seems to be possible in boost, that a whole library becomes unusable for me in a future release. [Not the best example of backward compatibility!]
Well it isn't boosts' fault. It is a limitation in the way win32 handles thread cleanup and stuff and currently there isn't a work-around for it. I suggest bug reports to Microsoft rather than having a go at the volunteer boost developers.
- There is NO WORD about that in the whole documentation. If there is one, you hid it very well! What is even worse: there is no word about ANY CHANGES in boost thread in the release notes!
Ok, this I agree with. There was no mention of this in the changes for 1.30.x and there probably should have been, but it is fairly obvious the first time you build boost::thread from 1.30.x that it isn't there, so stick with 1.29.0 until you are at a stage where distributing shared runtimes might be possible. We can't blame boost developers for limitations in the windows OS itself. Cheers Russell
Russell Hind wrote:
Well it isn't boosts' fault. It is a limitation in the way win32 handles thread cleanup and stuff and currently there isn't a work-around for it. I suggest bug reports to Microsoft rather than having a go at the volunteer boost developers.
It wasn't my intention to blame boost developers for a win32 defect - sorry if anybody got this impression! It just regret seeing the current boost library breaking all my thread projects; that's the point.
Ok, this I agree with. There was no mention of this in the changes for 1.30.x and there probably should have been, but it is fairly obvious the first time you build boost::thread from 1.30.x that it isn't there, so stick with 1.29.0 until you are at a stage where distributing shared runtimes might be possible.
Yes and no! As I mentioned, we talk about TWO changes here: The first - disabling the static library for boost.thread - was made in 1.30.0. BUT: there was a (more or less dirty) workaround in disabling a macro in thread/detail/config.hpp + building an own static library without the tss class (and cpp file). This worked if you didn't use tss (which many of us don't). The second - forcing boost to use the shared rt lib - is new with 1.31.0. A possible workaround for this could be disabling the auto_link macro in config/user.hpp. It seems that now after applying these two 'patches' boost.thread 'works' again as static lib and, more important than that, without the dynamic rt. I consider the latter point very critical for large companies as it is simply very expensive in administration to install the shared rt on thousands of machines, each having its own os and configuration! Once I have to do this also for the rest of the thread library (means: not just for tss), this could be a clear economic argument against using boost.threads in the future at all, which I would regret even more. What I want to say: PLEASE enable the use of the static runtime in boost.thread for users who don't need any other functionality than the 'pure' thread library, again! Best regards, Stefan
On Wed, 18 Feb 2004 15:01:54 +0100 Stefan Slapeta <stefan@slapeta.com> wrote:
What I want to say: PLEASE enable the use of the static runtime in boost.thread for users who don't need any other functionality than the
'pure' thread library, again!
The change went a bit further, as I mentioned previously, in that even on linux machines the builds do not create static libs. I think it reasonable that the libs can be built both static and dynamic, like everything else, but the documentation can state that the static libs (on win32) should only be used for certain circumstances. Unless I am missing something, if they are conditionally compiled, then the link will fail to find the proper symbols anyway. -- Jody Hagins "If you are beginning to doubt what I am saying, you are probably hallucinating." -- The Firesign Theatre, _Everything you know is Wrong_
Stefan Slapeta wrote:
As I mentioned, we talk about TWO changes here:
...
The second - forcing boost to use the shared rt lib - is new with 1.31.0. A possible workaround for this could be disabling the auto_link macro in config/user.hpp.
Sorry, missed the second part. I only briefly tried 1.31.0 but am sticking with 1.30.2 for now. When I built it, I added BOOST_ALL_NO_LIB as a define for the application (and I think for the library as well, but can't remember) HTH Russell
Russell Hind wrote:
Sorry, missed the second part. I only briefly tried 1.31.0 but am sticking with 1.30.2 for now. When I built it, I added
BOOST_ALL_NO_LIB
as a define for the application (and I think for the library as well, but can't remember)
I was inprecise. That's what I meant. Stefan
Michael Glassford wrote:
It is no longer supported: the tss class requires Boost.Thread to be in a dll to be able to clean up after itself properly (i.e. to
leaks). It would be possible to build a version that doesn't include support for this, but in a future version of Boost.Thread (currently in the thread_dev branch of CVS), I believe several new features depend on this support being available so it may not be worthwhile to do so.
There's one more big "surprise": the need for the shared runtime libraries! I'm very frustrated at the moment because I don't know which strategy to choose for boost.thread at all:
- IMO, it's not a 'little fish' to change the runtime libraries of all projects that use Boost.Thread. This and the necessity to ship an additional boost.thread dll is, at least for me and our company, at
"Stefan Slapeta" <stefan@slapeta.com> wrote in message news:c0vg2l$so7$1@sea.gmane.org... prevent the
moment an absolute showstopper for moving to a future release of boost! It is not easy to explain the costs for deploying the shared runtime library on some thousand machines.
I'm aware of this cost as I have the same problem myself. As I mentioned in another post, it is still possible, if you are aware of the issues involved and set up an appropriate build yourself, to use Boost.Thread in a static library. For what it's worth, I'm hoping to investigate what it would take to make Boost.Thread support a static library option again in the future. If such a thing ever happened (no promises), it would have to be a version in which features that require the dll are disabled.
Personally, I'm very disappointed as it seems to be possible in boost, that a whole library becomes unusable for me in a future release. [Not the best example of backward compatibility!]
- There is NO WORD about that in the whole documentation.
True, and this should be fixed.
If there is one, you hid it very well!
I'm not the one who made the change, only the messenger who's telling you about them.
What is even worse: there is no word about ANY CHANGES in boost thread in the release notes!
That's because this change is quite old. If I remember correctly, it was made in the 1.30 release.
Sorry for this critisism. I know about all your efforts and
appreciate
them very much. This time it seems that the need for new functionality broke too much of existing code for my taste!
br, Stefan
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Wed, 18 Feb 2004 07:04:07 -0500 Michael Glassford <glassfordm@hotmail.com> wrote:
For what it's worth, I'm hoping to investigate what it would take to make Boost.Thread support a static library option again in the future. If such a thing ever happened (no promises), it would have to be a version in which features that require the dll are disabled.
Mike, this is a rather conservative estimate I think. As I already have tried to show you that this can be done without any omission of features at all. Altough at the price of the application creating a (hidden, temporary) file on the target machine. I am currently trying to create a local modification of the threading library with static linkage, that has full function. I think I should send this to the list for discussion then. (BTW, the DLL version can be left totally unaltered.) Roland
"Roland" <roland.schwarz@chello.at> wrote in message news:20040219074625.ESPZ2453.viefep20-int.chello.at@speedsnail...
On Wed, 18 Feb 2004 07:04:07 -0500 Michael Glassford <glassfordm@hotmail.com> wrote:
For what it's worth, I'm hoping to investigate what it would take
to
make Boost.Thread support a static library option again in the future. If such a thing ever happened (no promises), it would have to be a version in which features that require the dll are disabled.
Mike, this is a rather conservative estimate I think. As I already have tried to show you that this can be done without any omission of features at all. Altough at the price of the application creating a (hidden, temporary) file on the target machine. I am currently trying to create a local modification of the threading library with static linkage, that has full function.
You're absolutely right. The last couple of weeks have been so hectic I temporarily forgot your interesting "pseudo-dll" solution, and I apologize. Thanks for reminding me and and for working on it.
I think I should send this to the list for discussion then. (BTW, the DLL version can be left totally unaltered.)
Please do! All my "Boost time" at the moment is spent answering posts and preparing to move things from the thread_dev branch to the main branch a piece at a time (after discussing each piece here first).
Roland
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Arkadiy Vertleyb wrote:
Hi all,
I just built boost 1.31.0 (windows, with mingw toolset), and I can't find the static thread library. Did I do something wrong or is it no longer supported (it was there at least in 1.29)?
There is no static thread library for win32. Search the archives for discussions as to why, but basically the cleanup required for TLS couldn't be implemented unless the library is built as a DLL on win32. If you don't use TLS, then you could possibly build your own static thread library from the source, but that isn't an official recommendation. (I do it, but I create all threads at the start of the application and they exit at the end, so no cleanup is required while the application is running (the OS should cleanup resources when the app exits) but you do this at your own risk) Cheers Russell
On Tue, 17 Feb 2004 19:12:13 +0000 Russell Hind <rhind@mac.com> wrote:
There is no static thread library for win32. Search the archives for discussions as to why, but basically the cleanup required for TLS couldn't be implemented unless the library is built as a DLL on win32.
Actually, I do not get static libs on linux either, so either the change was forced on linux as well, or there is a bug somewhere in the library generation jamfile. I am not familiar with any problems that would prevent a static threaded library for linux platforms... shandalle:jody> bjam -d2 "-sTOOLS=gcc" --builddir=./BUILD > BUILD/jam.out 2>&1 shandalle:jody> find . -name 'libboost_thread*' ./BUILD/bin/boost/libs/thread/build/libboost_thread.so ./BUILD/bin/boost/libs/thread/build/libboost_thread.so/gcc/debug/shared -linkable-true/threading-multi/libboost_thread-gcc-mt-d-1_31.so.1.31.0 ./BUILD/bin/boost/libs/thread/build/libboost_thread.so/gcc/debug/shared -linkable-true/threading-multi/libboost_thread-gcc-mt-d-1_31.so ./BUILD/bin/boost/libs/thread/build/libboost_thread.so/gcc/release/shar ed-linkable-true/threading-multi/libboost_thread-gcc-mt-1_31.so.1.31.0 ./BUILD/bin/boost/libs/thread/build/libboost_thread.so/gcc/release/shar ed-linkable-true/threading-multi/libboost_thread-gcc-mt-1_31.so -- Jody Hagins Desist from enumerating your fowl prior to their emergence from the shell.
participants (6)
-
Arkadiy Vertleyb -
Jody Hagins -
Michael Glassford -
Roland -
Russell Hind -
Stefan Slapeta