[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 15 Apr 2015 03:17:07 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Concerns about dlclose() behaviour
On Tue, Apr 14, 2015 at 11:29:17PM -0700, Brad Conroy wrote:
> I recently checked out the netsurf-framebuffer package from debian
> and was bothered that all of the backends were compiled in...
> thus requiring a bunch of extra dependencies and increasing footprint.
>
> I am currently patching it to make the backends modular, but ran into
> a concern about musl compatibility.
>
> libnsfb is set up in such a way that each backend has (static) functions
> exported in a single struct. With normal dlclose() functionality, I could
> use dlopen to get a module and run its init function, then if it fails, just
> dlclose() it and try the next backend (all using the same variable and
> function names, thus simplifying the implementation)
>
> I am thinking this will still work on musl in a way similar to using
> LD_PRELOAD, but wanted to verify before moving forward since many
> nsfb users also use musl.
If I understand correctly, what you're hoping is that dlclose will
remove the symbols loaded by dlopen so that you can replace them with
new definitions. This is not going to happen, but I'm not sure your
conclusion that you need it to happen is correct. If you're using
RTLD_LOCAL, the names aren't even global to begin with. How are you
calling/accessing them? By dlsym? Or is some other library getting
loaded and binding to the names in the global (RTLD_GLOBAL) namespace?
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
