| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When `fstat` fails, `st` is left uninitialised. In our case, Ben Kohler
noticed our release media builds were failing in Gentoo on x86 when building
busybox with occasional SIGBUS. This turned out to be EOVERFLOW (from 32-bit
ino_t) which wasn't being reported because nothing was checking the return value
from `fstat`.
Fix that to avoid UB (use of uninit var) and to give a more friendly
error to the user.
This actually turns out to be fixed already in the kernel from back in
2010 [0] and 2016 [1].
[0] https://github.com/torvalds/linux/commit/a3ba81131aca243bfecfa78c42edec0cd69f72d6
[1] https://github.com/torvalds/linux/commit/46fe94ad18aa7ce6b3dad8c035fb538942020f2b
Reported-by: Ben Kohler <bkohler@gentoo.org>
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
In the function find_export_symbols, since the fopen file does not
exit when it fails, there is a dereference problem in fclose(fp),
which will cause a segmentation fault.
Signed-off-by: Yan Zhu <zhuyan2015@foxmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
| | |
| |
| |
| |
| | |
Recent versions of gcc fail to build the binary to test for
ncurses because main() is lacking a return type.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| | |
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.
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| | |
Bug: https://bugs.gentoo.org/893776
Closes: https://bugs.busybox.net/show_bug.cgi?id=15326
Signed-off-by: Arsen Arsenović <arsen@gentoo.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
'make menuconfig' uses a hardcoded colour palette which may be
difficult to read. Add support for the 'COLORS' environment
variable. Setting this to '0' will cause 'make menuconfig' to
be displayed in black and white.
(GitHub issue #273)
|
| | |
| |
| |
| |
| |
| |
| | |
Previously, pressing slash to search at the menu aborted the menu
program ('mconf'), because regexp is not available with native mingw.
Now it works, but the search is of plain string rather than regexp.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We need to build the supplied PDCurses code when using w64devkit.
This was being detected by checking for the W64DEVKIT environment
variable, but this is only defined if w64devkit is started via
w64devkit.exe.
Set W64DEVKIT ourselves if HOSTCC targets the mingw32 platform.
This won't be the case when cross-compiling on Linux but will
for w64devkit and MSYS2 MINGW32/64.
The build won't work properly for MSYS2 MINGW32/64, but it doesn't
work when using the supplied curses library either. 'make menuconfig'
requires the use of MSYS2 MSYS, and HOSTCC there targets msys.
|
| | |
| |
| |
| |
| |
| | |
The compiler in MSYS2 warns that strcasecmp(3) isn't declared in
scripts/kconfig/lxdialog/checklist.c. Add the appropriate include
to silence this warning.
|
| | |
| |
| |
| |
| |
| |
| | |
The WIN32 code in the 'mconf' build program should truncate the
exit status from dialogs as if it were passed through WEXITSTATUS.
The text dialog, for example, returns a status of -1 when ESC or
CR is pressed. 'mconf' expects to see this as 255.
|
| | |
| |
| |
| |
| |
| | |
w64devkit doesn't ship a curses library. Provide a cut-down copy
of PDCurses which is sufficient to allow 'make menuconfig' to work
in w64devkit.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
'make menuconfig' is a build option to allow changes to be made
to the BusyBox configuration. It's a bit friendlier than using
a text editor on the .config file.
Previously 'menuconfig' was only available when cross-compiling
on a Linux/Unix platform. The 'mconf' build program has been
ported to WIN32 so it's now able to run the 'lxdialog' program
which displays the configuration dialogs.
Building 'lxdialog' is somewhat awkward in MSYS2. The MINGW32/64
build environments generate WIN32 executables for 'lxdialog'.
These doesn't work properly in the MSYS2 console.
For 'menuconfig' to work it's necessary to run it in an MSYS
build environment. This generates an MSYS binary which works
in the MSYS2 console. busybox-w32 should then be built in a
MINGW32/64 build environment. Doing so will generate additional
copies of the build programs without a '.exe' suffix: the MSYS
build environment adds '.exe' to binaries it builds. This breaks
'menuconfig'.
To configure an MSYS build environment use:
pacman -S gcc ncurses-devel
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Upstream changes to the embedded_scripts and mkconfigs scripts
resulted in busybox-w32 failing to build with MSYS2.
bzip2 in MSYS2 detects stdout redirected to /dev/null as a terminal
and returns a non-zero exit status. Since the test is only for
the existence of bzip2, not its functionality, even an exit status
of 1 is OK. Only fail if the exit status is 127.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Make some adjustments to the build system to allow busybox-w32
to be built with w64devkit:
- Strip drive prefix from CURDIR in Makefile to avoid confusing
make with colons.
- Limit file redirection to a subshell in the usage_compressed and
embedded_scripts scripts. Otherwise it isn't possible to move
the open generated file on Windows.
- Change the option tests in Kbuild.include to allow for /dev/null
not existing on Windows.
- Create host binaries without a '.exe' extension. Otherwise they're
rebuilt more often than necessary.
- Modify split-include.c to allow for Windows' popen() not expanding
wildcards.
(GitHub issue #239)
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Pass down the correct EXTRA_CFLAGS to the compiler driver when building
assembler source.
Otherwise building busybox for a multilib other than the default failed
to link since hash_md5_sha256_x86-64_shaNI.o and
hash_md5_sha_x86-64_shaNI.o were built for the default arch which might
not what we requested in the EXTRA_CFLAGS.
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
|
| |\|
| |
| |
| |
| |
| | |
Fix merge conflict in miscutils/less.c.
Use exit_SUCCESS() where possible.
|
| | |
| |
| |
| | |
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
| | |
| |
| |
| | |
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
| |\| |
|
| | |
| |
| |
| | |
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
| | |
| |
| |
| | |
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The SOURCE_DATE_EPOCH is an effort of the Reproducible Builds
organization to make timestamps/build dates in compiled tools
deterministic over several repetitive builds.
Busybox shows by default the build date timestamp which changes whenever
compiled. To have a reasonable accurate build date while staying
reproducible, it's possible to use the *date of last source
modification* rather than the current time and date.
Further information on SOURCE_DATE_EPOCH are available online [1].
This patch modifies `confdata.c` so that the content of the
SOURCE_DATE_EPOCH env variable is used as timestamp.
To be independent of different timezones between builds, whenever
SOURCE_DATE_EPOCH is defined the GMT time is used.
[1]: https://reproducible-builds.org/docs/source-date-epoch/
Signed-off-by: Paul Spooren <mail@aparcar.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When include/applets.h is re-generated
it generates code macros in include/applets.h e.g.
IF_XZCAT(APPLET_ODDNAME(xzcat, unxz, BB_DIR_USR_BIN, BB_SUID_DROP, xzcat))
...
IF_CHVT(APPLET_NOEXEC(chvt, chvt, BB_DIR_USR_BIN, BB_SUID_DROP, chvt))
...
sed is used to process source files like below to feed into this header
generation
sed -n 's@^//applet:@@p' "$srctree"/*/*.c "$srctree"/*/*/*.c
this means we let shell decide the order of .c files being fed into sed
tool, applets.h has code snippets thats generated out of code fragments
from these .c files and the order of the generated code depends on the
order of .c files being fed to sed and then piped to generate tool, even
though the generated code is logically same, it does result in re-odered
code in applets.h based on which shell was used during build on exact busybox
sources since sort order is different based on chosen locale and also default shell
being bash or dash
This sets the environment variable LC_ALL to the value C, which will
enforce bytewise sorting, irrespective of the shell
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
A CR in the gcc output would cause the following to show throughout build:
: invalid numberbox-1.32.1/scripts/gcc-version.sh: line 12: printf: 9
Signed-off-by: Chris Renshaw <osm0sis@outlook.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
| | |
| |
| |
| |
| |
| |
| | |
On Cygwin, "echo __GNUC__ __GNUC_MINOR__ | gcc -E -xc -" can print
extra empty trailing line.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
| | |
| |
| |
| | |
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Commit 4bdc914ff (build system: fix compiler warnings) added a
test on the return value of fgets() in split-include.c.
During bisection it's possible to go back to a state where a
configuration value didn't exist. This results in an empty
include file corresponding to the missing feature. If a
subsequent bisection returns to a state where the feature exists
split-include treats the empty file as an error and the build
fails.
Add a call to ferror() to distinguish between fgets() failing
due to an error and due to there being no data to read.
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Disable 'echo' in the default config, run 'make baseline', then
re-enable 'echo' and run 'make bloatcheck':
function old new delta
.rodata 182521 182622 +101
packed_usage 33714 33792 +78
applet_main 3168 3176 +8
applet_names 2730 2735 +5
applet_suid 99 100 +1
applet_install_loc 198 199 +1
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 6/0 up/down: 194/0) Total: 194 bytes
text data bss dec hex filename
955052 4195 1808 961055 eaa1f busybox_old
955153 4195 1808 961156 eaa84 busybox_unstripped
The Total bytes value doesn't equal the change in the size of the
binary. The packed_usage and applet_* items are in .rodata and
are counted twice. With this modified bloat-o-meter the size of
named items is deducted from .rodata:
function old new delta
packed_usage 33714 33792 +78
applet_main 3168 3176 +8
.rodata 105105 105113 +8
applet_names 2730 2735 +5
applet_suid 99 100 +1
applet_install_loc 198 199 +1
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 6/0 up/down: 101/0) Total: 101 bytes
text data bss dec hex filename
955052 4195 1808 961055 eaa1f busybox_old
955153 4195 1808 961156 eaa84 busybox_unstripped
v2: Sections numbered less than 10 were always being omitted from
consideration because splitting "[ 1] .interp" leaves "1]" in
x[1] where the section name is expected. This wasn't a problem
for .rodata (numbered 15 in my testing) but let's fix it anyway.
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
| | |
| |
| |
| | |
Plus a few other make targets that make measurements on the binary.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Disable 'echo' in the default config, run 'make baseline', then
re-enable 'echo' and run 'make bloatcheck':
function old new delta
.rodata 182521 182622 +101
packed_usage 33714 33792 +78
applet_main 3168 3176 +8
applet_names 2730 2735 +5
applet_suid 99 100 +1
applet_install_loc 198 199 +1
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 6/0 up/down: 194/0) Total: 194 bytes
text data bss dec hex filename
955052 4195 1808 961055 eaa1f busybox_old
955153 4195 1808 961156 eaa84 busybox_unstripped
The Total bytes value doesn't equal the change in the size of the
binary. The packed_usage and applet_* items are in .rodata and
are counted twice. With this modified bloat-o-meter the size of
named items is deducted from .rodata:
function old new delta
packed_usage 33714 33792 +78
applet_main 3168 3176 +8
.rodata 105105 105113 +8
applet_names 2730 2735 +5
applet_suid 99 100 +1
applet_install_loc 198 199 +1
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 6/0 up/down: 101/0) Total: 101 bytes
text data bss dec hex filename
955052 4195 1808 961055 eaa1f busybox_old
955153 4195 1808 961156 eaa84 busybox_unstripped
v2: Sections numbered less than 10 were always being omitted from
consideration because splitting "[ 1] .interp" leaves "1]" in
x[1] where the section name is expected. This wasn't a problem
for .rodata (numbered 15 in my testing) but let's fix it anyway.
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
| |\| |
|
| | |
| |
| |
| | |
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
These items are already listed, albeit without `.exe` suffix.
Presumably, this is because BusyBox-w32 is traditionally cross-compiled
on Linux.
However, we are about to introduce a CI build definition that builds
BusyBox-w32 in MSYS2 (using mingw-w64-gcc), meaning that those
executables might very well exist _with_ `.exe` suffix.
Let's ignore those, too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
To investigate GitHub issue #200 it was necessary to perform
build on Window using the MSYS2/mingw-w64 toolchain. This
threw up some issues:
- The settings for _WIN32_WINNT and __USE_MINGW_ANSI_STDIO differ
from those in Fedora resulting in compiler errors and warnings.
Force the defaults I'm used to.
- The workaround to allow native compilation of mconf.c was broken
by a subsequent upstream change. Make it work again.
|
| |\| |
|
| | |
| |
| |
| | |
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
