Hide Forgot
Description of problem: The composite libraries that nx are linked are in a non-standard and non-resolvable location. This breaks prelink, as well as breaking calling the agents directly instead of through wrapper scripts. Version-Release number of selected component (if applicable): 3.3.0-38 (latest for F14 at time of post) Steps to Reproduce: yum install nx 1: ldd /usr/libexec/nx/nxagent | grep 'not found' 2: prelink -am Actual results: 1: libXcomp.so.3 => not found libXcompext.so.3 => not found libXcompshad.so.3 => not found 2: prelink: /usr/libexec/nx/nxagent: Could not find one of the dependencies prelink: /usr/libexec/nx/nxproxy: Could not find one of the dependencies prelink: /usr/libexec/nx/nxssh: Could not find one of the dependencies Expected results: (nothing listed) Further info: This can be worked around (for prelink only) by: echo "-b /usr/libexec/nx" >/etc/prelink.conf.d/nx.conf Due to the overlapping library names, it's not easily fixed for ldconfig. Better would be if nx were explicitly relinked with -rpath against the long (versioned) DSO names, and the short version copies removed from /usr/lib{,64}/nx/. That would solve both issues. (It would also remove the bloat of the /usr/lib{,64}/nx/lib* DSOs existing as two copies, instead of a copy and a symlink which is the normal approach when linking against the short names. For libXrender, there's even two differing DSOs provided, which surely must be unintentional.)
Unfortunately the extra X bits supplied are an upstream issue. They ship some modified X libs they need to link against. Ideally their patches would make it into an official X tree and the extra baggage could be dropped. So we cannot remove them, but also cannot put them into ldconfig's default path, which is why the situation is as it is currently. :( Thanks for the prelink fix! At least this eases off the pain a bit. It doesn't warrent a rebuild by itself, but it should be introduced with the next package update. If you have any other ideas on the issue please share. Note that rpaths are much disliked in Fedora packaging, but OTOH the packaging commitee is open to solid arguments, and maybe with nx there is a case for sane rpath usage.
Using rpath would be fine in this case in my opinion, no need to ask anyone: http://fedoraproject.org/wiki/Packaging/Guidelines#Rpath_for_Internal_Libraries Sprinkling some -Wl,-rpath,%{_pkglibdir}s to CFLAGS here and there (and to LDFLAGS for nxssh) results in the executables getting the correct RPATHs, but some RPATHs would also be needed in some of the shipped shared libs for prelinking to actually work; the above didn't accomplish that, so I did the blacklisting in 3.5.0-2 (rawhide only for now, building as I write this). 3.5.0-2 also gets rid of the duplicate shared lib copies and uses symlinks instead.
nx-3.5.0-4.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/nx-3.5.0-4.fc16
Package nx-3.5.0-4.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing nx-3.5.0-4.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/nx-3.5.0-4.fc16 then log in and leave karma (feedback).
nx-3.5.0-5.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/nx-3.5.0-5.fc16
nx-3.5.0-5.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.