Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Incoming connections from any nx client fail because /usr/libexec/nx/nxnode cannot find libXcomp.so.3 Version-Release number of selected component (if applicable): nx-3.2.0-27.fc9.i386 freenx-server-0.7.2-8.fc9.x86_64 How reproducible: Every time until configuration modified. Steps to Reproduce: 1. Install latest nx and freenx-server 2. Connect from another machine via nx 3. Connection error occurs Actual results: NX> 105 /usr/libexec/nx/nxagent: error while loading shared libraries: libXcomp.so.3: cannot open shared object file: No such file or directory NX> 1006 Session status: closed server_nxnode_echo: NX> 596 Session startup failed Expected results: A working nx connection. Additional info: Looking at the nx package, /usr/lib/nx contains that packages shared libraries. However, /usr/lib/nx is not in the ld.so path, so there needs to be a /usr/ld/so/conf.d/nx-i386.conf file containing /usr/lib/nx However, the shared libraries in /usr/lib/nx are not of the form library.so.major.minor with a symbolic link pointing library.so.major at this file, the major versions are simply copies of the major.minor versions so that running /sbin/ldconfig produces an error complaining that the major version files are not symbolic links. The package needs to be rebuilt to remove these files, substitute links for the major version library files, and add in an /etc/ld.so.conf.d/nx-i386.conf file containing /usr/lib/nx, with a post install script to force /sbin/ldconfig to run.
All the libraries are invoked by setting LD_LIBRARY_PATH in a wrapper to the libexec bits. I'm not sure why it doesn't work for you, it probably means that you are invoking the libexec bits directly. The package used to publish its libraries to ldconfig, but it was considered a pollution of xorg space (as it did indeed share the same SONAMEs), so it had to be redesigned to leave ldconfig and rpm out.
Well, I don't really see how I can invoke the libexec bits directly, I'm simply logging in externally with the Windows NX client. Oddly v3.1.0 of that didn't work either, but v3.2.0 does work fine. How would you suggest I debug this further? I have had one other problem with the system since updating to F9, maybe there is something wrong somewhere. Certainly with the default configuration of having installed the packages and left the /etc/nxserver directory keys alone it didn't work (whereas in F7 is did), I don't see how it can do other than what was intended.
OK, just to make sure you're clear on what I'm doing. The remote machine (running Fedora 9) is acting as an NX server, I won't claim to be knowledgeable about NX in general. I can see that there is an additional library path set in /usr/libexec/nx/nxwrapper, but I don't see how this gets called when I connect with my NX client remotely. My logs have showed problems with /usr/libexec/nx/nxnode and with /usr/libexec/nx/nxagent, both complaining about the inability to find shared libraries such as liXcomp.so.3, so my changes made this work. How is nxwrapper involved in this process? I can see that it should be called and then pass execution to the correct script with the LD_LIBRARY_PATH set with /usr/lib/nx added to the path, but it seems this does not happen. Any assistance with changing the configuration to make it work how you intended would be appreciated.
Further tests reveal that the problem appears to be due to a mismatch between the nx and freenx-server package archs, I had nx.i386 and freenx-server.x86_64 as this is what anaconda installed during my F7->F9 upgrade. The version of freenx-server is the one available in updates. Manually finding freenx-server.i386 (again from updates) and installing it in place of the x86_64 version (there is no nx.x86.64 in any of the repos) and manually undoing my changes to /usr/lib/nx and /etc/ld.so.conf.d/ has given me a working setup with the installation defaults. Might be worth finding out why the repos insist on presenting a broken combination of packages.....
I'm making this a duplicate of bug #446816, but that doesn't address the issue with anaconda installing a wrong set of packages. If you'd like to see that addressed, please open a bug against anaconda with this info, thanks! As to the missing nx x86_64 build: The current workaround is to remove the x86_64 freenx-server build as well and have x86_64 use the i386 builds. See also bug #446816. *** This bug has been marked as a duplicate of 446816 ***