Portability of boost libs for "universal linux binary?"
Details: I work on a project where one of the eventual goals is to have one binary for a given architecture that runs on multiple Linux distributions. This goal is currently accomplished by both Sun's Java VM as well as the cmake project ( http://www.cmake.org/HTML/Index.html ). We are in the process of evaluating how this goal is impacted by third party dependencies. We currently use the following boost libs: thread, program_options, regex, date_time, and filesystem. I strongly suspect that the thread lib is going to be the biggest cause of grief towards accomplishing this goal (mostly due to the inability to static link it). Are the other (non thread) boost libs statically linkable? Thanks in advance. -- Zach
On 8/7/06, Zachary Mark
I strongly suspect that the thread lib is going to be the biggest cause of grief towards accomplishing this goal (mostly due to the inability to static link it). Are the other (non thread) boost libs statically linkable?
After building boost 1.33.1 in Gentoo with the static USE flag on, I get a /usr/lib/libboost_thread-mt-s.a I don't see anything (not header-only) in boost that doesn't have a static lib: /usr/lib/libboost_date_time-mt-s.a /usr/lib/libboost_date_time-mt-sd.a /usr/lib/libboost_date_time-s.a /usr/lib/libboost_date_time-sd.a /usr/lib/libboost_filesystem-mt-s.a /usr/lib/libboost_filesystem-mt-sd.a /usr/lib/libboost_filesystem-s.a /usr/lib/libboost_filesystem-sd.a /usr/lib/libboost_iostreams-mt-s.a /usr/lib/libboost_iostreams-mt-sd.a /usr/lib/libboost_iostreams-s.a /usr/lib/libboost_iostreams-sd.a /usr/lib/libboost_prg_exec_monitor-mt-s.a /usr/lib/libboost_prg_exec_monitor-mt-sd.a /usr/lib/libboost_prg_exec_monitor-s.a /usr/lib/libboost_prg_exec_monitor-sd.a /usr/lib/libboost_program_options-mt-s.a /usr/lib/libboost_program_options-mt-sd.a /usr/lib/libboost_program_options-s.a /usr/lib/libboost_program_options-sd.a /usr/lib/libboost_python-mt-s.a /usr/lib/libboost_python-mt-sd.a /usr/lib/libboost_python-s.a /usr/lib/libboost_python-sd.a /usr/lib/libboost_regex-mt-s.a /usr/lib/libboost_regex-mt-sd.a /usr/lib/libboost_regex-s.a /usr/lib/libboost_regex-sd.a /usr/lib/libboost_serialization-mt-s.a /usr/lib/libboost_serialization-mt-sd.a /usr/lib/libboost_serialization-s.a /usr/lib/libboost_serialization-sd.a /usr/lib/libboost_signals-mt-s.a /usr/lib/libboost_signals-mt-sd.a /usr/lib/libboost_signals-s.a /usr/lib/libboost_signals-sd.a /usr/lib/libboost_test_exec_monitor-mt-s.a /usr/lib/libboost_test_exec_monitor-mt-sd.a /usr/lib/libboost_test_exec_monitor-s.a /usr/lib/libboost_test_exec_monitor-sd.a /usr/lib/libboost_thread-mt-s.a /usr/lib/libboost_thread-mt-sd.a /usr/lib/libboost_unit_test_framework-mt-s.a /usr/lib/libboost_unit_test_framework-mt-sd.a /usr/lib/libboost_unit_test_framework-s.a /usr/lib/libboost_unit_test_framework-sd.a /usr/lib/libboost_wave-mt-s.a /usr/lib/libboost_wave-mt-sd.a /usr/lib/libboost_wave-s.a /usr/lib/libboost_wave-sd.a /usr/lib/libboost_wserialization-mt-s.a /usr/lib/libboost_wserialization-mt-sd.a /usr/lib/libboost_wserialization-s.a /usr/lib/libboost_wserialization-sd.a ~ SWMc
I've seen static libs generated for boost-thread, but I've had bad luck trying to get a statically linked thread lib to work (though my issues may be caused by something that is not boost::thread related) . I'll give it another go and see what we can come up with. -- Zach me22 wrote:
On 8/7/06, Zachary Mark
wrote: I strongly suspect that the thread lib is going to be the biggest cause of grief towards accomplishing this goal (mostly due to the inability to static link it). Are the other (non thread) boost libs statically linkable?
After building boost 1.33.1 in Gentoo with the static USE flag on, I get a /usr/lib/libboost_thread-mt-s.a
I don't see anything (not header-only) in boost that doesn't have a static lib: /usr/lib/libboost_date_time-mt-s.a /usr/lib/libboost_date_time-mt-sd.a /usr/lib/libboost_date_time-s.a /usr/lib/libboost_date_time-sd.a /usr/lib/libboost_filesystem-mt-s.a /usr/lib/libboost_filesystem-mt-sd.a /usr/lib/libboost_filesystem-s.a /usr/lib/libboost_filesystem-sd.a /usr/lib/libboost_iostreams-mt-s.a /usr/lib/libboost_iostreams-mt-sd.a /usr/lib/libboost_iostreams-s.a /usr/lib/libboost_iostreams-sd.a /usr/lib/libboost_prg_exec_monitor-mt-s.a /usr/lib/libboost_prg_exec_monitor-mt-sd.a /usr/lib/libboost_prg_exec_monitor-s.a /usr/lib/libboost_prg_exec_monitor-sd.a /usr/lib/libboost_program_options-mt-s.a /usr/lib/libboost_program_options-mt-sd.a /usr/lib/libboost_program_options-s.a /usr/lib/libboost_program_options-sd.a /usr/lib/libboost_python-mt-s.a /usr/lib/libboost_python-mt-sd.a /usr/lib/libboost_python-s.a /usr/lib/libboost_python-sd.a /usr/lib/libboost_regex-mt-s.a /usr/lib/libboost_regex-mt-sd.a /usr/lib/libboost_regex-s.a /usr/lib/libboost_regex-sd.a /usr/lib/libboost_serialization-mt-s.a /usr/lib/libboost_serialization-mt-sd.a /usr/lib/libboost_serialization-s.a /usr/lib/libboost_serialization-sd.a /usr/lib/libboost_signals-mt-s.a /usr/lib/libboost_signals-mt-sd.a /usr/lib/libboost_signals-s.a /usr/lib/libboost_signals-sd.a /usr/lib/libboost_test_exec_monitor-mt-s.a /usr/lib/libboost_test_exec_monitor-mt-sd.a /usr/lib/libboost_test_exec_monitor-s.a /usr/lib/libboost_test_exec_monitor-sd.a /usr/lib/libboost_thread-mt-s.a /usr/lib/libboost_thread-mt-sd.a /usr/lib/libboost_unit_test_framework-mt-s.a /usr/lib/libboost_unit_test_framework-mt-sd.a /usr/lib/libboost_unit_test_framework-s.a /usr/lib/libboost_unit_test_framework-sd.a /usr/lib/libboost_wave-mt-s.a /usr/lib/libboost_wave-mt-sd.a /usr/lib/libboost_wave-s.a /usr/lib/libboost_wave-sd.a /usr/lib/libboost_wserialization-mt-s.a /usr/lib/libboost_wserialization-mt-sd.a /usr/lib/libboost_wserialization-s.a /usr/lib/libboost_wserialization-sd.a
~ SWMc _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (2)
-
me22
-
Zachary Mark