Hi,
I still have the problem that after upgrading my SLES from 11SP3 to 12SP1 most X11 command result in a symbol lookup error: /usr/lib64/libX11.so.6: undefined symbol: xcb_take_socket
I studied the problem at my best and now I’m quite sure that it there must be a bug (at least) in the upgrade procedure
I’d like to open a bug but I’m not entitled since I only pay for using SLES, not for having any support.
Here it follows why I’m sure there is a bug:
[LIST=1]
[*]yast2 sw_single often complains that “xxxx requires libxcb-xlib.so.0()(64bit), but this requirement cannot be provided” BUT the lib is in its place
cd /usr/lib64
ls -ls libxcb-xlib*
0 lrwxrwxrwx 1 root root 20 Mar 2 2014 libxcb-xlib.so.0 -> libxcb-xlib.so.0.0.0*
8 -rwxr-xr-x 1 root root 6248 May 24 2013 libxcb-xlib.so.0.0.0*
[*]/usr/lib64/libxcb.so is faulty link to a non-existing libxcb.so.1.1.0
cd /usr/lib64
ls -ls libxcb.so*
0 lrwxrwxrwx 1 root root 15 Aug 11 13:51 libxcb.so -> libxcb.so.1.1.0
0 lrwxrwxrwx 1 root root 15 Mar 2 2014 libxcb.so.1 -> libxcb.so.1.0.0
116 -rwxr-xr-x 1 root root 113536 May 24 2013 libxcb.so.1.0.0
I manually changed the link of libxcb.so so that it now points to libxcb.so.1.0.0 instead of libxcb.so.1.1.0
But such change doesn’t help in my problem!
[*] /usr/lib64/libX11.so.6.2.0 calls xcb_take_socket which is NOWHERE defined!!
cd /usr/lib64
for i in `ls *.so`; do echo $i ;nm -D $i|grep "T xcb_take_socket" ;done
[/LIST]
Of course I’d really apreciate any help.
Thanks,
Emanuele
It appears that in the past few days you have not received a response to your
posting. That concerns us, and has triggered this automated reply.
These forums are peer-to-peer, best effort, volunteer run and that if your issue
is urgent or not getting a response, you might try one of the following options:
Visit http://www.suse.com/support and search the knowledgebase and/or check all
the other support options available.
If this is a reply to a duplicate posting or otherwise posted in error, please
ignore and accept our apologies and rest assured we will issue a stern reprimand
to our posting bot…
soon after the upgrade in /usr/lib64 there was a problem:
libxcb.so pointed to a missing .so
cd /usr/lib64
ls -ls libxcb.so*
0 lrwxrwxrwx 1 root root 15 Aug 11 13:51 libxcb.so → libxcb.so.1.1.0
0 lrwxrwxrwx 1 root root 15 Mar 2 2014 libxcb.so.1 → libxcb.so.1.0.0
116 -rwxr-xr-x 1 root root 113536 May 24 2013 libxcb.so.1.0.0
The file /usr/lib64/libxcb.so.1.1.0 was missing, being present only its previous version libxcb.so.1.0.0
I found out that in the SLES12SP1 DVD1 there is a rpm named libxcb1-1.10-1.21.x86_64.rpm which contains the version 1.1.0 of libxcb.
Such rpm was not installed during the upgrade process (I don’t know why) and when I had a look into it I found there the missing
xcb_take_socket
although you seem to run fine, there are two things that catch the eye:
since in /usr/lib64 there was not any libxcb.so.1.1.0 I copied there the one in ./usr/lib/
this usually means you copied a 32bit version (stored in /usr/lib) to the place where the system is looking for 64bit versions (/usr/lib64). You better double-check that the libs’ architecture is right in both locations (i.e using the “file” command, which should report “ELF 32-bit LSB shared object” for files in /usr/lib and “ELF 64-bit LSB shared object” for files in /usr/lib64).
I found out that in the SLES12SP1 DVD1 there is a rpm named libxcb1-1.10-1.21.x86_64.rpm
[…]
since in /usr/lib64 there was not any libxcb.so.1.1.0 I copied there the one in ./usr/lib/
In /usr/lib64 I then modified the links libxcb.so and libxcb.so.1 to point to the new libxcb.so.1.1.0
was there any reason you didn’t just install the RPM, which should have installed the (64 bit) lib and created the symlinks? That way you’d also catch any future updates to that package.