This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
I need a workaround (!) for "undefined reference to `__ctype_b'"
- From: Hartmut Niemann <Hartmut dot Niemann at gmx dot de>
- To: libc-help at sourceware dot org
- Date: Thu, 26 Feb 2009 05:55:44 +0100
- Subject: I need a workaround (!) for "undefined reference to `__ctype_b'"
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