tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: dlopen(3) and symbol conflicts

Emmanuel Dreyfus <> writes:

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

Having a mechanism to override and trying to use it are two separate
issues :-)

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

But if glusterfs called this gl_uuid_compare instead, then none of this
would be an issue.

Attachment: pgpRL0aACBSP2.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index