I reemerged nx-x11 and most of my X11 applications would not work, e.g. unable to login to X at all. Turns out the problem is that all my dynamically linked X apps began to look for NX libraries before X11 libraries. NX breaks == no X11 for you. Reproducible: Always Steps to Reproduce: 1. reemerge nx-x11 after using older version 2. notice X becomes completely unusable 3. whoops, it is because lots of X applications try to link dynamically to missing X11 libraries in /usr/NX/lib Actual Results: almost every X application was unusable Expected Results: I didn't expect NX's libraries to come ahead of standard libraries for every user. If /usr/lib came before /usr/NX/lib in /etc/ld.so.conf normal Xorg.x11 would not break. nxclient also still works when /usr/NX/lib is not present at all in ld.so.conf and ldconfig has been run. This is related to bug 36170 : http://bugs.gentoo.org/show_bug.cgi?id=36270 . There is obviously a missing dependency for nxcomp == x.y.z somewhere. Those missing libraries brought my GUI system down. Portage 2.0.51-r3 (gcc34-x86-2004.2, gcc-3.4.3, glibc-2.3.4.20040808-r1, 2.6.10-gentoo-r1 i686) ================================================================= System uname: 2.6.10-gentoo-r1 i686 AMD Athlon(TM) XP 1600+ Gentoo Base System version 1.5.3 distcc 2.13 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.90.0.1.1-r3 Headers: sys-kernel/linux26-headers-2.6.8.1-r1 Libtools: sys-devel/libtool-1.5.10-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/NX/etc /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache distlocks" GENTOO_MIRRORS="http://gentoo.osuosl.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/overlays/bmg-main /usr/local/overlays/deltup" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="X aalib alsa apache2 apm arts avi berkdb bitmap-fonts blender-game bluetooth bonobo c cairo caps cdr crypt cups dvd encode esd f77 flac foomaticdb fortran gcj gdbm gif gimp gimpprint gnome gphoto2 gpm gtk gtk2 gtkhtml guile imlib ipv6 jabber jack java javascript jikes joystick jpeg kde ldap libg++ libwww mad mikmod mmx mng motif mozilla mozsvg mpeg ncurses network nls nptl objc ofx oggvorbis opengl oss pam pda pdflib perl pic png postgres ppds python qt quicktime readline ruby sdl slang snmp speex spell sse ssl svg tcltk tcpd tetex theora threads tiff truetype usb v4l v4l2 x86 xinerama xml2 xmms xprint xv zlib zvbi"
*** 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
