Re:[boost] (For me a) showstopper [was: boost thread static library]
Stefan Slapeta wrote:
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:
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!
I'm not sure I'm following all this. Given that you are understand what the consequences of building and using a static library in this context, and you decide that they are not a problem for you, what prevents you from building your own statically linked library and using it in your own projects? Wouldn't that solve your whole issue Robert Ramey
Robert Ramey wrote:
Stefan Slapeta wrote:
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:
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!
I'm not sure I'm following all this. Given that you are understand what the consequences of building and using a static library in this context, and you decide that they are not a problem for you, what prevents you from building your own statically linked library and using it in your own projects? Wouldn't that solve your whole issue
His problem is that if he builds a statically linked library and uses the Boost threads library, he will be using a shared library and all the shared RTL libraries also, since that is what the shared Boost threads library needs to work. I also have found that mixing static and shared libraries in any situation quite often leads to problems. In this latter respect, one should use all shared libraries or all static libraries, instead of mixing in both.
// Edward Diener wrote: // // His problem is that if he builds a statically linked library // and uses the // Boost threads library, he will be using a shared library and // all the shared // RTL libraries also, since that is what the shared Boost // threads library // needs to work. // No, that was not my point. You CAN'T build anything here using a static rt library anymore, what means that it's not possible to use the static and dynamic runtime library TOGETHER, either! Because of the auto_link feature in Boost 1.31.0, any attempt to include a boost.thread header results in the error message "Mixing a dll boost library with a static runtime is a really bad idea...". This is not only the case for the thread library itself but for every other translation unit, too. After you disable the auto_link feature, you still have to fight against the incompatible __declspec(dllimport) directives (intended for the dynamic rt). // I also have found that mixing static and shared libraries in // any situation // quite often leads to problems. In this latter respect, one // should use all // shared libraries or all static libraries, instead of mixing in both. //
From my experience, I can just second that.
Stefan
// -----Original Message----- // From: boost-bounces@lists.boost.org // [mailto:boost-bounces@lists.boost.org] On Behalf Of Robert Ramey // // I'm not sure I'm following all this. Given that you are // understand what the // consequences of building and using a static library in this // context, and you // decide that they are not a problem for you, what prevents // you from building // your own statically linked library and using it in your own projects? // Wouldn't that solve your whole issue // Robert Ramey // I see two problems: 1. IMHO, it's not possible to create a static thread library without modifying the boost code (first, disabling the auto_link feature, second, eliminate the declspec macros in thread/detail/config.hpp). 2. The clear absence of future support for a static thread library (and, more important than that, for a static runtime library!). I would be glad if there were a commitment to a static thread library without tss. Stefan
"Stefan Slapeta" <stefan@slapeta.com> wrote in message news:200402182203.XAA22397@stud3.tuwien.ac.at...
// -----Original Message----- // From: boost-bounces@lists.boost.org // [mailto:boost-bounces@lists.boost.org] On Behalf Of Robert Ramey // // I'm not sure I'm following all this. Given that you are // understand what the // consequences of building and using a static library in this // context, and you // decide that they are not a problem for you, what prevents // you from building // your own statically linked library and using it in your own
projects?
// Wouldn't that solve your whole issue // Robert Ramey //
I see two problems:
1. IMHO, it's not possible to create a static thread library without modifying the boost code (first, disabling the auto_link feature, second, eliminate the declspec macros in thread/detail/config.hpp).
So it isn't possible to do this by defining the appropriate macros (on the command line, in the IDE settings, by using the appropriate #defines before you include the Boost.Thread headers, etc.)? I haven't tried this or looked into it at all, I'm just asking what you've tried already.
2. The clear absence of future support for a static thread library (and, more important than that, for a static runtime library!). I would be glad if there were a commitment to a static thread library without tss.
As I said, I plan to look into the feasibility of adding back static library support, limiting features as necessary. I'm afraid that until I look into it I can't commit to it any more than to say that I would really like to have static library support for some of my own projects, so I'm motivated to make it work if practical. A complicating factor is that I believe some new Boost.Thread features (currently existing only in the thread_dev branch in cvs so far, though I hope to migrate them to the main branch over the next few weeks) require tss support, so a static library that disabled tss would have to disable those features as well. I plan to look into this further soon. Though I've only built and used the Win32 version of Boost.Thread so far, it sounds as if static library support should at least be aded back for non-Win32 platforms, which don't have the dynamic library requirement. Is that correct? Mike
Stefan
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Michael Glassford wrote:
So it isn't possible to do this by defining the appropriate macros (on the command line, in the IDE settings, by using the appropriate #defines before you include the Boost.Thread headers, etc.)? I haven't tried this or looked into it at all, I'm just asking what you've tried already.
I don't see this option out of thread/detail/config.hpp (it's not tested whether the macro is set already). Anyway, just eliminating the macro would be a much cheaper solution (manually setting the macro for each project isn't very easy, either).
As I said, I plan to look into the feasibility of adding back static library support, limiting features as necessary. I'm afraid that until I look into it I can't commit to it any more than to say that I would really like to have static library support for some of my own projects, so I'm motivated to make it work if practical.
Great!
A complicating factor is that I believe some new Boost.Thread features (currently existing only in the thread_dev branch in cvs so far, though I hope to migrate them to the main branch over the next few weeks) require tss support, so a static library that disabled tss would have to disable those features as well. I plan to look into this further soon.
That's a trade-off boost.thread users have to deal with in the future [and with NEW features]. The most important thing is that no _existing_ code is broken.
Though I've only built and used the Win32 version of Boost.Thread so far, it sounds as if static library support should at least be aded back for non-Win32 platforms, which don't have the dynamic library requirement. Is that correct?
I'm not sure if I understood correctly what you mean. Stefan
"Stefan Slapeta" <stefan@slapeta.com> wrote in message news:c1264r$hor$1@sea.gmane.org...
Michael Glassford wrote:
Though I've only built and used the Win32 version of Boost.Thread so far, it sounds as if static library support should at least be aded back for non-Win32 platforms, which don't have the dynamic library requirement. Is that correct?
I'm not sure if I understood correctly what you mean.
Sorry. I meant two things: 1) Boost.Thread requires a dynamic library to fix a Win32 problem. 2) Someone, earlier in this thread, I believe, pointed out that the ability to compile Boost.Thread as a static lib had been removed on non-Win32 platforms for no reason. I was suggesting that, if both these facts are true, support for compiling Boost.Thread as a static library should at least be added back for non-Win32 platforms.
Stefan
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Michael Glassford wrote:
Sorry. I meant two things:
1) Boost.Thread requires a dynamic library to fix a Win32 problem.
2) Someone, earlier in this thread, I believe, pointed out that the ability to compile Boost.Thread as a static lib had been removed on non-Win32 platforms for no reason.
I was suggesting that, if both these facts are true, support for compiling Boost.Thread as a static library should at least be added back for non-Win32 platforms.
Why just for non-Win32 platforms? I would suggest having a static lib also for Win32, but without tss (as this needs the dll version). Stefan
Michael Glassford wrote:
Sorry. I meant two things:
1) Boost.Thread requires a dynamic library to fix a Win32 problem.
2) Someone, earlier in this thread, I believe, pointed out that
"Stefan Slapeta" <stefan@slapeta.com> wrote in message news:c1cr8h$8tr$1@sea.gmane.org... the
ability to compile Boost.Thread as a static lib had been removed on non-Win32 platforms for no reason.
I was suggesting that, if both these facts are true, support for compiling Boost.Thread as a static library should at least be added back for non-Win32 platforms.
Why just for non-Win32 platforms?
I would suggest having a static lib also for Win32, but without tss (as this needs the dll version).
That's why I said "at least". The reason I was posting is that, if I understand correctly, the non-Win32 static library builds should be restored since there was no reason for their removal. Since I don't use any of those platforms, I was asking for a comment from those who do whether this is a correct statement. In addition, the "at least" above implies, and other postings of mine explicitly state, that as far as possible (either by means of limiting features, or by means of Roland's pseudo-dll approach), I would like to restore static libraries in Win32 builds. Since I haven't yet attempted this, and since the static library in Win32 builds was removed for good reasons by the original Boost.Thread maintainer, I can't promise that this will work out, as I also stated elsewhere. Mike
Stefan
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (7)
-
Edward Diener -
Michael Glassford -
Robert Ramey -
Stefan Slapeta