On 11/2/2016 1:12 PM, Waldemar Brodkorb wrote:
Hi Lance, Lance Fredrickson wrote,
On 11/2/2016 12:05 PM, Waldemar Brodkorb wrote:
Hi Lance, Lance Fredrickson wrote,
It seems as if static libc is missing symbols for libdl in uclibc-ng 1.0.19. When trying to static link I get the typical 'undefined to dl....' errors, but dynamic linking is successful.
But isn't that what is expected. From my understanding, you can't use dl* functions if you are using a fully static linked binary.
Are you trying a mixed situation? Supporting both modes?
Can you add some ore details to your use case. Thanks Waldemar
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.
I think you overreact here somehow.
Perhaps I have a little. We'll just say I'm overly passionate about this feature. I apologize.
I just have not concluded what exactly the problem in 1.0.19 is for you. I am willing to get back the functionality you need. I just have not understand it. So an example is always useful to get me understand your problem.
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