Hi Bruno, > The dependencies to these modules (unistr/u32-strlen and unistr/u32-pcpy) are > declared in modules/fnmatch, as well as the link requirements > Could it be that
> This workaround of yours disables the support of Unicode characters outside > the BMP (used by Chinese, Emoji, and many other scripts) in fnmatch. > That support is only present through char32_t. That's actually the point of > using char32_t. [1] > [1] https://www.gnu.org/software/gnulib/manual/html_node/Characters.html Thank you for sharing how the components cooporate! It help a lot to understand gnulib. It seems Windows just use `wchar_t` for Unicode: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/strlen-wcslen-mbslen-mbslen-l-mbstrlen-mbstrlen-l https://learn.microsoft.com/en-us/windows/win32/Intl/unicode-and-character-set-functions I thought gnulib follows Windows behavior on Windows. In fact, in `fnmatch`, you convert characters to UTF32. Thus using `char32_t`. ```c #include <stdio.h> #include <stdlib.h> #include <wchar.h> void main(void){ wchar_t *u16le = L"\uD83D\uDE00"; // 😀 printf("%d\n", wcslen(u16le)); } ``` and ```js console.log('😀'==='\uD83D\uDE00'); console.log('😀'.length); ``` yield 2. It is a bit weird. For the linking errors: Only the `fuzz` linking fails, but `build` and `tests` succeed, when shared building but not static. 4 months ago and 2 days ago. Today, when I try to download the `.a` files and `Makefile` to do more research, all succeeded, without hacking, the same gcc version. This is really weird! Let it be, until it's reproduced. Thank you very much! Best Regards, YX Hao
