Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libfakeXinerama.so.1 cannot be loaded #798

Closed
totaam opened this issue Jan 28, 2015 · 16 comments
Closed

libfakeXinerama.so.1 cannot be loaded #798

totaam opened this issue Jan 28, 2015 · 16 comments

Comments

@totaam
Copy link
Collaborator

totaam commented Jan 28, 2015

Issue migrated from trac ticket # 798

component: core | priority: minor | resolution: needinfo

2015-01-28 00:24:01: lukashaase created the issue


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.

@totaam
Copy link
Collaborator Author

totaam commented Jan 28, 2015

2015-01-28 00:26:01: lukashaase commented


Sorry, I hit "Submit" too early.

$ xpra --version
xpra v0.14.18

on CentOS 6. The file exists.

@totaam
Copy link
Collaborator Author

totaam commented Jan 28, 2015

2015-01-28 02:01:03: totaam changed owner from antoine to lukashaase

@totaam
Copy link
Collaborator Author

totaam commented Jan 28, 2015

2015-01-28 02:01:03: totaam edited the issue description

@totaam
Copy link
Collaborator Author

totaam commented Jan 28, 2015

2015-01-28 02:01:03: totaam commented


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?

@totaam
Copy link
Collaborator Author

totaam commented Jan 28, 2015

2015-01-28 02:40:07: lukashaase commented


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.

@totaam
Copy link
Collaborator Author

totaam commented Jan 28, 2015

2015-01-28 03:55:13: totaam commented


Can it have something to do with --start-child?
[[BR]]
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: 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*

@totaam
Copy link
Collaborator Author

totaam commented Jan 28, 2015

2015-01-28 16:58:24: lukashaase commented


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

@totaam
Copy link
Collaborator Author

totaam commented Jan 28, 2015

2015-01-28 17:02:32: totaam commented


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

@totaam
Copy link
Collaborator Author

totaam commented Jan 28, 2015

2015-01-28 17:17:43: lukashaase commented


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.

@totaam
Copy link
Collaborator Author

totaam commented Jan 28, 2015

2015-01-28 17:20:54: totaam commented


Try this:

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

@totaam
Copy link
Collaborator Author

totaam commented Jan 28, 2015

2015-01-28 17:37:50: lukashaase commented


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.

@totaam
Copy link
Collaborator Author

totaam commented Feb 13, 2015

2015-02-13 04:51:15: totaam commented


Can we close this ticket?

@totaam
Copy link
Collaborator Author

totaam commented Feb 18, 2015

2015-02-18 06:18:16: lukashaase commented


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

@totaam
Copy link
Collaborator Author

totaam commented Feb 18, 2015

2015-02-18 08:42:11: antoine changed status from new to closed

@totaam
Copy link
Collaborator Author

totaam commented Feb 18, 2015

2015-02-18 08:42:11: antoine set resolution to needinfo

@totaam
Copy link
Collaborator Author

totaam commented Feb 18, 2015

2015-02-18 08:42:11: antoine commented


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

@totaam totaam closed this as completed Feb 18, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant