[build][wave] tools/wave link failure
I have talked to multiple developers about this, yet none has assumed responsibility, so I'm not sure where to raise this: Building inside boost/tool/wave/build on trunk fails for me due to a link error, since wave wants to link to boost_thread, but doesn't link to -lpthread. (This is the default toolchain on my Fedora 8 box, i.e. GCC.) I'm not sure where the -lpthread needs to be added (I added it manually to the link command and it succeeded), or in fact, why wave links to boost_thread at all. It doesn't use threads underneath, or does it ? Another point I just touched on with Volodya on IRC is that all tools are built against the static boost libraries, presumably because Windows doesn't have the equivalent of -rpath. Could that be changed at least for non-Windows platforms that would allow it ? Thanks, Stefan PS: Thanks for changing the default to only build a single variant. It's *much* more pleasant to work with trunk now ! -- ...ich hab' noch einen Koffer in Berlin...
Following up on my own mail... Stefan Seefeld wrote:
I'm not sure where the -lpthread needs to be added (I added it manually to the link command and it succeeded), or in fact, why wave links to boost_thread at all. It doesn't use threads underneath, or does it ?
It turns out the dependency on boost_thread is dragged in by boost.spirit. (I modified the subject line to reflect this.) I'm not sure in what way boost_thread is used there, but I would hope that the decision to use threads (and boost_thread) could be left to the library's user. Only pay for what you really use, or so the saying goes... Is it possible to modify the config logic to have some users only use the subset of boost.spirit that doesn't require boost_thread ? (I'm writing a preprocessor and I do not want to use threads, so why would I have to link with boost_thread and pthread ?) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan,
I'm not sure where the -lpthread needs to be added (I added it manually to the link command and it succeeded), or in fact, why wave links to boost_thread at all. It doesn't use threads underneath, or does it ?
It turns out the dependency on boost_thread is dragged in by boost.spirit. (I modified the subject line to reflect this.)
I'm not sure in what way boost_thread is used there, but I would hope that the decision to use threads (and boost_thread) could be left to the library's user. Only pay for what you really use, or so the saying goes...
Is it possible to modify the config logic to have some users only use the subset of boost.spirit that doesn't require boost_thread ?
(I'm writing a preprocessor and I do not want to use threads, so why would I have to link with boost_thread and pthread ?)
Wave drags in threads only if it gets compiled in an environment requiring threads (BOOST_HAS_THREADS is defined). If you build Wave such that BOOST_HAS_THREADS is not defined, it won't depend on threads. HTH Regards Hartmut
Hartmut Kaiser wrote:
Stefan,
I'm not sure where the -lpthread needs to be added (I added it manually to the link command and it succeeded), or in fact, why wave links to boost_thread at all. It doesn't use threads underneath, or does it ? It turns out the dependency on boost_thread is dragged in by boost.spirit. (I modified the subject line to reflect this.)
I'm not sure in what way boost_thread is used there, but I would hope that the decision to use threads (and boost_thread) could be left to the library's user. Only pay for what you really use, or so the saying goes...
Is it possible to modify the config logic to have some users only use the subset of boost.spirit that doesn't require boost_thread ?
(I'm writing a preprocessor and I do not want to use threads, so why would I have to link with boost_thread and pthread ?)
Wave drags in threads only if it gets compiled in an environment requiring threads (BOOST_HAS_THREADS is defined). If you build Wave such that BOOST_HAS_THREADS is not defined, it won't depend on threads.
What happens when one wants to use Wave without threads in a platform that has threads? Also... Is a thread safe Wave and Spirit (or Phoenix) that doesn't use Boost Threads available? I.e. are there reentrant versions available? By the way the reason Stefan and I are asking about this is that currently using a static version of Wave doesn't build on some platforms as Boost Threads needs extra user work to build statically. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Rene,
I'm not sure where the -lpthread needs to be added (I added it manually to the link command and it succeeded), or in fact, why wave links to boost_thread at all. It doesn't use threads underneath, or does it ? It turns out the dependency on boost_thread is dragged in by boost.spirit. (I modified the subject line to reflect this.)
I'm not sure in what way boost_thread is used there, but I would hope that the decision to use threads (and boost_thread) could be left to the library's user. Only pay for what you really use, or so the saying goes...
Is it possible to modify the config logic to have some users only use the subset of boost.spirit that doesn't require boost_thread ?
(I'm writing a preprocessor and I do not want to use threads, so why would I have to link with boost_thread and pthread ?)
Wave drags in threads only if it gets compiled in an environment requiring threads (BOOST_HAS_THREADS is defined). If you build Wave such that BOOST_HAS_THREADS is not defined, it won't depend on threads.
What happens when one wants to use Wave without threads in a platform that has threads?
Ok, I added a corresponding configuration option on the trunk. Before that the Wave config looked just at the BOOST_HAS_THREADS macro. Here is the corresponding new snippet from the wave_config.hpp file: // If BOOST_WAVE_SUPPORT_THREADING is not defined, Wave will use the global // Boost build settings (BOOST_HAS_THREADS), if it is defined its value // defines whether threading will be enabled or not (should be set to '0' // or '1'). Does this help? Should I add this to the 1.35 release branch as well? It shouldn't have any influence on the Wave regression tests whatsoever.
Also...
Is a thread safe Wave and Spirit (or Phoenix) that doesn't use Boost Threads available? I.e. are there reentrant versions available?
The Wave code itself is reentrant, but since it's using Spirit V1 underneath, which is not, the overall library isn't reentrant either. Spirit V2 will be thread agnostic, i.e. the user decides and is responsible.
By the way the reason Stefan and I are asking about this is that currently using a static version of Wave doesn't build on some platforms as Boost Threads needs extra user work to build statically.
Ok, understand. Regards Hartmut
Hartmut Kaiser wrote:
Stefan,
I'm not sure where the -lpthread needs to be added (I added it manually to the link command and it succeeded), or in fact, why wave links to boost_thread at all. It doesn't use threads underneath, or does it ? It turns out the dependency on boost_thread is dragged in by boost.spirit. (I modified the subject line to reflect this.)
I'm not sure in what way boost_thread is used there, but I would hope that the decision to use threads (and boost_thread) could be left to the library's user. Only pay for what you really use, or so the saying goes...
Is it possible to modify the config logic to have some users only use the subset of boost.spirit that doesn't require boost_thread ?
(I'm writing a preprocessor and I do not want to use threads, so why would I have to link with boost_thread and pthread ?)
Wave drags in threads only if it gets compiled in an environment requiring threads (BOOST_HAS_THREADS is defined). If you build Wave such that BOOST_HAS_THREADS is not defined, it won't depend on threads.
But having threads and using threads are not the same thing ! Also, I find this configuration-based approach a little too coarse-grained. Ideally the question of whether or not to use threads (or whatever it is boost.spirit uses that requires thread support) would be configured using a template parameter (policy / traits), so the same library could be used with and without threads without requiring a separate build. Of course, this is all wishfull thinking only, I don't know boost.spirit and thus have no idea why you chose to design it the way you did. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan,
Wave drags in threads only if it gets compiled in an environment requiring threads (BOOST_HAS_THREADS is defined). If you build Wave such that BOOST_HAS_THREADS is not defined, it won't depend on threads.
But having threads and using threads are not the same thing ! Also, I find this configuration-based approach a little too coarse-grained. Ideally the question of whether or not to use threads (or whatever it is boost.spirit uses that requires thread support) would be configured using a template parameter (policy / traits), so the same library could be used with and without threads without requiring a separate build.
Agreed. But this isn't possible using the existing libraries. As I said, threading support is needed for Spirit and Pool, both of which need to be configured by pp constants at compile time. Regards Hartmut
participants (3)
-
Hartmut Kaiser -
Rene Rivera -
Stefan Seefeld