Created attachment 169696 [details] Output of running "LANG=C craft -v kopeninghours" SUMMARY Building this library on macOS using Craft fails. The failure occurs with Craft's flex, which seemingly fails to handle some unicode character(s). Manually running Craft's flex with additional arguments "-8 --debug --trace --hex" shows it fails at line 159, with the russian name for February (Февраль) Running the same command with Apple's flex (flex 2.6.4 Apple(flex-34)) works fine, interestingly. I have not bothered comparing their sources with Craft's flex yet. STEPS TO REPRODUCE 1. Set up Craft on macOS according to https://community.kde.org/Get_Involved/development/Mac 2. Try to build KOpeningHours or anything depending on it (in my case, I was trying to build Itinerary) OBSERVED RESULT Build failure EXPECTED RESULT Build success SOFTWARE/OS VERSIONS macOS: 14.4.1 ADDITIONAL INFORMATION
Huh. I just wanted to add Craft-flex's debug output as another attachment. To keep it english, I set LANG=C (instead of LANG=de_DE.UTF-8 which is the default on my machine) and... it worked! So what's weird is that Craft seems to pass along LANG=C to flex in *some* way, or else its error message wouldn't be in english. If I just run `craft -v kopeninghours`, the error message is german instead. But setting LANG=C when running flex directly definitely runs without issues. Strange...
Aha. I dumped all env vars with printenv(1) using a small shell wrapper. Craft (or something along the way) additionally sets LC_CTYPE=UTF-8, which is normally unset!
(In reply to Fridtjof from comment #2) > Craft (or something along the way) additionally sets LC_CTYPE=UTF-8, which > is normally unset! I don't have access to macOS, so there are limits to what I can do here unfortunately. Is LC_CTYPE=UTF-8 even valid on macOS? On Linux that needs to be a full locale, not just a text codec. Trying that nevertheless gives me plenty of warnings but still a working build.
No idea. If I don't specify LANG=C, LC_CTYPE stays empty/unset. Flex fails with anything but LANG=C, though - so LANG=de_DE.UTF-8 for example breaks, as does LANG=en_US.UTF-8. In those cases, LC_CTYPE stays untouched as well. Interestingly, LANG=de_DE.ISO8859-1 works fine! (So it's probably the UTF-8 charmap handling in general that's the problem) By now, this feels more like a vanilla flex on macOS bug? It's unfortunately incredibly annoying to compare Apple's downstream source code to upstream flex because they completely throw out any git history with their releases.
(In reply to Fridtjof from comment #4) > By now, this feels more like a vanilla flex on macOS bug? It's unfortunately > incredibly annoying to compare Apple's downstream source code to upstream > flex because they completely throw out any git history with their releases. Quite possible, I'm still unable to reproduce this on Linux independent of which of those locales I try. I also double-checked the source file, that is correctly encoded in UTF-8 it seems.
I just tried this with a build of latest flex off git (https://github.com/westes/flex/tree/05909f20c58fbce8859e711b697ca996fccf0711) and that also works regardless of LANG and LC_CTYPE (tested with LANG=, LANG=de_DE.UTF-8 and LANG=de_DE.UTF-8;LC_CTYPE=UTF-8 for good measure). What version/commit do you have on your system? The last release, 2.6.4, is from 2017 and I figure that some distros might have started packaging later revisions without a formal release. Of course, this might still be a macOS specific problem, but asking just in case.
flex says it's version 2.6.4 here, no idea whether it contains additional changes on top though (this is openSUSE Tumbleweed, same as the KDE CI is using for Linux).