vcpkg + Boost + ICU + Windows 10
Anyone familiar with vcpkg on Windows?
I just installed it and then ran the
vcpkg install boost-locale[icu] boost-regex[icu] boost --triplet x64-windows --recurse
which informed me it completed successfully. Yet when I try to compile a.cpp using Boost Locale I get:
FWIW, I’m using MSVC 2022 (19.34.31937 for x64).
The whole point is to link to the OS’s icu.dll.
I just installed it and then ran the
vcpkg install boost-locale[icu] boost-regex[icu] boost --triplet x64-windows --recurse
which informed me it completed successfully. Yet when I try to compile a.cpp using Boost Locale I get:
LINK : fatal error LNK1104: cannot open file 'libboost_locale-vc141-mt-s-x64-1_70.lib' |
FWIW, I’m using MSVC 2022 (19.34.31937 for x64).
The whole point is to link to the OS’s icu.dll.
Yes, I am familiar with vcpkg used with VS 2022. JLBorges gave you the proper nudge to get it to work.
The "getting started" web page mentions integrating vcpkg with VS:
https://vcpkg.io/en/getting-started.html
The "getting started" web page mentions integrating vcpkg with VS:
https://vcpkg.io/en/getting-started.html
My "vcpkg and why I like it" thread:
https://cplusplus.com/forum/lounge/284973/
I use a slightly different command to install a library, so I get x64, x64-static and x86 libs (if any) created.
It works well for me. YMMV.
https://cplusplus.com/forum/lounge/284973/
I use a slightly different command to install a library, so I get x64, x64-static and x86 libs (if any) created.
It works well for me. YMMV.
If'n I read this (https://www.boost.org/doc/libs/1_48_0/libs/locale/doc/html/using_localization_backends.html) correctly Boost-locale is built using icu by default.
The Boost install in my vcpkg setup has [core] instead of [icu], that should have been built against icu.
My Boost install command was:
I wanted to make sure I got the Windows triplet installed correctly, I'm a "it works this way though probably not the best or easiest method" kinda guy, and it installed a butt-load of Boost libraries. As it should have.
Installing the upper level Boost did the --recurse option as part of the install process for all the libraries.
A while back I added a special system-wide environment variable so vcpkg didn't retain the binary caches since I am a lone self-taught hobbyist developer. It is enabled by default.
https://devblogs.microsoft.com/cppblog/vcpkg-accelerate-your-team-development-environment-with-binary-caching-and-manifests/
vcpkg is updated periodically, running an outdated version can cause problems with keeping the installed libraries up to date. There is a special bat file for updating the local versions of the app. bootstrao-vcpkg.bat. I run the bat file after I do a git pull and then run the batch with the -disableMetrics options.
The Boost install in my vcpkg setup has [core] instead of [icu], that should have been built against icu.
My Boost install command was:
vcpkg install boost:x64-windows boost:x64-windows-static boost:x86-windowsI wanted to make sure I got the Windows triplet installed correctly, I'm a "it works this way though probably not the best or easiest method" kinda guy, and it installed a butt-load of Boost libraries. As it should have.
Installing the upper level Boost did the --recurse option as part of the install process for all the libraries.
A while back I added a special system-wide environment variable so vcpkg didn't retain the binary caches since I am a lone self-taught hobbyist developer. It is enabled by default.
https://devblogs.microsoft.com/cppblog/vcpkg-accelerate-your-team-development-environment-with-binary-caching-and-manifests/
| If you don’t want to use binary caching, you can turn it off by setting the environment variable VCPKG_FEATURE_FLAGS to -binarycaching (including the minus). You can alternatively pass the --no-binarycaching option on the command line. |
vcpkg is updated periodically, running an outdated version can cause problems with keeping the installed libraries up to date. There is a special bat file for updating the local versions of the app. bootstrao-vcpkg.bat. I run the bat file after I do a git pull and then run the batch with the -disableMetrics options.
Lol, I forgot to integrate install _after_ adding boost.
Gonna add the static option too. I was wondering if I’d want that, and I think I do.
The whole point is I want to use Boost Locale, but I want it to be linked to _Windows’s_ ICU and not something bulky I would need to ship to anyone...
I’ll update y’all on how it turns out.
EDIT: No dice. Linker still can’t find boost locale. (I can see boost_locale-vc143-mt-x64-1_81.dll and .pdb in the packages. I’m still not sure why the linker is trying to use libboost...-vc141...)
Gonna add the static option too. I was wondering if I’d want that, and I think I do.
The whole point is I want to use Boost Locale, but I want it to be linked to _Windows’s_ ICU and not something bulky I would need to ship to anyone...
I’ll update y’all on how it turns out.
EDIT: No dice. Linker still can’t find boost locale. (I can see boost_locale-vc143-mt-x64-1_81.dll and .pdb in the packages. I’m still not sure why the linker is trying to use libboost...-vc141...)
Last edited on
Finally got things to compile from the command line directly:
cl /EHsc /W4 /Ox /std:c++17 /MT collate.cpp /I \vcpkg\installed\x64-windows-static\include libboost_locale-vc143-mt-s-x64-1_81.lib
(I had copied the static boost lib directly to the compile directory.)
The file runs, and does things correctly!
I still can’t quite get CMake to behave here, though.
But while this is fabulous, I cannot verify that the system icu.dll is being used by the Boost Locale library (the one in C:\Windows\System32). It is not directly required by collate.exe’s dependencies, which I figure it ought to be were the static libboost_locale requiring it...
Dependency Walker hangs for me on this program, and dumpbin is just a deep deep rabbit hole of dependency hocky sticks.
(I also tried to look through the non-static boost locale DLL.)
Currently running the Boost Locale example “boundary.cpp” program indicates that the generated locale does not have word-boundary boundary analysis, which it should were it properly linked to ICU!
(The very same program works just fine on WSL.)
Fooey.
cl /EHsc /W4 /Ox /std:c++17 /MT collate.cpp /I \vcpkg\installed\x64-windows-static\include libboost_locale-vc143-mt-s-x64-1_81.lib
(I had copied the static boost lib directly to the compile directory.)
The file runs, and does things correctly!
I still can’t quite get CMake to behave here, though.
But while this is fabulous, I cannot verify that the system icu.dll is being used by the Boost Locale library (the one in C:\Windows\System32). It is not directly required by collate.exe’s dependencies, which I figure it ought to be were the static libboost_locale requiring it...
Dependency Walker hangs for me on this program, and dumpbin is just a deep deep rabbit hole of dependency hocky sticks.
(I also tried to look through the non-static boost locale DLL.)
Currently running the Boost Locale example “boundary.cpp” program indicates that the generated locale does not have word-boundary boundary analysis, which it should were it properly linked to ICU!
(The very same program works just fine on WSL.)
Fooey.
Brilliant!
Thank you so much!
Aaannnd I can confirm that Windows’s icu.dll is not found in the libs installed by the vcpkg manager. Like, wut?
Unless MS’s localization stuff is ultimately linking to it somewhere deep, deep down... but it doesn’t seem to be?
I can do it myself with:
Which works. But then I need to do what Boost.Locale does for me myself. Fooey.
Maybe I’ll play with trying to get bjam to compile Boost.Locale against Windows’s ICU.
idk.
Thank you so much!
Aaannnd I can confirm that Windows’s icu.dll is not found in the libs installed by the vcpkg manager. Like, wut?
Unless MS’s localization stuff is ultimately linking to it somewhere deep, deep down... but it doesn’t seem to be?
I can do it myself with:
|
|
Maybe I’ll play with trying to get bjam to compile Boost.Locale against Windows’s ICU.
idk.
D, you've helped me in the past, so helping you with Dependencies is a more than fair payback. :)
I thought you'd have already known about it, but.... :D
I thought you'd have already known about it, but.... :D
Interesting that a tool created by MS doesn't auto-link with Windows dlls.
I simply use vcpkg to ease the pain (for me) of getting, installing, maintaining and updating 3rd party libraries as needed and wanted.
I'm a just-use-it kinda guy, so the details of the guts of how vcpkg works is neither of much interest beyond a vague intellectual exercise, and knowingly way above my C++ programming paygrade.
I simply use vcpkg to ease the pain (for me) of getting, installing, maintaining and updating 3rd party libraries as needed and wanted.
I'm a just-use-it kinda guy, so the details of the guts of how vcpkg works is neither of much interest beyond a vague intellectual exercise, and knowingly way above my C++ programming paygrade.
Re: Dependencies
Yeah, there’s plenty of awesome software out there that flies past my radar these days. I’m too old to keep up on it all any more.
Re: Auto-link
Vcpkg packages link with plenty of Windows DLLs.
It’s just that its boost-locale[icu] compilation did not link with Windows’s copy of ICU.
The reason it matters is because the ICU data base is massive, and the DLLs aren’t tiny either. But every modern system (Win, Linux, Mac, iOS, Android, etc) all have a bundled copy of ICU available and running on it, to which I figure my software ought to bind instead of just adding bloat.
But playing with Boost configuration scripts is Not What I Want To Do, alas. We’ll see what I wind up doing, I guess. I’ll keep y’all posted.
Yeah, there’s plenty of awesome software out there that flies past my radar these days. I’m too old to keep up on it all any more.
Re: Auto-link
Vcpkg packages link with plenty of Windows DLLs.
It’s just that its boost-locale[icu] compilation did not link with Windows’s copy of ICU.
The reason it matters is because the ICU data base is massive, and the DLLs aren’t tiny either. But every modern system (Win, Linux, Mac, iOS, Android, etc) all have a bundled copy of ICU available and running on it, to which I figure my software ought to bind instead of just adding bloat.
But playing with Boost configuration scripts is Not What I Want To Do, alas. We’ll see what I wind up doing, I guess. I’ll keep y’all posted.
The amusing part of this discussion about vcpkg is I have (for me) a number of 3rd party libraries installed via vcpkg, Boost (all of it) is one of them, but I rarely use any of the libraries I've installed. Only recently did I use SFML very briefly because of a "Learn C++" book I purchased that is all about creating graphical games using the library I was plinking with.
Do I care about how the libraries binaries are built? "Easy for you, difficult for me" might be my response. :) vcpkg works, and works very well, for this self-taught C++ hobbyist.
But yet again, D, you educate me about something I had never thought about. And done it in a manner that didn't talk down or sneeringly insult. Thanks for the easily digestible lecture on ICU. :D
Do I care about how the libraries binaries are built? "Easy for you, difficult for me" might be my response. :) vcpkg works, and works very well, for this self-taught C++ hobbyist.
But yet again, D, you educate me about something I had never thought about. And done it in a manner that didn't talk down or sneeringly insult. Thanks for the easily digestible lecture on ICU. :D
Topic archived. No new replies allowed.