[Subject Prev][Subject Next][Thread Prev][Thread Next][Subject Index][Thread Index]
name clash between glibc and my program
After reading about how Torwalds use printk to debug the kernel, I
too wrote a function of my own called dprintf which, depending on a
few global settings, would print debugging formatted o/p into a file or
syslog, or whatever. The code worked beautifully, and I debugged quite a
few stuff using this. Then I had this brilliant idea of putting commonly
used functions into a library of my own, and link to it when needed. That
was when things started going haywire.
dprintf started dumping core on me. When I put dprintf.c into the source
itself, core dumps vanished. So after two days of trying to debug a
function meant to help me debug, I had this brainwave of nm /lib/libc.so
and yes, there it was - dprintf. I looked into stdio.h, and the function
was prototyped there as well, albeit in a #ifdef __USE_GNU.
I never used that macro. So why did my program get linked to the library
version? The version in the library is undocumented as well. The
prototypes were different, but the one that was used was mine (in a
header of my own), so no compilation errors were reported. The only
problem was that while linking, the library version was used.
So does that mean I cannot write code which use same names as
GNU extensions? I prefer to use portable code, and avoid gcc/gnu
extensions. But this means that I cannot have a function whose name
coincides with an extension.
So how do I tell the linker not to use GNU extensions, but look for
my functions and report error if one cannot be found? Or is that not
possible at all?
I know that I cannot have functions whose names fall in mem*, str*, is*,
to* etc., but I didn't know about *printf.
Right now I have renamed dprintf as debug_printf.
The prompt for all occasions:
export PS1="F:\$(pwd | tr '/[a-z]' '\134\134[A-Z]')> "
--------------- Binand Raj S. (binand@xxxxxxxxxxxxxxxxxxxxx)