Description
NUT sources include a number of fallback implementations of certain methods that not all target platforms provide on their own.
Ways to integrate those differ:
- a few are listed in
configure.ac
in theAC_REPLACE_FUNCS()
method, causing autotools to generate the needed goals for missing code, and are listed asLTLIBOBJS
macro in that build circumstance - many cases are listed in our
Makefile.am
explicitly, as a pattern like
if !HAVE_SOME_METHOD
something_SOURCES += some_method.c
endif !HAVE_SOME_METHOD
- possibly other tricks are also used (primarily in test code optionally including C files like headers, but that may be or not be not too interesting for this clean-up)
This issue is about investigating more about this, and perhaps simplify recipes where we needlessly re-invented a wheel we are already using elsewhere.
From work done in #2825/#2828 we know that LTLIBOBJS
should be used carefully, as they are tacked into our helper libraries (mostly under common/
) and it is very possible to end up including two libraries with competing (albeit identical) copies of the object code, or a library and object explicitly (when building a library).
It may make sense to have a further helper library made of only LTLIBOBJS
(and maybe some dummy object so it is never empty) that all others can depend on, ensuring a single implementation as far as linker is concerned. This may be (or not be) coupled with #2097 to provide the strings from nut_version.h
as that "dummy object".
Maybe all other Makefiles have to be updated, so that library is linked into final programs and published libraries (static/shared) explicitly and on same level as other libcommon*.la
helpers, and not through them (complicating the dependency and rebuild tree, and possibly re-introducing those linker conflicts).