[haiku-development] Re: Symbol resolution problem with add-ons, userlandfs
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 13 Jul 2014 10:44:30 +0200
On 07/13/2014 01:30 AM, Julian Harnath wrote:
while working with userlandfs I ran into a problem related to mutexes
and the runtime loader.
My FS-addon uses kernel mutexes, so when compiling for userlandfs it
should use the implementation from kernelland_emu
(libuserlandfs_haiku_kernel.so).
There is a problem with mutex_init() though: libroot also has a
function by the same name. So when userlandfs_server loads my FS-add-
on, the runtime loader chooses the mutex_init symbol from libroot and
not from libuserlandfs_haiku_kernel.
Is there any way around that? Making it use the symbol from the correct
library when loading the add-on? LD_PRELOAD doesn't work either for
this case.
I'm afraid there isn't a trivial solution. When multiple libraries
provide the same symbol the runtime loader must try to resolve all
references to the same provider. So I see two different angles to
approach the issue from: 1. avoid clashing symbols in the first place
and 2. hack the runtime loader to resolve to the one we want in that case.
For 2. there's already an API provided by the runtime loader (in
headers/private/runtime_loader/runtime_loader.h), though that needs some
reworking. I also don't know, if it would be sufficient in the is case.
For 1. there are a few options:
* libroot shouldn't leak private symbols. We should always use some kind
of namespace. For C++ that's usually the BPrivate::* or B* one, for C
symbols there's only __*. The latter should be used, possibly in
combination with macros, so that we don't have to touch all users.
* As a work-around on the userlandfs side, libuserlandfs_haiku_kernel.so
could be made a static library and the FS add-on could be linked
symbolically. Not sure, if this can really work.
* libuserlandfs_haiku_kernel.so could export versioned symbols. When the
FS add-on is linked against it, it will reference the versioned symbols
which shouldn't clash with the unversioned ones from libroot. Or so I hope.
CU, Ingo
Other related posts:
