Re: dlopen(3) and symbol conflicts

[Emmanuel Dreyfus <manu%netbsd.org@localhost>]

On Thu, Mar 19, 2015 at 09:44:12AM -0400, Greg Troxel wrote:
> My not-really-thinking reaction is that having a function in any user
> program that has the same name as a function in libc is asking for
> trouble and should be avoided.

This is why libc symbol are weaks and are meant to be overriden by 
the ones with same names from user libraries and programs.

In the case I face, the problem is with uuid_compare. NetBSD and Linux 
have source and binary incompatible versions. A program like glusterfs 
that uses UUID can work this around by providing its own implementation
(which is the Linux version). The result is that a uuid_compare() call
in glusterfs goes to libglusterfs's uuid_compare() and not libc 
uuid_compare(). It works fine for any program linked with -lglusterfs
because libc symbols are weak.

However if we throw dlopen() into the equation, it breaks, libc weak 
symbols are not treated as such anymore.

-- 
Emmanuel Dreyfus
manu%netbsd.org@localhost