Re: dlopen(3) and symbol conflicts

[David Holland <dholland-tech%netbsd.org@localhost>]

On Thu, Mar 19, 2015 at 06:30:44PM +0000, Valery Ushakov 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

Inasmuch as it's not a Standard C function, that'd be a bug.

-- 
David A. Holland
dholland%netbsd.org@localhost