Boost.Locale on Windows not building with runtime-link=static
Hello there, once every year or so I have to rebuilt boost for the current compiler/settings combination I work with. This time it's the following: Visual Studio 2015 32 and 64bit static linking statically linked runtime I built boost from within the VS2015 developer console using this command line: c:\projects\boost_1_59_0>.\b2 variant=debug,release link=static runtime-link=static address-model=32 --stagedir=stage32 -sICU_PATH=C:\projects\icu Works great. Except that Boost.Locale does not respect the "runtime-link=static" and builds for dynamically linked runtime instead. The build log looks like this: ...patience... ...found 19297 targets... ...updating 76 targets... common.mkdir stage32 common.mkdir stage32\lib common.copy stage32\lib\libboost_atomic-vc140-mt-sgd-1_59.lib common.copy stage32\lib\libboost_system-vc140-mt-sgd-1_59.lib common.copy stage32\lib\libboost_chrono-vc140-mt-sgd-1_59.lib common.copy stage32\lib\libboost_container-vc140-mt-sgd-1_59.lib common.copy stage32\lib\libboost_thread-vc140-mt-sgd-1_59.lib common.copy stage32\lib\libboost_context-vc140-mt-sgd-1_59.lib common.copy stage32\lib\libboost_coroutine-vc140-mt-sgd-1_59.lib common.copy stage32\lib\libboost_date_time-vc140-mt-sgd-1_59.lib common.copy stage32\lib\libboost_exception-vc140-mt-sgd-1_59.lib common.copy stage32\lib\libboost_filesystem-vc140-mt-sgd-1_59.lib common.copy stage32\lib\libboost_regex-vc140-mt-sgd-1_59.lib common.copy stage32\lib\libboost_graph-vc140-mt-sgd-1_59.lib common.copy stage32\lib\libboost_iostreams-vc140-mt-sgd-1_59.lib common.copy stage32\lib\libboost_system-vc140-mt-gd-1_59.lib common.copy stage32\lib\libboost_chrono-vc140-mt-gd-1_59.lib common.copy stage32\lib\libboost_thread-vc140-mt-gd-1_59.lib common.copy stage32\lib\libboost_locale-vc140-mt-gd-1_59.lib common.copy stage32\lib\libboost_log-vc140-mt-sgd-1_59.lib Shortened. Please note the build process working correctly up until iostreams - all libraries have a 's' in the filename, denoting the statically linked runtime. Then comes Boost.Locale. And Boost.Locale does not respect the static runtime linking and instead builds for DLL runtime. The build process therefore builds all dependencies (system, chrono, thread) again with dynamic runtime linking and then builds Boost.Locale. When I'm trying to use this setup in my game, the boost auto-linking mechanism correctly determines that Boost.Locale is required, but requires the static runtime linked version, which obviously doesn't exist. So this is a bug in the build files? Is there a simple quickfix I can apply to my local installation to be able to carry on? Should I open an issue in Trac? Thanks for your time. Bye, Thomas
Hi Thomas, I agree with you. I opened a feature request for Boost.Locale static runtime support on Windows, around 19 months ago: https://svn.boost.org/trac/boost/ticket/9685 I also emailed the list, but there was no follow up: http://lists.boost.org/boost-users/2013/10/80253.php Looking at the history of bugs closed on Trac for Boost.Locale it appears that the last time a bug was closed there is 2 years ago: https://svn.boost.org/trac/boost/query?status=closed&component=locale&col=id&col=summary&col=status&col=owner&col=type&col=milestone&desc=1&order=id Is the library still actively maintained? regards, stathis On 18/09/2015 14:59, Thomas Ziegenhagen wrote:
Hello there,
once every year or so I have to rebuilt boost for the current compiler/settings combination I work with. This time it's the following:
Visual Studio 2015 32 and 64bit static linking statically linked runtime
I built boost from within the VS2015 developer console using this command line:
c:\projects\boost_1_59_0>.\b2 variant=debug,release link=static runtime-link=static address-model=32 --stagedir=stage32 -sICU_PATH=C:\projects\icu
Works great. Except that Boost.Locale does not respect the "runtime-link=static" and builds for dynamically linked runtime instead. The build log looks like this:
...patience... ...found 19297 targets... ...updating 76 targets... common.mkdir stage32 common.mkdir stage32\lib common.copy stage32\lib\libboost_atomic-vc140-mt-sgd-1_59.lib common.copy stage32\lib\libboost_system-vc140-mt-sgd-1_59.lib common.copy stage32\lib\libboost_chrono-vc140-mt-sgd-1_59.lib common.copy stage32\lib\libboost_container-vc140-mt-sgd-1_59.lib common.copy stage32\lib\libboost_thread-vc140-mt-sgd-1_59.lib common.copy stage32\lib\libboost_context-vc140-mt-sgd-1_59.lib common.copy stage32\lib\libboost_coroutine-vc140-mt-sgd-1_59.lib common.copy stage32\lib\libboost_date_time-vc140-mt-sgd-1_59.lib common.copy stage32\lib\libboost_exception-vc140-mt-sgd-1_59.lib common.copy stage32\lib\libboost_filesystem-vc140-mt-sgd-1_59.lib common.copy stage32\lib\libboost_regex-vc140-mt-sgd-1_59.lib common.copy stage32\lib\libboost_graph-vc140-mt-sgd-1_59.lib common.copy stage32\lib\libboost_iostreams-vc140-mt-sgd-1_59.lib common.copy stage32\lib\libboost_system-vc140-mt-gd-1_59.lib common.copy stage32\lib\libboost_chrono-vc140-mt-gd-1_59.lib common.copy stage32\lib\libboost_thread-vc140-mt-gd-1_59.lib common.copy stage32\lib\libboost_locale-vc140-mt-gd-1_59.lib common.copy stage32\lib\libboost_log-vc140-mt-sgd-1_59.lib
Shortened. Please note the build process working correctly up until iostreams - all libraries have a 's' in the filename, denoting the statically linked runtime. Then comes Boost.Locale. And Boost.Locale does not respect the static runtime linking and instead builds for DLL runtime. The build process therefore builds all dependencies (system, chrono, thread) again with dynamic runtime linking and then builds Boost.Locale.
When I'm trying to use this setup in my game, the boost auto-linking mechanism correctly determines that Boost.Locale is required, but requires the static runtime linked version, which obviously doesn't exist.
So this is a bug in the build files? Is there a simple quickfix I can apply to my local installation to be able to carry on? Should I open an issue in Trac?
Thanks for your time.
Bye, Thomas _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
So this is a bug in the build files? Is there a simple quickfix I can apply to my local installation to be able to carry on? Should I open an issue in Trac?
I had a quick look, and both regex and locale have this issue - and it's the same one - once you tell them to use ICU, they insist on runtime-link=dynamic. That's because last time I checked, that's the only build configuration ICU supports by default. Plus it's actually bloody hard to correctly configure ICU usage (not helped by ICU continually changing their library names!). So.... by all means open a Trac issue, but don't hold your breath (at least as far as regex is concerned). I think the quickest and easiest way around this is to treat those two libraries as just a bunch of source files, and build them directly from your IDE - this presupposes that you have an ICU build that also uses the static runtime. HTH, John.
Thank you both, stathis and John John Maddock.
I did not open a new ticket. I instead realized that the only thing from
locale I'm actively using is the gettext, so I simply isolated and
shortened the code to my needs. Gets rid of ~30MB of dependencies, avoids
the hilariously complex process of building boost.locale with ICU support,
AND finally allows me to link the runtime statically. It also avoids the
laughable /dir/to/the.moon/LC_MESSAGE/file.mo directory structure, and
last but not least it removes all the locale stuff creeping into global
state and suddenly reformatting numbers in an XML file, for example. What
a mess.
Thanks again. Issue solved.
Bye, Thomas
Am 18.09.2015, 19:19 Uhr, schrieb John Maddock
So this is a bug in the build files? Is there a simple quickfix I can apply to my local installation to be able to carry on? Should I open an issue in Trac?
I had a quick look, and both regex and locale have this issue - and it's the same one - once you tell them to use ICU, they insist on runtime-link=dynamic. That's because last time I checked, that's the only build configuration ICU supports by default. Plus it's actually bloody hard to correctly configure ICU usage (not helped by ICU continually changing their library names!).
So.... by all means open a Trac issue, but don't hold your breath (at least as far as regex is concerned).
I think the quickest and easiest way around this is to treat those two libraries as just a bunch of source files, and build them directly from your IDE - this presupposes that you have an ICU build that also uses the static runtime.
HTH, John. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (3)
-
John Maddock -
stathis -
Thomas Ziegenhagen