In issue https://github.com/termux/termux-packages/issues/6160 I have found
that community repo "its-pointless.github.io" specifies us as maintainer
for its packages. This is NOT TRUE and potentially misleads people using
these packages.
Now TERMUX_PKG_MAINTAINER will contain a default value which is neutral
and not specify maintainer. So all packages now have to override it to
the correct value.
[skip ci]
%ci:no-build
Variables
TERMUX_PKG_PLATFORM_INDEPENDENT
TERMUX_DEBUG
TERMUX_PKG_HAS_DEBUG
TERMUX_PKG_ESSENTIAL
TERMUX_SUBPKG_ESSENTIAL
TERMUX_PKG_NO_STATICSPLIT
TERMUX_PKG_BUILD_IN_SRC
TERMUX_PKG_FORCE_CMAKE
TERMUX_PKG_HOSTBUILD
should not accept arbitrary values for marking them "enabled". Instead
they should accept boolean values which makes them easier to handle and
also makes their meaning clear.
build-package.sh should make decision based on variable's value but not on
whether it is set or empty.
%ci:no-build
Work around rpl_malloc being used, see
http://wiki.buici.com/xwiki/bin/view/Programing+C+and+C%2B%2B/Autoconf+and+RPL_MALLOC
for more information:
"The AC_FUNC_MALLOC macro makes sure that the malloc function when passed a zero
argument returns a valid memory block instead of a NULL pointer. This behaviour
conforms to the GNU C library. Normally, this is a reasonable test that autoconf
makes at build-time. In the case of cross-compilation, however, autoconf cannot
execute a program to verify proper behavior. It makes the conservative assumption
that the target library will produce non-conforming code.
Failure of this test causes autconf to replace malloc() calls with rpl_malloc()
calls. At link time, if there is no rpl_malloc() function, the linker will fail
with an error describing the missing symbol. The autoconf documentation recommends
adding this harmless code to the application to implement the function."
In Termux the rpl_malloc() usage is useless at best, and may also prevent building
some packages as well as giving runtime crashes for libgc-using packages or others
expecting to intercept malloc.
Previously some packages specified worked around this themselves, but the configure
arguments are now moved into build-package.sh.
Leonid Pliushch
Fredrik Fornwall