libbsd merge requestshttps://gitlab.freedesktop.org/libbsd/libbsd/-/merge_requests2021-01-01T17:22:02Zhttps://gitlab.freedesktop.org/libbsd/libbsd/-/merge_requests/10Add recallocarray() and freezero() from OpenBSD2021-01-01T17:22:02ZFaidon LiambotisAdd recallocarray() and freezero() from OpenBSDAdd recallocarray(), introduced in OpenBSD 6.1, and freezero(),
introduced in OpenBSD 6.2. The former is imported as-is from OpenBSD,
while the latter is the non-malloc-internal branch of the same code (and
also the OpenSSH portable vari...Add recallocarray(), introduced in OpenBSD 6.1, and freezero(),
introduced in OpenBSD 6.2. The former is imported as-is from OpenBSD,
while the latter is the non-malloc-internal branch of the same code (and
also the OpenSSH portable variant).
Both of these originated in OpenBSD, but have also been implemented by
IllumOS, cf. https://www.illumos.org/issues/8546
Documentation for these functions is in malloc(3) upstream, the relevant
parts of which were previously imported in reallocarray(3bsd). Update
reallocarray(3bsd) with the changes that were introduced since, and add
the relevant bits for recallocarray() and freezero(), plus aliases.https://gitlab.freedesktop.org/libbsd/libbsd/-/merge_requests/9Draft: Fix compile for MinGW with `CPPFLAGS="-D__need_FILE" ./configure`2020-12-18T19:14:27ZJon DanielDraft: Fix compile for MinGW with `CPPFLAGS="-D__need_FILE" ./configure`Adds missing type checks and defines
Compiles with CPPFLAGS="-D__need_FILE" ./configureAdds missing type checks and defines
Compiles with CPPFLAGS="-D__need_FILE" ./configurehttps://gitlab.freedesktop.org/libbsd/libbsd/-/merge_requests/8Fix ELF detection on Intel compilers2021-01-01T17:22:44ZSeth R. JohnsonFix ELF detection on Intel compilersThe Intel compiler does not define `__amd64__` on x86_64 platforms;
instead, like other compilers, it defines `__x86_64__` .
References:
- [pre-defined compiler macros list](https://sourceforge.net/p/predef/wiki/Architectures/)
- [simil...The Intel compiler does not define `__amd64__` on x86_64 platforms;
instead, like other compilers, it defines `__x86_64__` .
References:
- [pre-defined compiler macros list](https://sourceforge.net/p/predef/wiki/Architectures/)
- [similar issue on intel help forums](https://software.intel.com/en-us/forums/intel-c-compiler/topic/302899)https://gitlab.freedesktop.org/libbsd/libbsd/-/merge_requests/7Support AArch64 ILP322019-08-08T02:04:04ZFrank SchaeferSupport AArch64 ILP32ILP32 is kind of a thing now on AArch64, so let's support it.
Without this fix, test/nlist in particular fails on AArch64 ILP32 (for obvious reasons).ILP32 is kind of a thing now on AArch64, so let's support it.
Without this fix, test/nlist in particular fails on AArch64 ILP32 (for obvious reasons).https://gitlab.freedesktop.org/libbsd/libbsd/-/merge_requests/6local-elf: Add ARC support2019-08-08T02:04:30ZRosen Penevlocal-elf: Add ARC supportSigned-off-by: Rosen Penev <rosenp@gmail.com>Signed-off-by: Rosen Penev <rosenp@gmail.com>https://gitlab.freedesktop.org/libbsd/libbsd/-/merge_requests/5Update libbsd.7: Fix typo2019-08-08T02:04:56ZSebastianUpdate libbsd.7: Fix typohttps://gitlab.freedesktop.org/libbsd/libbsd/-/merge_requests/4nlist.h: Re-allow direct use of nlist.n_name2019-08-08T02:05:07ZJessica Clarkenlist.h: Re-allow direct use of nlist.n_nameCommit e8d340de ("Remove a.out support from nlist()") introduced a copy of the
definition of nlist from a.out.h. However, as well as having n_name inside
n_un, n_name could also be accessed as a direct member of nlist, and this is
made u...Commit e8d340de ("Remove a.out support from nlist()") introduced a copy of the
definition of nlist from a.out.h. However, as well as having n_name inside
n_un, n_name could also be accessed as a direct member of nlist, and this is
made use of by FreeBSD's usr.bin/netstat/main.c. Thus we should also add the
same enclosing anonymous union.https://gitlab.freedesktop.org/libbsd/libbsd/-/merge_requests/2Remove usage of __register_atfork2019-08-08T02:02:27ZFabrice FontaineRemove usage of __register_atforkCalling an internal function of glibc is never a good idea.
This is especially true for __register_atfork which is not defined on
uClibc with noMMU.
So remove call to __register_atfork and so always use pthread_atfork
Signed-off-by: Fab...Calling an internal function of glibc is never a good idea.
This is especially true for __register_atfork which is not defined on
uClibc with noMMU.
So remove call to __register_atfork and so always use pthread_atfork
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>https://gitlab.freedesktop.org/libbsd/libbsd/-/merge_requests/1Support building natively for Windows2022-02-19T10:35:42ZAaron DierkingSupport building natively for WindowsThis provides built-in support for cross-compiling a subset of libbsd for Windows using LLVM/Clang or MSYS2/MinGW. While many libbsd interfaces already support Windows, developers are currently required to manually modify libbsd's build ...This provides built-in support for cross-compiling a subset of libbsd for Windows using LLVM/Clang or MSYS2/MinGW. While many libbsd interfaces already support Windows, developers are currently required to manually modify libbsd's build system and header files in order to use them in a native environment. Changing/replacing libbsd code like this is difficult to maintain and it is not ideal for external projects which depend on libbsd and want to target Windows. I'm helping out with efforts to support the Swift programming language on Windows, and this is one of the roadblocks that we've hit. If this merge request is accepted, we will continue to maintain and test this through that project.
To simplify things, I've restricted this to only provide support for the libbsd interfaces that already work on Windows or which can be trivially ported to it. Interfaces that would require significant amounts of platform-specific code in order to build for Windows are not covered here, and some interfaces simply don't make sense on Windows (e.g. anything dealing with `mode_t` or file descriptors). There is currently also no support for building libbsd as a DLL (shared library). These restrictions are generally sufficient for most libbsd consumers who want to target Windows anyway.
I've tested these changes by running the following commands on a Linux system to cross-compile for Windows using a recent build of LLVM/Clang. (This requires the Windows SDK to be available and the `INCLUDE` and `LIB` environment variables to be set properly.)
$ export CC=clang
$ export AR=llvm-ar
$ export RANLIB=llvm-ranlib
$ export CFLAGS="-target x86_64-pc-windows-msvc -fuse-ld=lld -Xclang --dependent-lib=msvcrtd -Xclang --dependent-lib=oldnames -nostdlib"
$ export CPPFLAGS="-target x86_64-pc-windows-msvc -D_DEBUG -D_MT -D_DLL"
$ ./autogen && ./configure --host=x86_64-pc-mingw64
$ make checkGuillem JoverGuillem Jover