multiply-defined in Client SDK

One of our own archive libraries, mylib.a, has the below global function defined as "int sfree( void *ptr )". Now, after installing the Client SDK 2.0.2, I got the below linking error: UW: ld: ERROR: ... /db/lib/libasf.a(al.o): fatal error: symbol 'sfree' multiply-defined, also in file mylib.a(dshm.o) 'sfree' is not declared anywhere in the Client SDK header files. Is this a bug in Informix SDK and should be fixed or I have to do something else on my part to avoid this ? For the latter, any suggestion is appreciated. We don't want to change our function name, sfree, to something else if we don't have to. Thanks, Thanh Sent via Deja.com http://www.deja.com/ Before you buy.

tqma@my-deja.com wrote: > One of our own archive libraries, mylib.a, has the below global > function defined as "int sfree( void *ptr )". Now, after installing > the Client SDK 2.0.2, I got the below linking error: > > UW: ld: ERROR: ... /db/lib/libasf.a(al.o): fatal error: symbol 'sfree' > multiply-defined, also in file mylib.a(dshm.o) > > 'sfree' is not declared anywhere in the Client SDK header files. > > Is this a bug in Informix SDK and should be fixed or I have > to do something else on my part to avoid this ? For the latter, > any suggestion is appreciated. We don't want to change our function > name, sfree, to something else if we don't have to. It depends on your definition of bug. There is always a risk that you will choose a function name that collides with a name in the ESQL/C libraries; you've just demonstrated that. You've also demonstrated that there isn't any particularly obvious naming convention used by Informix to hide the functions within their libraries. Since I learned programming in a Fortran library writing project where every function began with G, all the internal functions began GK, the majority of functions were specific to a device driver so they began GK0P or GK1T, and because this was Fortran you only had 6 monocase characters to play with, I learned how to follow naming conventions religiously. The Informix coding standards are incredibly sloppy by comparison. Roll on C++ namespaces! So, you've lost temporarily. You will need to file a bug report about the conflict, and then rename your function to something other than sfree(). And don't hold your breath waiting for the problem to be fixed. I largely gave up on C-ISAM when I found it defined a function error() which clashed with my standard function of the same name. Ugh! -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v0.62 -- see http://www.perl.com/CPAN #include <disclaimer.h>