2 Nov
2016
2 Nov
'16
9:04 p.m.
On 11/2/2016 1:12 PM, Waldemar Brodkorb wrote:
Hi Lance,
Lance Fredrickson wrote,
Perhaps I have a
little. We'll just say I'm overly passionate about this
feature. I apologize.
On 11/2/2016 12:05 PM, Waldemar Brodkorb wrote:
I think you overreact here somehow. Hi Lance,
Lance Fredrickson 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. 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 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