Chris Bagwell <chris at cnpbagwell.com> writes: > [snip] > Second question is this: I don't think its a good idea to link internal > versions of standard functions into the backends. As I mentioned > earlier, its super common for all projects to do this. If we link in, > for example, snprintf into libsane and then if someone else links in > libsane along with their own internal snprintf then we will get symbol > collisions and failed compiles.
ACK. > In the past, I've worked around this issue by using preprocessor magic. > When we detect internal version will be used then add a "#define > snprintf sanei_snprintf" to some global header file. Then normal code > keeps referring to just snprintf() but it sometimes get remapped to > internal version without library knowing it. Exported symbol table will > be proper sanei_ prefix as well. SANE backends should not export sanei_ symbols. The preprocessor magic you suggest sounds fine to me. Hope this helps, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS Corporation FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962