Boost-locale compiled with vcpkg won't pass program linking

[YuHuanTin]

When I try to use boost::locale::conv::from_utf he never works well!

• When I compile code like this with a version of x86-windows boost-locale installed by vcpkg (no icu backend installed) I get this linking problem: unresolved external command

  std::string u8ToGbk(const std::u8string &U8Str) {
      return boost::locale::conv::from_utf(U8Str, "GBK");    
  }

  

  But it links successfully when I use the following code, which seems to solve my problem

  std::string u8ToGbk(const std::string &U8Str) {
      return boost::locale::conv::from_utf(U8Str, "GBK");
  }

  msvc 17.7.0 c++20

• But the situation is even worse when I'm using the version of x86-windows-static installed by vcpkg, and I can barely use the function whether it's using u8 or std::string

  std::string u8ToGbk(const std::string &U8Str) {
    return boost::locale::conv::from_utf(U8Str, "GBK");
  }

  

  msvc 17.7.0 c++20

• Here's my example on compoler explorer (https://godbolt.org/z/M51oMzYec), which seems to be consistent with the problem I'm having

[artyom-beilis]

char8_t or std::u8string aren't supported. Even char16_t and char32_t that exist for much longer are hugely problematic and not supported by most runtimes.

In my personal opinion I'd avoid using char8_t because honestly it is yet another "very-smart" but useless idea by C++ committee

Most compilers incuding MSVC support utf-8 strings in char * and as source encoding. So there is no real need to using of char8_t or u8"stuff"

[YuHuanTin]

char8_t or std::u8string aren't supported. Even char16_t and char32_t that exist for much longer are hugely problematic and not supported by most runtimes.

In my personal opinion I'd avoid using char8_t because honestly it is yet another "very-smart" but useless idea by C++ committee

Most compilers incuding MSVC support utf-8 strings in char * and as source encoding. So there is no real need to using of char8_t or u8"stuff"

Thank you very much for your reply, I now understand that I probably shouldn't have used u8string or char8_t but std::string to store it, but as my screenshot shows, I still can't use the from_utf function even though I put the UTF-8 data in std::string.

And I realized that I misplaced my second image, (fixed), it should be a linking error generated by the following code: (same as shown by Compiler Explorer)

std::string u8ToGbk(const std::string &U8Str) {
    return boost::locale::conv::from_utf(U8Str, "GBK");
}

I'm attaching my cmakelist.txt because I'm not sure if this is the right way to use the boost-locale static library

set(Boost_INCLUDE_DIR ${VCPKG_INSTALLED_DIR}/x86-windows-static/include)
set(Boost_LIBRARY_DIR_DEBUG ${VCPKG_INSTALLED_DIR}/x86-windows-static/debug/lib)
set(Boost_LIBRARY_DIR_RELEASE ${VCPKG_INSTALLED_DIR}/x86-windows-static/lib)

find_package(Boost REQUIRED COMPONENTS locale)

link_libraries(Boost::boost Boost::locale)

[Flamefire]

Although there are issues with char8_t IMO Boost.Locale should support it for such conversion functions, same for the other Unicode char types, see also #79

As for the linker error:

• Compiler explorer does not support non-header-only Boost libs so the error there is expected
• As for the error with the static version: The error mentions a declspec(dllimport) which means that either BOOST_ALL_DYN_LINK or BOOST_LOCALE_DYN_LINK is defined while it should not. So I guess your find_package(Boost REQUIRED COMPONENTS locale) finds the shared library, not the static library

-> Setting Boost_INCLUDE_DIR and the other 2 is surely wrong. This is what find_package should set.

Check how to use vcpkg with CMake and maybe reconfigure from a clean build dir to avoid having cached variables from a previous run interfere.

[YuHuanTin]

• Compiler explorer does not support non-header-only Boost libs so the error there is expected

Thank you, I've since recompiled boost and flushed the cmake cache and it works fine, but I hadn't figured out at the time why it was still an error in Compiler explorer (I thought it was a generalized error), and now everything seems to make sense!