version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
Rob Gom
I have updated my PC from i686 to Intel Quad. Therefore I switched to
64 bit kernel. In the meantime I upgraded my libc from 2.7-something
to 2.9-23.
After that smb:// protocol no longer works in KDE3 (yes, I have
decided to stay with that version - it's fine for my purposes). Log
message is:
Could not open library '/usr/lib/kde3/kio_smb.la'.
/lib/i686/cmov/libnsl.so.1: symbol __libc_clntudp_bufcreate, version
GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
What can I do with that? Does it seem to be a KDE3 bug or libc6 bug?
I searched google but with no useful results.
System: mainly SID (mixed with stable & others)
Kernel: 2.6.30-amd64
Regards,
Robert
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Sven Joachim
> I have updated my PC from i686 to Intel Quad. Therefore I switched to
> 64 bit kernel. In the meantime I upgraded my libc from 2.7-something
> to 2.9-23.
> After that smb:// protocol no longer works in KDE3 (yes, I have
> decided to stay with that version - it's fine for my purposes). Log
> message is:
> Could not open library '/usr/lib/kde3/kio_smb.la'.
> /lib/i686/cmov/libnsl.so.1: symbol __libc_clntudp_bufcreate, version
> GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
That does not seem to happen for me:
,----
| % objdump -T /lib/i686/cmov/libc.so.6 | grep __libc_clntudp_bufcreate
| 0010ad30 g DF .text 00000399 GLIBC_PRIVATE __libc_clntudp_bufcreate
`----
> What can I do with that? Does it seem to be a KDE3 bug or libc6 bug?
Possibly you have a private copy of libc.so.6 somewhere. What does
"ldd /lib/i686/cmov/libnsl.so.1" print?
Sven
Rob Gom
[cut]
>
> That does not seem to happen for me:
>
> ,----
> | % objdump -T /lib/i686/cmov/libc.so.6 | grep __libc_clntudp_bufcreate
> | 0010ad30 g DF .text 00000399 GLIBC_PRIVATE __libc_clntudp_bufcreate
> `----
>
>> What can I do with that? Does it seem to be a KDE3 bug or libc6 bug?
>
> Possibly you have a private copy of libc.so.6 somewhere. What does
> "ldd /lib/i686/cmov/libnsl.so.1" print?
>
> Sven
>
It seems that objdump reveals the same information as yours:
~/scripts/linux$ objdump -T /lib/i686/cmov/libc.so.6 | grep
__libc_clntudp_bufcreate
0010ad30 g DF .text 00000399 GLIBC_PRIVATE __libc_clntudp_bufcreate
ldd:
~/scripts/linux$ ldd /lib/i686/cmov/libnsl.so.1
linux-gate.so.1 => (0xf7f72000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xf7de0000)
/lib/ld-linux.so.2 (0xf7f73000)
Maybe the error message is misleading?
I can't think of any private copy of libc.so.6...
I tried to uninstall libc6-i686 - didn't help.
Any suggestions will be appreciated, as the only solution for
accessing smb is currently smbc, which is much less convenient than
kde tools.
Regards,
Robert
Rob Gom
version to /lib/i686/cmov/) and modified symbolic links libnsl.so.1.
And smb access started working again ...
Shall I report a bug against libc6?
Rob Gom
> I workarounded that by copying old libnsl-2.7.so to /lib (and second
> version to /lib/i686/cmov/) and modified symbolic links libnsl.so.1.
> And smb access started working again ...
> Shall I report a bug against libc6?
>
> Regards,
> Robert
>
I did further research using nm. That's the beginning of the
differences (2.7 vs 2.9).
8c8
< 0000b350 T __create_ib_request
---
> 0000b330 T __create_ib_request
12c12
< 0000a930 T __do_niscall3
---
> 0000a920 T __do_niscall3
14c14
< 0000b1c0 T __follow_path
---
> 0000b1a0 T __follow_path
18,24c18,25
< 0000fe70 T __nis_default_access
< 00010250 T __nis_default_group
< 00010320 T __nis_default_owner
< 000100c0 T __nis_default_ttl
< 0000e680 T __nis_finddirectory
< 0000e550 T __nis_hash
< 0000a470 T __nisbind_connect
---
> U __libc_clntudp_bufcreate
> 0000fdf0 T __nis_default_access
> 000101c0 T __nis_default_group
> 00010290 T __nis_default_owner
> 00010030 T __nis_default_ttl
> 0000e620 T __nis_finddirectory
> 0000e510 T __nis_hash
> 0000a460 T __nisbind_connect
29c30
< 0000aa80 T __prepare_niscall
---
> 0000aa60 T __prepare_niscall
As one can see, __libc_clntudp_bufcreate is new in 2.9 and is undefined.
As I'm not familiar with the nm tool, I don't know how to proceed.
Sven Joachim
Not here:
,----
| % nm -D /lib/i686/cmov/libc-2.9.so | grep __libc_clntudp_bufcreate
| 0010ad30 T __libc_clntudp_bufcreate
`----
Google found the following bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=458825
Reading Jakub Jelinek's last comment there, you may have to restart some
service (don't know which one that would be for SMB access).
Sven
Rob Gom
I compared libnsl versions, not libc.
I _guess_ that some lib is linked against libnsl, but not libc6 (is
that possible?). Then on older versions, it would work fine. On new,
it would try to load libnsl and fail because on new referred symbol
present in libc6.
What else may that be?
I restarted whole system, so it doesn't appear to be a question of
restarting a service.
It is somehow tied to krusader starting (well, I forgot to check smb:/
in konqueror). If I change libs and restart krusader, it is fine. On
the other hand I searched libs in /lib, /usr/lib, /usr/lib/kde3 and
those got from stracing krusader. Some of them were linked against
libnsl, but all of them were also linked against libc6... But I don't
know a way of recursive linkage checking (when a is linked against b,
which is linked against c....)
Regards,
Robert
Sven Joachim
> [cut]
> I compared libnsl versions, not libc.
I see, I had misunderstood you. Yes, nm lists __libc_clntudp_bufcreate
as undefined in libnsl.
> I _guess_ that some lib is linked against libnsl, but not libc6 (is
> that possible?).
Theoretically it may be possible, but I would be very surprised to see
such a beast in practice.
> Then on older versions, it would work fine. On new,
> it would try to load libnsl and fail because on new referred symbol
> present in libc6.
> What else may that be?
I don't have a clue, but I think it is time for you to file a bug report
against libc6. You can also try to remove libc6-i686 and see whether
that makes a difference (it should not, but just to be sure).
Sven