Some library dependency and auto liker issues
Hi, there is an issue https://svn.boost.org/trac/boost/ticket/7045 that I don't know how to fix. The problem is related to library dependencies and auto-linker. * 1st issue: Boost.Threads depends on Boost.DateTime but only for the header only part. Anyway, it includes a DateTime file that includes the boost/config/auto_link.hpp, and this makes the tools using the auto linker to create a dependency on Boost.DateTime. As the Boost.Threads build Jamfile doesn't link with Boost.DateTime, the command bjam toolset=msvc-11.0 --build-type=complete --with-thread doesn't build the library Boost.DateTime and so when a tool such as Visual studio uses the auto linker information, it tries to link with Boost.DateTime and not finds it, as not build (even if it is not needed). What is the best way to fix this? Should Boost.Thread link with Boost.DateTime, even if it don't needs it? Or just document that the user relaying on auto-linker needs to build explicitly the boost_date_time library with the command: bjam toolset=msvc-11.0 --build-type=complete --with-thread --with-date_time * 2nd issue: Boost.Threads depends on Boost.Chrono and the library is linked with boost_chrono. When a user includes for example <boost/thread/tss.hpp> the autolinker doesn't detects the chrono dependency as this file don't depends on any file in boost/chrono. But as boost_thread depends on boost_chrono, the linker find some unresolved symbols. What is the best way to fix this? Should Boost.Thread include boost/chrono.hpp in all their public files even if not needed other than by auto linker tools? Or just document that the user relaying on auto-linker needs to include only the top level file <boost/thread.hpp> so that all the dependencies are covered? Any suggestions are welcome, Vicente
On Monday 20 August 2012 18:20:50 Vicente J. Botet Escriba wrote:
Hi,
there is an issue https://svn.boost.org/trac/boost/ticket/7045 that I don't know how to fix.
The problem is related to library dependencies and auto-linker.
* 1st issue: Boost.Threads depends on Boost.DateTime but only for the header only part. Anyway, it includes a DateTime file that includes the boost/config/auto_link.hpp, and this makes the tools using the auto linker to create a dependency on Boost.DateTime. As the Boost.Threads build Jamfile doesn't link with Boost.DateTime, the command
bjam toolset=msvc-11.0 --build-type=complete --with-thread
doesn't build the library Boost.DateTime and so when a tool such as Visual studio uses the auto linker information, it tries to link with Boost.DateTime and not finds it, as not build (even if it is not needed).
What is the best way to fix this? Should Boost.Thread link with Boost.DateTime, even if it don't needs it? Or just document that the user relaying on auto-linker needs to build explicitly the boost_date_time library with the command:
bjam toolset=msvc-11.0 --build-type=complete --with-thread --with-date_time
I think Boost.Thread always depends on Boost.DateTime, at least on Windows. I see it includes Boost.DateTime in src/win32/thread.cpp. I think, the dependency on Boost.DateTime should be in the Jamfile of Boost.Thread. This way the build system will know that Boost.DateTime should also be compiled when Boost.Thread builds.
* 2nd issue: Boost.Threads depends on Boost.Chrono and the library is linked with boost_chrono. When a user includes for example <boost/thread/tss.hpp> the autolinker doesn't detects the chrono dependency as this file don't depends on any file in boost/chrono. But as boost_thread depends on boost_chrono, the linker find some unresolved symbols.
Does it? I thought Boost.Chrono-related code in Boost.Thread was header-only. If so, the chrono-related part should probably be disabled by defining BOOST_THREAD_DONT_USE_CHRONO when Boost.Thread builds.
What is the best way to fix this? Should Boost.Thread include boost/chrono.hpp in all their public files even if not needed other than by auto linker tools? Or just document that the user relaying on auto-linker needs to include only the top level file <boost/thread.hpp> so that all the dependencies are covered?
Please don't do this. I had this problem with Boost.Log, which uses Boost.Thread but doesn't use Boost.Chrono. I don't want to introduce dependency on Boost.Chrono, so I explicitly disabled it when Boost.Log compiles. I would like to keep this dependency optional, if possible.
Le 20/08/12 18:44, Andrey Semashev a écrit :
On Monday 20 August 2012 18:20:50 Vicente J. Botet Escriba wrote:
Hi,
there is an issue https://svn.boost.org/trac/boost/ticket/7045 that I don't know how to fix.
The problem is related to library dependencies and auto-linker.
* 1st issue: Boost.Threads depends on Boost.DateTime but only for the header only part. Anyway, it includes a DateTime file that includes the boost/config/auto_link.hpp, and this makes the tools using the auto linker to create a dependency on Boost.DateTime. As the Boost.Threads build Jamfile doesn't link with Boost.DateTime, the command
bjam toolset=msvc-11.0 --build-type=complete --with-thread
doesn't build the library Boost.DateTime and so when a tool such as Visual studio uses the auto linker information, it tries to link with Boost.DateTime and not finds it, as not build (even if it is not needed).
What is the best way to fix this? Should Boost.Thread link with Boost.DateTime, even if it don't needs it? Or just document that the user relaying on auto-linker needs to build explicitly the boost_date_time library with the command:
bjam toolset=msvc-11.0 --build-type=complete --with-thread --with-date_time I think Boost.Thread always depends on Boost.DateTime, at least on Windows. I see it includes Boost.DateTime in src/win32/thread.cpp. Yes, but it uses only inline functions.
I think, the dependency on Boost.DateTime should be in the Jamfile of Boost.Thread. This way the build system will know that Boost.DateTime should also be compiled when Boost.Thread builds. An the dependency in on inline functions, I suspect that others than you will request that Boost.Thread don't link with Boost.DateTime. Note that currently, everything is OK without linking with.
* 2nd issue: Boost.Threads depends on Boost.Chrono and the library is linked with boost_chrono. When a user includes for example <boost/thread/tss.hpp> the autolinker doesn't detects the chrono dependency as this file don't depends on any file in boost/chrono. But as boost_thread depends on boost_chrono, the linker find some unresolved symbols. Does it? Yes. At least when BOOST_THREAD_DONT_USE_CHRONO is not defined. I thought Boost.Chrono-related code in Boost.Thread was header-only. No the dependent part uses system_clock::now() and steady_clock::now() indirectly.
If so, the chrono-related part should probably be disabled by defining BOOST_THREAD_DONT_USE_CHRONO when Boost.Thread builds. Unfortunately this should be possible only if Boost.Chrono is configured as header only, which is not the default.
What is the best way to fix this? Should Boost.Thread include boost/chrono.hpp in all their public files even if not needed other than by auto linker tools? Or just document that the user relaying on auto-linker needs to include only the top level file <boost/thread.hpp> so that all the dependencies are covered? Please don't do this. I had this problem with Boost.Log, which uses Boost.Thread but doesn't use Boost.Chrono. I don't want to introduce dependency on Boost.Chrono, so I explicitly disabled it when Boost.Log compiles. I would like to keep this dependency optional, if possible.
So you will admit a fix via documentation, isn't it? Best, Vicente
Le Mon Aug 20 21:55:55 2012, Vicente J. Botet Escriba a écrit :
Le 20/08/12 18:44, Andrey Semashev a écrit :
On Monday 20 August 2012 18:20:50 Vicente J. Botet Escriba wrote:
Hi,
there is an issue https://svn.boost.org/trac/boost/ticket/7045 that I don't know how to fix.
The problem is related to library dependencies and auto-linker.
* 2nd issue: Boost.Threads depends on Boost.Chrono and the library is linked with boost_chrono. When a user includes for example <boost/thread/tss.hpp> the autolinker doesn't detects the chrono dependency as this file don't depends on any file in boost/chrono. But as boost_thread depends on boost_chrono, the linker find some unresolved symbols. Does it? Yes. At least when BOOST_THREAD_DONT_USE_CHRONO is not defined. I thought Boost.Chrono-related code in Boost.Thread was header-only. No the dependent part uses system_clock::now() and steady_clock::now() indirectly.
Of course, I could move the function using now() to a header as an inline function, which will solve this issue. What do you think? Vicente
On Monday 20 August 2012 22:21:58 Vicente J. Botet Escriba wrote:
Le Mon Aug 20 21:55:55 2012, Vicente J. Botet Escriba a écrit :
Le 20/08/12 18:44, Andrey Semashev a écrit :
On Monday 20 August 2012 18:20:50 Vicente J. Botet Escriba wrote:
Hi,
there is an issue https://svn.boost.org/trac/boost/ticket/7045 that I don't know how to fix.
The problem is related to library dependencies and auto-linker.
* 2nd issue: Boost.Threads depends on Boost.Chrono and the library is linked with boost_chrono. When a user includes for example <boost/thread/tss.hpp> the autolinker doesn't detects the chrono dependency as this file don't depends on any file in boost/chrono. But as boost_thread depends on boost_chrono, the linker find some unresolved symbols.
Does it?
Yes. At least when BOOST_THREAD_DONT_USE_CHRONO is not defined.
I thought Boost.Chrono-related code in Boost.Thread was header-only.
No the dependent part uses system_clock::now() and steady_clock::now() indirectly.
Of course, I could move the function using now() to a header as an inline function, which will solve this issue.
What do you think?
That would be great, thanks!
On Monday 20 August 2012 21:55:55 Vicente J. Botet Escriba wrote:
Le 20/08/12 18:44, Andrey Semashev a écrit :
I think Boost.Thread always depends on Boost.DateTime, at least on Windows. I see it includes Boost.DateTime in src/win32/thread.cpp.
Yes, but it uses only inline functions.
I think, the dependency on Boost.DateTime should be in the Jamfile of Boost.Thread. This way the build system will know that Boost.DateTime should also be compiled when Boost.Thread builds.
An the dependency in on inline functions, I suspect that others than you will request that Boost.Thread don't link with Boost.DateTime. Note that currently, everything is OK without linking with.
Well, I would add the dependency anyway. I didn't verify but doesn't MSVC auto-link Boost.DateTime to Boost.Thread just because of the header include? Anyway, if you're certain you want to avoid the dependency then there are two solutions. The simplest one, as you suggested, is to add a note to the docs. Another solution is to make Boost.DateTime inclusion optional, much like it is with Boost.Chrono now. I'm personally fine with either one.
participants (2)
-
Andrey Semashev -
Vicente J. Botet Escriba