3 Nov
2016
3 Nov
'16
4:04 p.m.
On 11/3/2016 4:14 AM, Thomas Petazzoni wrote:
I think the idea is that if you're doing a static
build, then
everything should be static, and there shouldn't be any shared object
in the system, be they used at link time or at run time (via dlopen).
The build
environment I make is for general purpose compiling. Because
not everything can be statically compiled it allows for both dynamic
linking as well. I specifically have dynamic and static versions of all
libraries. When there is a disparity of available features between the
dynamic and static libraries, it further complicates things when doing a
static compilation.
However, what confuses me is that this behavior is not
new. We have
been having build failures related to dlopen()/dlfcn.h being not
available in static uClibc builds for a while. I don't see this as
being new in 1.0.19.
The specific commit effecting me is one Waldemar mentions,
9b1077dc70e52ee85a718bce3fcfec7ae9af2967. When I revert just the libdl
portion of this commit, the expected functionality is restored to that
of the pre 1.0.19 release. The static functionality of libdl has been
providing since before uclibc-ng (at least in a hybrid environment),
either in it's own full static library, as well in libc.a when that
change was recently made. In a hybrid environment, dlfcn.h would always
be available, we've only just recently changed whether libdl is
available in a static form in this last release. I've never experimented
with pure static toolchains, but I would suspect that some of the
software the fails to build there, could be built in a hybrid
environment and even function, depending on it's use of libdl. Or if the
static toolchain had the dl headers, and the static library included,
additional software would compile, and possibly work as well like
possible in a hybrid environment, depending on its usage of libdl.
thanks,
Lance