Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 452518 - Incoming nx connections fail due to nx package shared library path problem
Summary: Incoming nx connections fail due to nx package shared library path problem
Keywords:
Status: CLOSED DUPLICATE of bug 446816
Alias: None
Product: Fedora
Classification: Fedora
Component: nx
Version: 9
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Axel Thimm
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-06-23 14:41 UTC by Brian Morrison
Modified: 2008-07-02 18:27 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-07-02 18:27:09 UTC


Attachments (Terms of Use)

Description Brian Morrison 2008-06-23 14:41:30 UTC
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.

Comment 1 Axel Thimm 2008-06-23 15:10:07 UTC
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.



Comment 2 Brian Morrison 2008-06-23 15:21:47 UTC
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.


Comment 3 Brian Morrison 2008-06-23 15:51:05 UTC
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.


Comment 4 Brian Morrison 2008-06-25 13:05:32 UTC
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.....


Comment 5 Axel Thimm 2008-07-02 18:27:09 UTC
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 ***


Note You need to log in before you can comment on or make changes to this bug.