A mirror of https://github.com/rmyorston/busybox-w32.git https://git.lua4.win/busybox-w32/atom?h=path_search 2024-04-28T14:48:03+00:00 2024-04-28T14:48:03+00:00 Ron Yorston rmy@pobox.com 2024-04-28T14:48:03+00:00 urn:sha1:e21f531c297d1567720c8b0f1c9bab7daf0cfdad Recent versions of gcc fail to build the binary to test for ncurses because main() is lacking a return type. 2024-03-29T14:26:13+00:00 Avi Halachmi (:avih) avihpit@yahoo.com 2023-07-24T08:01:00+00:00 urn:sha1:c188a345a4d8fe453c4a06796e38d036106fc161 This commit adds a new wcwidth implementation at libbb/wcwidth_alt.c, and uses it instead of the existing implementation when compiling for windows and CONFIG_LAST_SUPPORTED_WCHAR >= 0x30000 - which is the case with the unicode configs/mingw64u_defconfig. The windows-target condition keeps non-windows build unmodified, and the last supported wchar threshold is a semi-hack to allow switching between implementations without adding a new config option (the old code supports codepoints up to 0x2ffff). The new file wcwidth_alt.c was generated by a new scripts/mkwcwidth, which prints a wcwidth implementation using latest unicode data from a local clone of https://github.com/jquast/wcwidth . This repo is the main python wcwidth implementation, and is maintained and up to date. Functional differences from the existing implementation: - Unicode 15.1.0 (latest) with the new version (about 450 ranges of wide and zero-width codepoints), compared to roughly Unicode 5.0 of the existing code (nearly 20 years old spec, about 150 ranges). The new spec includes, among others, various wide icons and emojis, which can now be edited correctly at the shell prompt, have correct alignment in 'ls', etc. - The old implementation returns -1 (non-printable) for surrogates, while the new code returns 1, though this is inconsequential, and POSIX doesn't care. Also libc implementations vary in this regard. Technical differences: - The old version compiles less code/data when the last supported wchar is smaller, while the new version doesn't. This doesn't matter because the new version is enabled only for the full range. - The new version is smaller and relatively straight forward, and fully automated (generated), so updates to newer spec is trivial. The old version mixes data, ad-hoc code (tailored to the data), and preprocessor checks, and is hard to automate updates. The old version has various forms of 32 and 16 bit data ranges, in several arrays, while the new version uses single data array with unified form of 32 bits per range, with two rules: - A data range can't span Unicode planes (enforced, but unlikely required, and if yes, code to split ranges would be simple). - A range can't hold more than 32768 codepoints, so bigger ranges are split automatically (currently there are 2 such ranges). Performance wise, the new version should be faster, even with three times the data ranges. Both versions do effectively at most one binary search in one Unicode plane data, but the new version finds both zero-width and wide-width results in this one search, while the old version only finds zero-width, and to detect wide-width it does an additional linear series of manual range tests, but since most results are width 1, this sequence is performed in most (non-ASCII) calls. In a cursory comparison of the new wcwidth with glibc and musl-libc (both use O(1) lookup tables), with few bodies of text, we're in the same ballpark, with typical speed of 60% or better. Bloat-wise, the new version is about 180 bytes code and 1800 bytes data. If it had similar number of data ranges as the old code (150), the new version would be about 200 bytes smaller, but because the new version has 450 data ranges, it's about 1K bigger. 2024-02-20T13:11:01+00:00 Ron Yorston rmy@pobox.com 2024-02-20T12:53:39+00:00 urn:sha1:17992d06810a9b0c60bab404f720bbd7539bdb93 Commit 992387539 (build system: more clang/llvm tweaks) added a test in scripts/Makefile.build which used the intcmp function. This isn't present in GNU make prior to 4.4. Rewrite the test so it works with older versions of GNU make. 2024-01-21T15:27:38+00:00 Ron Yorston rmy@pobox.com 2024-01-21T15:27:38+00:00 urn:sha1:a3f52971946049c6e74e156faf2e864daa436a06 Commit 992387539 (build system: more clang/llvm tweaks) falsely claimed that the lack of the --warn-common linker option was being detected. It wasn't, but it is now. 2024-01-18T08:01:49+00:00 Ron Yorston rmy@pobox.com 2024-01-18T08:01:49+00:00 urn:sha1:992387539f26de1aeb2cdca62d85fddbde27b798 Linkers associated with clang/llvm may not support the -r option. This is used to create built-in.o object files. It turns out that all such files in busybox-w32 are either empty or only contain one object file. The first case is already supported and the second can be handled by simply copying the object file to built-in.o. The linker is therefore never invoked with the -r option. One adjustment is required: the workaround adopted for GitHub issue #200 linked the dummy C file with the resource object file. This is no longer done so only one object file is used. Since it was the linking that broke the resource file, copying it is an equally effective fix for the issue. Some old linkers don't support the --warn-common option. The lack of this option was being detected but it was still sometimes used. 2024-01-06T12:44:21+00:00 Ron Yorston rmy@pobox.com 2024-01-06T12:44:21+00:00 urn:sha1:cdee4a435a7d0d4abac29ea38f8bee9b53e9830e 2024-01-02T16:50:06+00:00 Ron Yorston rmy@pobox.com 2024-01-02T16:50:06+00:00 urn:sha1:cca8c8e806db11810e25c8fa9446e86431aa2a53 Commit 7390f29cf (build system: allow building with w64devkit) checked the target of the host compiler to determine if it was Windows. This relied on the target being a triple of the form *-*-mingw32. Some compilers have a target of the form *-*-windows-gnu. Allow for this too. 2023-09-15T08:44:12+00:00 Ron Yorston rmy@pobox.com 2023-09-15T08:41:57+00:00 urn:sha1:54e6e2a16f2091d5dd1251bb3b4436555b1b0a03 The default configurations now include the provided standard or UTF-8 manifest. This works best if the build toolchain doesn't provide a default manifest (which Fedora and w64devkit don't, by default). If the toolchain does have a default manifest some bloat will result. (GitHub issue #366) 2023-08-03T17:57:53+00:00 Avi Halachmi (:avih) avihpit@yahoo.com 2023-08-03T15:23:23+00:00 urn:sha1:bf70275f786716546ec474caade0f16ec28da541 Previously, the unicode build required console (out) codepage of UTF8 in order for unicode output to be printed correctly - e.g. at the shell command prompt or the output of `ls` for unicode file names. This is inconvenient, because by default it's not UTF8, and so unless the user invoked 'chcp 65001' - by default unicode output didn't work. This feature (which is now enabled for the unicode build) makes it print unicode output correctly regardless of the console CP, by using a new stream-conversion funcion from UTF8 chars to wchar_t, and writing those using WriteConsoleW. If the console CP happens to be UTF8 - this conversion is disabled. We could have instead changed the console CP to UTF8, but that's a slippery slope, and some old program which expect the default CP might get broken, so achieving the same result without touching the console CP is hopefully better. 2023-07-22T06:40:36+00:00 Avi Halachmi (:avih) avihpit@yahoo.com 2023-07-16T18:29:08+00:00 urn:sha1:7aa64d90542cfc8f01f52ece38bf751c7b843875 Run ./scripts/mk_mingw64u_defconfig to create (or update) configs/mingw64u_defconfig from configs/mingw64_defconfig while enabling UTF8 manifest, UTF8 input, and unicode editing.