Link failed: "undefined reference to `__ctype_b'"
Greg Lee
/gnome/lib/libxklavier.so: undefined reference to `__ctype_b'
/gnome/lib/libxklavier.so: undefined reference to `__ctype_toupper'
/gnome/lib/libxklavier.so: undefined reference to `__ctype_tolower'
ldd says this library depends on libc.so.6, and nm says these symbols
are there in libc.so.6 (libc-2.3.2.so). What can I do so they'll
be found? Could it have something to do with my locale (en_US.UTF-8)?
The symbols are defined in xlocale.h.
--
Greg Lee <gr...@ling.lll.hawaii.edu>
Paul Pluzhnikov
> /gnome/lib/libxklavier.so: undefined reference to `__ctype_b'
>
> ldd says this library depends on libc.so.6, and nm says these symbols
> are there in libc.so.6 (libc-2.3.2.so).
What's happening here is that the libxklavier.so was built against
older glibc. The version libc-2.3.2.so does define __ctype_b,
but it is defined as a "hidden" symbol:
objdump --dynamic-syms /lib/libc.so.6 | grep '__ctype_b$'
00137518 g DO .data 00000004 (GLIBC_2.0) __ctype_b
[The hiddennes is indicated by parenthesis around GLIBC-2.0].
This means that old binaries will still be able to use __ctype_b
(at runtime), but the linker will not consider that symbol during
the linking process, which is why your link fails.
> What can I do so they'll be found?
The best thing to do is rebuild libxklavier.so (which will eliminate
its dependency on the obsolete/hidden symbols). Another option is
to build on a glibc-2.2-based machine.
If you can't do that, perhaps there is an 'ld' flag that will allow
you to bind to "hidden" symbols (I didn't find one).
If you are desperate, one other workaround is to build an
"interposer" library that provides missing symbols, and forwards
them to the "real" ones.
> Could it have something to do with my locale (en_US.UTF-8)?
No, this has nothing to do with your locale.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
Greg Lee
> Greg Lee <gr...@ling.lll.hawaii.edu> writes:
>
>
>>/gnome/lib/libxklavier.so: undefined reference to `__ctype_b'
>>
>>What can I do so they'll be found?
>
>
> The best thing to do is rebuild libxklavier.so (which will eliminate
But I just did build it. Then, when I noticed the problem, I rebuilt
it. Same thing.
> Another option is
> to build on a glibc-2.2-based machine.
>
> If you can't do that, perhaps there is an 'ld' flag that will allow
> you to bind to "hidden" symbols (I didn't find one).
I'll look.
> If you are desperate, one other workaround is to build an
> "interposer" library that provides missing symbols, and forwards
> them to the "real" ones.
I'm not that desperate. I'm building gnome, and for now, I've just
disabled the parts that need libxklavier.
>
>
>>Could it have something to do with my locale (en_US.UTF-8)?
>
>
> No, this has nothing to do with your locale.
If you say so. But it is just these 3 symbols that are defined in
xlocale.h.
Thanks a lot.
Greg
Paul Pluzhnikov
> Paul Pluzhnikov wrote:
> > The best thing to do is rebuild libxklavier.so (which will eliminate
> > its dependency on the obsolete/hidden symbols) ...
>
> But I just did build it. Then, when I noticed the problem, I rebuilt
> it. Same thing.
That is *very* strange (and unexpected).
You don't have multiple versions of glibc installed, do you?
Here is a little test program:
#include <ctype.h>
int main() { return isupper('A') ? 0 : 1; }
When compiled and linked on a glibc-2.2 system:
$ gcc junk.c && nm a.out | grep __ctype
08049558 B __ctype_b@@GLIBC_2.0
On a glibc-2.3.x:
U __ctype_b_loc@@GLIBC_2.3
What do you get from this test case on your machine?
> >>Could it have something to do with my locale (en_US.UTF-8)?
> > No, this has nothing to do with your locale.
>
> If you say so. But it is just these 3 symbols that are defined in
> xlocale.h.
If your xlocale.h looks anything like mine, they are *not* defined
in there (though their names do appear there as part of __locale_t).
Greg Lee
> Greg Lee <gr...@ling.lll.hawaii.edu> writes:
>
>
>>Paul Pluzhnikov wrote:
>>
>>>The best thing to do is rebuild libxklavier.so (which will eliminate
>>>its dependency on the obsolete/hidden symbols) ...
>>
>>But I just did build it. Then, when I noticed the problem, I rebuilt
>>it. Same thing.
>
>
> That is *very* strange (and unexpected).
> You don't have multiple versions of glibc installed, do you?
Yes, I do. 2.2.3 and 2.3.2.
>
> Here is a little test program:
>
> #include <ctype.h>
> int main() { return isupper('A') ? 0 : 1; }
>
> When compiled and linked on a glibc-2.2 system:
>
> $ gcc junk.c && nm a.out | grep __ctype
> 08049558 B __ctype_b@@GLIBC_2.0
>
> On a glibc-2.3.x:
> U __ctype_b_loc@@GLIBC_2.3
>
> What do you get from this test case on your machine?
The second: U __ctype_b_loc@@GLIBC_2.3
Greg
Paul Pluzhnikov
> > What do you get from this test case on your machine?
> The second: U __ctype_b_loc@@GLIBC_2.3
Somehow, when you build libxklavier.so, it finds glibc-2.2 headers
and libc.so, which is what causes you grief later.
If you examine its build commands and build the test case with the
same flags, you'll probably end up with __ctype_b@@GLIBC_2.0
dependency. After that it's a simple matter to figure out which
flags cause that, and rebuild libxklavier without them.
Greg Lee
> Greg Lee <gr...@ling.lll.hawaii.edu> writes:
>
>
>>>What do you get from this test case on your machine?
>>
>>The second: U __ctype_b_loc@@GLIBC_2.3
>
>
> Somehow, when you build libxklavier.so, it finds glibc-2.2 headers
> and libc.so, which is what causes you grief later.
>
> If you examine its build commands and build the test case with the
> same flags, you'll probably end up with __ctype_b@@GLIBC_2.0
> dependency. After that it's a simple matter to figure out which
> flags cause that, and rebuild libxklavier without them.
The source and header files for libxklavier have no references to
"ctype", and the object files have no reference to "__ctype". But
the .so file is built by linking with libxkbfile.a from XFree86 4.3.0,
which does have references:
U __ctype_b
U __ctype_toupper
So I guess that's where they come from. I didn't build X. It may
well be a glibc-2.2 version.
Greg
Greg Lee
> the .so file is built by linking with libxkbfile.a from XFree86 4.3.0,
> which does have references:
> U __ctype_b
> U __ctype_toupper
>
> So I guess that's where they come from. I didn't build X. It may
> well be a glibc-2.2 version.
Ok, it's fixed now. Thanks again for your help. I installed a
glibc-2.3 version of X, rebuilt libxklavier, and now I can link
against it.
Greg