I need a workaround (!) for "undefined reference to `__ctype_b'"

Hartmut Niemann Hartmut.Niemann@gmx.de
Thu Feb 26 04:53:00 GMT 2009


Hello everybody!

I have a precompiled .o (and .fpo) file where I can not get full source disclosure (for 
reasons I must accept) from the company that creates the software module.
When I link that to my program, I get
undefined reference to `__ctype_b'
errors.
(Debian Testing, by the way)

>From searches in the web it looks like they used a very old libc to compile it,
and the symbol was removed somewhere around glibc 2.3 or so.

Now my question is:

Obviously the module uses a libc function that needs this symbol.
How can I find out, which one?

I can not request recompilation with a recent setup (it would help, but 
probably break compatibility with legacy systems) or full source code
from that company, but if I can point them to a few library functions, 
they could wrap these in private functions, split those into 
something like mystring.c which they could distribute in source code.

e.g.

where they have now
closed-source.c         strcpy(d,c);

I could probably persuade them to change that to
closed-source.c        private_strcpy(d,c);

open-strings.c          char * private_strcpy(char * d, char * c) { return strcpy(d,c) ; }

and give me their closed-sorce.o and open-strings.c.
I would hope that closed-source.o would not contain references to ctype_b any longer, but to
private_strcpy, and those can be met by compiling open-strings.c against my current libc.

Two questions:
(1) would that work?
(2) what function(s) needed ctype_b and must be moved to open-strings.c?

Thank you for reading so far, and thank you for any hints you can give me.
With best regards
Hartmut



More information about the Libc-help mailing list