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