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