Summary: | net-misc/nxclient configuration can break almost every X11 application when nx-x11 is improperly upgraded. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Daniel Holth <dholth> |
Component: | Current packages | Assignee: | Gentoo NX Server project <nx> |
Status: | RESOLVED TEST-REQUEST | ||
Severity: | critical | CC: | gentoo, jasmin-genbug, tschenturs, ufechner, vapier |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 82330 | ||
Attachments: | xorg env.d file |
Description
Daniel Holth
2005-01-01 16:48:58 UTC
*** This bug has been marked as a duplicate of 44028 *** This is not a sorting problem. This is an issue where the Xorg X11 libraries (in /usr/lib) are not mentioned at all, and so are implied as coming after, all the entries including /usr/NX/lib in ld.so.conf Removing /usr/NX/lib from ld.so.conf fixes this perfectly, and NX still functions. Hrm. My Gentoo system has the Xorg libraries in /usr/X11R6/lib, not /usr/lib, *and* they are correctly listed first in /etc/ld.so.conf. Please paste the contents of /etc/env.d/10xorg. Best regards, Stu Created attachment 47384 [details]
xorg env.d file
I'm using xorg-x11 version 6.8.0-r4. For some reason this version of xorg-x11
installs all its libraries in /usr/lib and symlinks /usr/X11R6/lib to /usr/lib.
No LDPATH in env.d
Putting /usr/NX/lib in ld.so.conf breaks things. Does it fix anything? A better solution would be to twiddle some elf option in the nx binaries so that only those specific binaries look for /usr/NX/lib first. The nxserver components set LD_LIBRARY_PATH appropriately so they still work with no /usr/NX/lib in the search path. It's brain damaged to have a binary that really needs NX libraries linking partially with standard X11 libs. Example: nxviewer dholth@bluefish /usr/NX/bin $ export LD_LIBRARY_PATH=/usr/lib:/usr/NX/lib dholth@bluefish /usr/NX/bin $ ./nxviewer ./nxviewer: symbol lookup error: /usr/NX/lib/libXcompext.so.1: undefined symbol: _NXEnableCleanGet dholth@bluefish /usr/NX/bin $ export LD_LIBRARY_PATH=/usr/NX/lib:/usr/lib dholth@bluefish /usr/NX/bin $ ./nxviewer NXTightVNC viewer version 1.2.4 (based on VNC 3.3.3r2) The NX binaries should be linked with the option -R/usr/NX/lib so that they search for shared libraries in that directory. That way NX programs link with NX libraries, regular programs link with standard libraries, and no ld.so.conf madness is necessary. How do you propose we add the -R option to the binaries that we don't have source code for? :) If there's something that can be done, I'm happy to do it. I'll have a chat with the maintainer of xorg-x11-6.8.0-r4, and find out more about the changes there. Best regards, Stu Stuart and I have discussed a fix, adding LDPATH="/usr/lib" to /etc/env.d/10xorg. Can anyone confirm that this in fact fixes the problem by making that addition, then running env-update and trying some nx app? Reassigning to us until this gets fixed, because we need to do it. X11 libs in /usr/lib with a symlink from /usr/X11R6/lib to /usr/lib is naughty and so is having to include /usr/lib in LDPATH (it is in there by default, but after manually specified directories). If xorg must provide LDPATH, set it to /usr/X11R6/lib/ ; this way, the LDPATH workaround will still work when xorg becomes sane and re-segregates its libraries. X is moving _toward_ sanity. You'll see /usr/X11R6/lib disappearing over time, along with everything else in the /usr/X11R6 monstrosity that exists for no good reason. (Is there /usr/gnome? /usr/xfce? /usr/kde? ... I could go on forever.) If you want to complain about something broken, complain about how nomachine provides its own copy of libX11, which breaks other apps, instead of a real lib that doesn't conflict with one that X has provided for ages. Incidentally, I'd enjoy a report of whether this works in addition to your opinion. sorry not to mention it before, it's old news to me that putting wherever the X11 libs are BEFORE wherever the NX libs are in the library path does work. I am very pleased that there is a separate directory for each version of KDE. It makes it very easy to answer the question "which kde programs do I have?". Unlike NX, the KDE folks are kind enough to understand linker options so their programs will work without ld.so.conf entries. Most of the NX programs work without an entry in ld.so.conf and that is my solution right now. My long term solution for open source NX is to fix the linker option so that their library search path is built in to the binaries. Summary: xorg used to put /usr/X11R6/lib before NX libraries. Then xorg changed, not mentioning its libraries at all. If it puts /usr/lib before NX's listing, things will work. But ld.so.conf is evil. The really non-intrusive, best solution is to replace all the NX binaries with wrapper scripts that say approximately: #!/bin/sh LDPATH=/usr/NX/lib:$LDPATH /usr/NX/bin/nx-binary-program a la mozilla. and to ban NX's ld.so.conf entry, and omit xorg's as well. Added this to 6.8.1.902 yesterday, plan to add to 6.8.0-r4 today. Maybe a fancier solution can come later. Added to 6.8.0-r4, fixed in 6.8.1.902. Reassigning to Stuart, removing X11 because our part is done for now. If another working solution gets decided upon that requires action on our part, just re-add us. By the way, I checked it out and, in the absence of any ld.so.conf entries: nxagent nxdesktop nxproxy nxviewer do not work. Everything else works fine. So these are the only binaries that might benefit from a wrapper. - Daniel Holth *** Bug 81014 has been marked as a duplicate of this bug. *** *** Bug 70927 has been marked as a duplicate of this bug. *** Daniel, I've just added nx-x11-1.4.0-r4 into Portage. Do you want to give that a go, and see if upstream have addressed this? W/ Donnie's changes having been made, I'm happy to close this bug. Best regards, Stu I think this bug is fixed with the latest ebuilds. *** Bug 91157 has been marked as a duplicate of this bug. *** Closing bug, as there's been no reply to the request for testing. if this LDPATH is no longer needed, then we should punt it if nx still sucks, then the nx ebuilds should inherit this bloat ... punishing the rest of the world for nx's problems is the opposite of what should happen Hi, Give the new packages in the NX overlay a try. They should hopefully fix this problem. Best regards, Stu |