2 Nov
2016
2 Nov
'16
6:31 p.m.
On 11/2/2016 12:05 PM, Waldemar Brodkorb wrote:
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.
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
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