[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: dlopen(3) and symbol conflicts
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
Main Index |
Thread Index |