| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
When looking at how dlopen for various libs is implemented, I found that the
macros hide too much. I find it much easier to see what is going on if 'extern'
and '= NULL' are written explicitly. After all, we don't hide those for other
definitions, e.g. our style guide says that static variables should be
initialized with '= NULL'. With that change, it's much more obvious what is
a variable declaration and what is a variable initialization.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have these pretty macros, let's use them everywhere (so far we mostly
used them for newer additions only).
This PR is mostly an excercise in "perl -p -i -e", but there are some
special cases:
* idn-util.c exposes a function whose prototype in the official library
headers is marked with the "const" attribute, and this apparently does
not propagate along typeof() correctly and then
__builtin_types_compatible_p() fails later because it detects that
prototype and original function don't match in prototype.
* libbpf removed some symbols in newer versions, hence we need to define
some prototypes manually to still be able to build.
* libcryptsetup marked a symbol as deprecated we want to use (knowing it
is deprecated). By using the macros this is detected by the compiler.
We work around it via the usual warning off macros.
Note by using these macros we assume that all symbols are known during
build time. Which might not be the case. We might need to revert this
commit for some symbols if this trips up builds on older distros.
|
|
|
Then, use dlopen_many_sym_or_warn() with DLSYM_ARG() macro.
|
