#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 )
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 (13)
comment:2 Changed 6 years ago by
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 6 years ago by
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 6 years ago by
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 6 years ago by
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 6 years ago by
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 6 years ago by
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 6 years ago by
Try this:
ldd /usr/bin/* | egrep "/usr/bin|Xinerama" | grep -B 1 Xinerama
comment:9 Changed 6 years ago by
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:11 Changed 6 years ago by
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 6 years ago by
Resolution: | → needinfo |
---|---|
Status: | new → closed |
Closing as needinfo because I don't understand why gedit can't preload fake xinerama..
comment:13 Changed 3 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/798
Sorry, I hit "Submit" too early.
on CentOS 6. The file exists.