> Indeed, doing collation properly (i.e. with Unicode, not just 8 bit > characters like FreeBSD does) really is a non-trivial effort. > > It requires some expertise in linguistics and a solid understanding > of the unicode standard. You'd need to make use of something like ICU > (icu-project.org) to keep your sanity, or implement a whole lot of > that code base yourself...
Unfortunately, that requires support in the 3rd party software itself. > Applications don't care where a symbol comes from. > Build scripts and Makefiles might expect them to be in libc and > would need to link an additional library, but that's trivial to do. For all such ports? Ok then :-) > I think you should tackle your goals (C++11, collation) in isolation. > They aren't coupled, really. Yes, but xlocale seemed like a thing they have in common. > If we bother with collation I think we should try to do better. Yes, but that I think is only applying a correct library. As you've said earlier, getting this right is really hard. > I would suggest to implement a small and non-OS-specific stub for > libcxx that they can use on any OS lacking xlocale support. > Replace/enhance the existing shim for Solaris as part of this effort. > Work with the libcxx team to integrate your changes there. > > If they tell you that they won't run on a non-xlocale OS that isn't > Solaris, implement the shim anyway and add it to our ports tree. > > The shim is going to be a lot less work, and doesn't preclude an > implentation inside libc at a later stage. Thanks for showing the right direction. I'll look into it as soon as I have more time; at least I know what is needed and how big is it. -- Martin Pelikan
