Emmanuel Dreyfus <manu%netbsd.org@localhost> 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