libfakeXinerama.so.1 cannot be loaded

[Lukas Haase]

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.

[Lukas Haase]

Sorry, I hit "Submit" too early.

$ xpra --version
xpra v0.14.18

on CentOS 6. The file exists.

[Antoine Martin]

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?

[Lukas Haase]

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.

[Antoine Martin]

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*

[Lukas Haase]

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 ...

[Antoine Martin]

You will only see this message if the application does make use of the xinerama extension, most applications do not, xterm does not.

[Lukas Haase]

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.

[Antoine Martin]

Try this:

ldd /usr/bin/* | egrep "/usr/bin|Xinerama" | grep -B 1 Xinerama

[Lukas Haase]

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.

[Antoine Martin]

Can we close this ticket?

[Lukas Haase]

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 :)

[Antoine Martin]

Closing as needinfo because I don't understand why gedit can't preload fake xinerama..

[migration script]

this ticket has been moved to: ​https://github.com/Xpra-org/xpra/issues/798