After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 795338 - Glib::ustring unicode handling in to_string(), operator>>(std::wistream&, ustring&), operator<<(std::wostream&, const ustring&) always fails on macOS when built against libc++
Glib::ustring unicode handling in to_string(), operator>>(std::wistream&, ust...
Status: RESOLVED FIXED
Product: glibmm
Classification: Bindings
Component: strings
2.56.x
Other Mac OS
: Normal major
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2018-04-17 19:09 UTC by Clemens Lang
Modified: 2018-10-17 15:27 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
ustring: Fix wchar conversion on macOS with libc++ (2.19 KB, patch)
2018-04-17 19:09 UTC, Clemens Lang 		committed Details | Review

Description Clemens Lang 2018-04-17 19:09:52 UTC 
Created attachment 371067 [details] [review]
ustring: Fix wchar conversion on macOS with libc++

When glibmm is compiled with clang++ against libc++ (as is the default on macOS), the methods that attempt conversion between std::wstring and Glib::ustring fall back to g_convert() from WCHAR_T to UTF-8, which in turn calls iconv with these parameters.

libiconv built on macOS, however, does not correctly convert these values. I do not know whether this is due to WCHAR_T having an unexpected meaning on macOS, or the value not being supported at all. Comments in the libiconv source code suggest this was implemented for glibc, which is not used on macOS. iconv --list does not list WCHAR_T as a valid encoding on macOS either.

This causes any conversion from a std::wstring to a Glib::ustring to fail with a Glib::ConvertError on macOS. This does, for example, affect inkscape 0.92.2, which no longer starts on macOS due to this issue.

See https://trac.macports.org/ticket/56214, https://github.com/caskformula/homebrew-caskformula/issues/41, https://github.com/caskformula/homebrew-caskformula/issues/42, https://github.com/caskformula/homebrew-caskformula/issues/43 which describe this issue. This is a problem on at least macOS 10.12 and 10.13, but likely also all other versions of macOS that use libc++.

Fortunately it seems the code that was implemented for libstdc++ within the #if defined(__STDC_ISO_10646__) && SIZEOF_WCHAR_T == 4 guards does work fine for libc++, but libc++ does not define the symbol. I'm attaching a patch to alternatively accept defined(_LIBCPP_VERSION) instead of defined(__STDC_ISO_10646__), which will be true when compiling against libc++. This patch allows inkscape to start.
Comment 1 Weikeng Chen 2018-04-22 04:44:07 UTC 
Following Clemens's patch, I created the following brew formula, as some users are using Inkscape from the brew, and very hard to escape the current difficulty.

See https://github.com/caskformula/homebrew-caskformula/issues/51
This is a temporary solution.

Thanks Clemens.

=======

Will wait for the official update of `glibmm`.
Comment 2 Kjell Ahlstedt 2018-04-26 13:29:41 UTC 
I've pushed the patch to the master branch and the glibmm-2-56 branch.

From https://trac.macports.org/ticket/56214:
  An upstream issue probably gets fixed more quickly with a working patch
  attached.

True in general, and certainly true in this case, where the bug shows up only on
MacOS, and probably not even on all versions of MacOS.
Comment 3 Marcin Cieślak 2018-10-15 10:40:25 UTC 
This problem has also been reported on FreeBSD, which also uses clang and its libc++:

https://lists.freebsd.org/pipermail/freebsd-ports/2018-October/114445.html

the patch attached to this bug report also fixes the problem there.