2 Nov
2016
2 Nov
'16
7:12 p.m.
Hi Lance,
Lance Fredrickson wrote,
On 11/2/2016 12:05 PM, Waldemar Brodkorb wrote:
I think you overreact here somehow.
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.
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 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.
best regards
Waldemar