Re: dlopen(3) and symbol conflicts

[uwe%stderr.spb.ru@localhost (Valery Ushakov)]

Emmanuel Dreyfus <manu%netbsd.org@localhost> wrote:

> 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.

Uhm, uuid_compare() is not weak, is it?

$ readelf -a /usr/lib/libc.a | grep uuid_compare
File: /usr/lib/libc.a(uuid_compare.o)
     1: 00000000     0 FILE    LOCAL  DEFAULT  ABS uuid_compare.c
     8: 00000000   272 FUNC    GLOBAL DEFAULT    1 uuid_compare

$ readelf -aD /lib/libc.so | grep uuid_compare
 2399 824: 00030d74   300 FUNC    GLOBAL DEFAULT   7 uuid_compare

-uwe