xpra icon
Bug tracker and wiki

Opened 5 years ago

Closed 5 years ago

#798 closed defect (needinfo)

libfakeXinerama.so.1 cannot be loaded

Reported by: Lukas Haase Owned by: Lukas Haase
Priority: minor Milestone: 0.14
Component: core Version: trunk
Keywords: Cc:

Description (last modified by Antoine Martin)

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.

Change History (12)

comment:1 Changed 5 years ago by Lukas Haase

Sorry, I hit "Submit" too early.

$ xpra --version
xpra v0.14.18

on CentOS 6. The file exists.

Last edited 5 years ago by Antoine Martin (previous) (diff)

comment:2 Changed 5 years ago by Antoine Martin

Description: modified (diff)
Milestone: 0.14
Owner: changed from Antoine Martin to Lukas Haase

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?

comment:3 Changed 5 years ago by 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.

comment:4 Changed 5 years ago by 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*

comment:5 Changed 5 years ago by 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 ...

comment:6 Changed 5 years ago by 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.

comment:7 Changed 5 years ago by 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.

comment:8 Changed 5 years ago by Antoine Martin

Try this:

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

comment:9 Changed 5 years ago by 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.

comment:10 Changed 5 years ago by Antoine Martin

Can we close this ticket?

comment:11 Changed 5 years ago by 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 :)

comment:12 Changed 5 years ago by Antoine Martin

Resolution: needinfo
Status: newclosed

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

Note: See TracTickets for help on using tickets.