Unfortunately, we can't just add the generated C file to the sources in
Makefile.am as the linker would remove that object file when it notices
that no symbol in it is ever referenced. So we include it in the file
that contains the library initialization, which will definitely be
referenced by the executable.
This allows building an almost stand-alone static version of e.g. charon
when building with `--enable-monolithic --enable-static --disable-shared`
(without `--disable-shared` libtool will only build a version that links
the libraries dynamically). External libraries (e.g. gmp or openssl) are
not linked statically this way, though.
Because settings are already accessed in library_init(), calling
add_fallback() externally after calling library_init() is not ideal.
This way namespaces already serve as fallback while library_init() is
executed and they are also in the correct order so that libstrongswan is
always the last root section.
To avoid any race conditions when multiple threads call and initialize
diffie_hellman_get_params(), explicitly examine the optimum DH exponent size
during library initialization.
Fixes#655.
Due to the removal of pthread_once, we manually create the seed for
chunk_hash(). With the new testable functions interface, this won't work for
the hashtable initiated using __attribute__((constructor)). Enforce seeding
before creating that hashtable.
Passing back the buffer address we memwipe() is not ideal, as it could, in
theory, change the behavior of the compiler and not-optimize memwipe(). But
as checking a larger stack is very difficult for different architectures
and compilers, we do it nonetheless for now.
getaddrinfo(3) may block a long time so proper termination of the daemon may
block if DNS servers are not reachable.
getaddrinfo(3) is an optional cancellation point in posix threads so it
might still block a shutdown but at least on Android (with the signal based
pthread_cancel implementation) it works, on Linux starter will kill charon
anyway after a while.
The invocation of addr2line to resolve backtrace source locations
is slow and cumbersome. When using libbfd directly, we can eliminate
the overhead of the process invocation. Even better, we can cache
library symbol names, bringing wicked fast lookups. As a neat bonus,
we can resolve static function names.
If plugins are not explicitly unloaded before library_deinit is called
there could have been a segfault because some plugins might unregister
objects during unloading/destruction.
I changed only the includes needed to fix the build on Android, which has an utils.h system header file, but we should probably change all the local includes in libstrongswan to "" and relative paths.
Tobias Brunner