Handle the three potential system scenarios:
- system time_t is time64
- system time_t is time32 and supports time64
- system time_t is time32 and does not support time64
Add the explicit time32 and time64 functions when necessary and map
them accordingly for each of these cases.
Explicitly select what to include as part of the target ABI, instead of
letting autoconfiguration potentially break ABI if the system grows
functionality provided by the library.
Make almost all the library selectable per target. Do not install manual
pages for interfaces not included in the library. Control inclusion of
symbols in map file via pre-processor macros, and move the comments
describing the ABI selection to configure.ac.
For now the header files are included as is and filtered through
pre-processor conditionals. Eventually they might get switched to be
autogenerated at build time.
This makes sure we include it when expected, alongside the man pages,
and the test cases, and do not accidentally break the ABI if the system
starts providing such interface.
This function cannot be easily and (more importantly) correctly ported
without cooperation from the libc stdio layer. We already document that
users should be prepared to have the function not available on some
platforms and that they should ideally switch their code to other
more portable and better interfaces.
Instead of making the build fail, and requiring porters to add
exceptions for something that most probably cannot be ported correctly
anyway, simply print a warning and let it build. This will not be a
regression because on those systems libbsd would have never been built
before.
Prompted-by: Jens Finkhaeuser <jens@finkhaeuser.de>
This means we can add a trailing «\» to every element, so that they
can be removed without requiring modification of other lines, and can
be easily sorted.
Replace the old usage of $(nil) which could possibly end up with junk
added if such variable is ever defined, in the environment.
- Remove trailing spaces.
- Declare file-scope functions and variables static.
- Declare functions with a proper prototype.
- Do not mix declarations and code for C90 conformance.
- Do not compare size_t and ssize_t variables.
This reverts commit beafad2657.
This test was already handled later on as part of the BUILD_LIBBSD_CTOR
conditional. Adding it to the unconditional set made the build fail when
the system does not have GNU .init_array section support.
Closes: #9
Analysis-by: Duncan Overbruck <mail@duncano.de>
When using the recent dlsym() based wrapper, we are not requiring any
symbol from libmd, as we resolve those dynamically at run-time. We were
ending up linking against libmd because in another part of the code we
require (depending on the architecture) the SHA512 functions for the
getentropy() local implementation. But that function might be provided
by the system libc on some systems, which means we end up not linking
against libmd at all.
To solve this we go back to the previous simpler solution of linking
directly, which had the main drawback of then making programs fail to
link when not specifying -lmd (on platforms that need it). And then
switch the .so link point from a symlink to a linker script, so that we
can inject the -lmd library as-needed. This is similar to what glibc is
doing.
Fixes: commit 31f034e386
Switch from the previous versioned symbol implementation which required
users to also link against the message digest provider explicitly, or
they would fail to find the symbols, to an implementation that loads
the symbols from the linked library providing the functions using
dlsym(), thus preserving backwards compatibility.
This splits the implementation responsibilities, and reduces embedded
code copies, which was one of the driving points with this project to
start with, so it's nice to give a good example.
The NetBSD implementations have different prototypes to the ones coming
from OpenBSD, which will break builds, and have caused segfaults at
run-time. We provide now both interfaces with different prototypes as
different version nodes allow selecting them at compile-time, defaulting
for now to the OpenBSD one to avoid build-time breakage, while emitting
a compile-time warning. Later on, in 0.10.0, we will be switching the
compile-time default to the NetBSD version.
Ref: http://gnats.netbsd.org/44977
Fixes: https://bugs.debian.org/899282
Although the current implementation in libbsd is probably one of the
safest ones around, it still poses some problems when used with many
file streams. This function has now a replacement, that is both more
standard and portable. Ask users to switch to getline(3) instead.
In case the support is not available, just stop building the
libbsd-ctor.a library, which is a nice to have thing, but should not
have been a hard requirement from the start. This should allow to
build libbsd on non-glibc based systems using another libc.
This is a wrapper over the glibc fopencookie() function.
We diverge from the FreeBSD, OpenBSD and DragonFlyBSD declarations,
because seekfn() there wrongly uses fpos_t, assuming it's an integral
type, and any code using that on a system where fpos_t is a struct
(such as GNU-based systems or NetBSD) will fail to build. In which case,
as the code has to be modified anyway, we might just as well use the
correct declaration.
The automatic initialization cannot be part of the main shared library,
because there is no thread-safe way to change the environ global
variable. This is not a problem if the initializaion happens just at
program load time, but becomes one if the shared library is directly or
indirectly dlopen()ed during the execution of the program, which could
have either kept references to the old environ or could change it in
some other thread. This has been observed for example on systems using
Samba NSS modules.
To avoid any other possible fallout, the constructor is split into a
new static library that needs to be linked explicitly into programs
using setproctitle(). As an additional safety measure the pkg-config
linker flags will mark the program as not allowing to be dlopen()ed
so that we avoid the problem described above.
Reported-by: Jan Alexander Steffens (heftig) <jan.steffens@gmail.com>
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=66679
This centralizes the setting so there's no duplication anymore,
makes sure the user supplied variables are never overridden, and
are only set when using gcc.
Reported-by: Samuli Suominen <ssuominen@gentoo.org>
