[Bug 282329] Many ports started to fail with: error: implicit instantiation of undefined template 'std::char_traits<unsigned char>'

From: <bugzilla-noreply_at_freebsd.org>
Date: Sat, 26 Oct 2024 11:01:27 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282329

Dimitry Andric <dim@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dim@FreeBSD.org
             Status|New                         |Open

--- Comment #1 from Dimitry Andric <dim@FreeBSD.org> ---
(In reply to Yuri Victorovich from comment #0)

Yes, as noted in quite a few sub-bugs for the llvm-19-update exp-run in
bug 280562, the libc++ 19 release notes [1] mention that
std::char_traits<> is now only provided for char, char8_t, char16_t,
char32_t and wchar_t, and any instantiation for other types will fail.

Originally the plan was to drop that support in libc++ 17, but instead
deprecation warnings were added, and these were in libc++ for two whole
releases. But apparently nobody looks at deprecation warnings. :-)

In any case, during the work for bug 280562, I fixed the following ports
that ran into this issue:

* bug 280563 for devel/binutils
* bug 280564 for graphics/poppler
* bug 280579 for devel/llvm1[1-7]
* bug 280673 for www/node20
* bug 280693 for databases/mysql80-server
* bug 280694 for databases/mysql81-server
* bug 280695 for databases/mysql82-server
* bug 280696 for net/kea
* bug 280791 for textproc/zxing-cpp
* bug 280893 for math/vtk9
* bug 281193 for devel/rapidfuzz-cpp
* bug 281194 for devel/py-rapidfuzz
* bug 281431 for www/qt5-webengine
* bug 281478 for devel/libxsd-frontend
* bug 281485 for www/node18
* bug 281499 for devel/folly
* bug 281516 for graphics/libemf
* bug 281534 for devel/py-Levenshtein
* bug 281540 for devel/sfml
* bug 281553 for devel/poco
* bug 281886 for cad/kicad
* bug 281974 for x11-toolkits/mygui
* bug 281975 for science/dlib-cpp
* bug 282165 for devel/librevisa

In many of these cases, the program abused either uint16_t or uint32_t
to represent UTF-16 or UTF-32 characters, and such cases can easily be
fixed by replacing those with char16_t or char32_t, respectively.

In some other cases, std::basic_string<uint8_t> is used to handle blobs,
and then it is usually best to replace it with std::vector<uint8_t>,
which is better suited to that purpose.

Otherwise, some customized approach will be needed, and this is
different for every port. For example with devel/sfml, the port needed
quite a bit of restructuring, and the port maintainer wanted to discuss
this with upstream first. (Although unfortunately nothing seems to have
come of this, so the port will be broken for now).

[1] https://libcxx.llvm.org/ReleaseNotes/19.html#deprecations-and-removals

-- 
You are receiving this mail because:
You are the assignee for the bug.