When starting some applications, I get in the console window:
ERROR: ld.so: object '/usr/lib64/libfakeXinerama.so.1' from LD_PRELOAD cannot be preloaded: ignored.
On a first sight, everything still works.
Sorry, I hit "Submit" too early.
$ xpra --version xpra v0.14.18
on CentOS 6. The file exists.
Odd, can you post ls -laZ '/usr/lib64/libfakeXinerama.so*'
?
Maybe it's an SELinux context issue? You could try a restorecon '/usr/lib64/libfakeXinerama.so.1'
.
Could also be a 32-bit vs 64-bit issue if you try to run 32-bit binaries. Is this for all applications or just some?
You probably mean ls without using the quotes:
$ ls -laZ /usr/lib64/libfakeXinerama.so* lrwxrwxrwx. root root system_u:object_r:lib_t:s0 /usr/lib64/libfakeXinerama.so.1 -> libfakeXinerama.so.1.0 -rwxr-xr-x. root root system_u:object_r:lib_t:s0 /usr/lib64/libfakeXinerama.so.1.0
After using restorecon, it's the same.
Sounds more like a 32/64 bit issue.
BUT: Can it have something to do with --start-child? When I use --start-child/--exit-with-children, the problem appears. When I manually start the program, not.
Can it have something to do with --start-child?
start-child
will setup the LD_PRELOAD
environment variable so that the children started from there will get the fake xinerama info we want them to use.
That's equivalent to running:
LD_PRELOAD=$LD_PRELOAD:/usr/lib64/libfakeXinerama.so.1.0 yourchild
More info here: wiki/FakeXinerama.
Which exact version of centos are you running? And which repository are you using? Maybe there's a mismatch preventing the library from loading, see the output of:
ldd /usr/lib64/libfakeXinerama.so*
Thanks, this explains a bit to me: Usually, I just started the server and used
$ setenv DISPLAY :1900 $ myapplication
i.e., I did not use Xinerama.
I am running CentOS6.6. I am using the standard stable repository (url=http://winswitch.org/dists/CentOS/$releasever/$basearch/)
$ ldd /usr/lib64/libfakeXinerama.so* /usr/lib64/libfakeXinerama.so.1: linux-vdso.so.1 => (0x00007fffaf7ff000) libc.so.6 => /lib64/libc.so.6 (0x00007f1f3d0ad000) /lib64/ld-linux-x86-64.so.2 (0x0000003b9de00000) /usr/lib64/libfakeXinerama.so.1.0: linux-vdso.so.1 => (0x00007fff447ff000) libc.so.6 => /lib64/libc.so.6 (0x00007f3ffc567000) /lib64/ld-linux-x86-64.so.2 (0x0000003b9de00000)
I do not see these messages with all applications. E.g., if I start xterm with LD_PRELOAD set, I get no error.
Is there an environment variable with which I can check if xinerama is successfully loaded? E.g. in my application I can read out environment variables ...
You will only see this message if the application does make use of the xinerama extension, most applications do not, xterm does not.
Ok, do you know of any typical application (potentially included in CentOS) that makes use of Xinerama?
I have tried Firefox, gnome-terminal (and other different gnome- applications) and the error never appears.
Try this:
ldd /usr/bin/* | egrep "/usr/bin|Xinerama" | grep -B 1 Xinerama
Hmm, this is weird. gedit seems to use it:
$ ldd /usr/bin/gedit | grep -i xinerama libXinerama.so.1 => /usr/lib64/libXinerama.so.1 (0x0000003ba5a00000)
I start gedit, no error. Then I set LD_PRELOAD:
$ setenv LD_PRELOAD /usr/lib64/libfakeXinerama.so.1 $ ldd /usr/bin/gedit | grep -i xinerama /usr/lib64/libfakeXinerama.so.1 (0x00007f255a3ba000) libXinerama.so.1 => /usr/lib64/libXinerama.so.1 (0x0000003ba5a00000)
I start gedit, still no error.
Can we close this ticket?
Well, problem is still there but so far I happily ignore it. We can close it for now and I may re-open when I face problems :)
Closing as needinfo because I don't understand why gedit can't preload fake xinerama..
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/798