On 11/2/2016 12:05 PM, Waldemar Brodkorb wrote: Maybe if this were the glibc mailing list you could expect that. One of the things uclibc (and musl) toughts over glibc is that you can create fully static binaries, this has always been the case for as far as I've know uclibc, so I am very perplexed by your response. This has only become an issue in the latest release. All the other libraries functionality have been place into libc itself, ie libm, libpthread, librt, libdl. Now that this has been done, you shouldn't ever have missing symbols from any of these libraries, be it dynamic or static. Why wouldn't you be able to static link with dl* functions? I've been doing it for years. Is this not a major reason people would use uclibc other than for size as well? For it's static linking capabilities? uclibc allows this, where in glibc static linking is discouraged, and most often not even possible if your application has need for dns lookups. My environment provides all dynamic and static libraries, and the user is left up to either dynamically linking or statically linking, though it is most often used for static linking. Many many applications use dl* functions, so I assure you I've been static compiling them long before uclibc forked to uclibc-ng. Thanks, Lance

On 11/2/2016 1:12 PM, Waldemar Brodkorb wrote: Perhaps I have a little. We'll just say I'm overly passionate about this feature. I apologize. The result is that programs that require dl symbols fail to compile at all in a static matter. I do realize that the 'dl' in libdl stands for dynamic linking, but these static programs in some cases need these symbols nonetheless, and otherwise fail to compile. OpenVPN is one such example. It requires libdl, and it does operate as expected when compiled statically. SoftEtherVPN, tranmission, unbound, are just a few more I can confirm. The list would be very large. I do think it would be ideal to omit libdl from libc, but static linking is simply not something many application maintainers even think about, nor have cross their minds. In the case of OpenVPN, dynamic libdl would be necessary if you want to use the libpam auth plugin. Compiling it statically you lose this functionality, just by the nature of how libpam works. Some applications that depend too heavily on plugins simply cannot be static compiled. Some applications you may lose some functionality, but can operate without. (OpenVPN libpam auth) Some applications I think just want to delay loading these libraries, which is fine, but not critical to the function of the program. Or in the case of OpenVPN, it may only want to load libcrypto if encryption is enabled on the vpn. Same with liblzo2. There is no harm with static linking these libraries if you want their functionality, but there typically is no configure script provision to completely exclude libdl. The biggest issue is that configure scripts always run their tests against the systems dynamic binaries, so it will see the working dynamic libdl, but fail when it thinks that functionality is present when statically linking. (just saw you last email, but I think think what I've written answers your question.) I am suggesting putting libdl.a back into libc.a. There are many programs that run fine at runtime that link with libdl. thanks, Lance

On 11/3/2016 4:14 AM, Thomas Petazzoni wrote: 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. 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