It can be dropped because this code was never actually enabled.
Actually, this implementation *surely* never ever compiled.
Signed-off-by: Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
Older versions of glibc included an fts implementation that didn't have
Large File Support on 32-bit systems. We worked that around by bundling
fts into rpm codebase. Thanks to Mark Wielaard, glibc >= 2.23 has LFS
support in fts.
Unfortunately, we can't drop bundled fts because we have to support
build with other libcs which do not implement fts at all or their
implementations do not provide Large File Support.
Signed-off-by: Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
[pmatilai: Added comment to configure.ac as the test is rather subtle,
thanks for Mark Wielaard for the explanation]
The RPM code contains setprogname()/getprogname() support implemented through compatiblity layer with very old GLIBC (internals supported back to '95 and earlier), before stabilization of the GNU C library. This compatiblity layer (__progname, __assert_progname, setprogname()) is supposed to support well archaic GLIBC, but on the other hand it pollutes the library namespace and introduces unpredicable compillation errors on BSD systems.
The functions setprogname() and getprogname() are natively supported in NetBSD and work the same way as __progname from the GNU C library (they are even implemented in the same way - but with a slightly changed logic). The support for very old (20 years and older) GNU C Library is obfuscating the code, because it uses defines over defines without a word of explaination why to do so.
It's important to note that the setprogname()/getprogname() was inconstiently implemented in the codebase, duplicating the code and/or functionality.
Add new generic functions getprogname() and setprogname() and bind it to:
- the current and for two decades stable GNU LIB C implementation,
- the current NetBSD implementation (introduces to NetBSD in 2002),
- fallback reimplementation functions of the setprogname() and getprogname() functionality for other systems.
Don't support anymore old GNU Lib C internals and don't support older NetBSD systems, as they aren't supported for many years.
Add to the codebase comments explaining the relevant codeparts.
So, as it turns out, pretty much all libc implementations
except for legacy ones implement it as fstat64(), so we
will use fstat64() unless otherwise necessary.
Also, fix typo in checking for _D_EXACT_NAMLEN definition.
The definitions were refactored because musl-libc does
not offer a __MUSL__ definition and μClibc tries to
identify as glibc, even though it's not quite compatible.
A nice side effect of this is that the platform support
definitions are somewhat simpler now.
__BEGIN_DECLS and __END_DECLS are already defined in the NetBSD's standard C
library as an internal definition and redefinition of it causes errors.
The possible solutions are to rename the definitions or take rid of them.
Actually __BEGIN_DECLS and __END_DECLS are used only once and encapsulate
'extern "C" {' and '}', so they aren't really helping more then obfuscating
the code.
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
- Lump glob.h and glob.c into rpmglob.c in all their g(l)ory libc
decorations and make everything static to stop overriding system
library symbols with our own glob().
- This is not really native rpm code but a copy of (glibc?) FTS
implementation, with slight modification to avoid symbol name
collisions. Stick it where the sun don't shine, we'd eventually
like to get rid of such bundled external code.
- only the lua posix extension "uses" this by providing putenv()
to Lua, make it conditional and return error if not supported by
the underlying operating system
- POSIX doesn't require PATH_MAX to be defined as constant, and Hurd
doesn't define it...
- deal with it just once in system.h for now, the proper fix is to get
rid of needing it at all (ie add a mallocing realpath() clone to librpmio)
- patch from Adam Tkac
- Replace INCLUDES with AM_CPPFLAGS
(INCLUDES has been replaced by AM_CPPFLAGS and is deprecated in
modern automakes for several years)
- Require autoconf-2.61 and automake-1.10
(already required by autogen.sh)
- update mkinstalldirs with the version from automake-1.10
(The version in rpm is ancient and known to be bugged)
Patch from Ralf Corsepius
Panu Matilainen