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