after an 'emerge hpoj' all hpoj applications are linked against libsnmp. tux ~ # xojpanel xojpanel: error while loading shared libraries: libsnmp.so.5: cannot open shared object file: No such file or directory tux ~ # ldd /usr/sbin/ptal-printd linux-gate.so.1 => (0xffffe000) libptal.so.0 => /usr/lib/libptal.so.0 (0x414a7000) libc.so.6 => /lib/tls/libc.so.6 (0xb7ea0000) libsnmp.so.5 => not found libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0xb7d9f000) /lib/ld-linux.so.2 (0xb7fea000) libdl.so.2 => /lib/libdl.so.2 (0xb7d9b000) But as ldd shows correctly: SNMP is not installed. SNMP is not in USE and looking through the logs, configure does correctly tell that it is not using SNMP. But the binaries end up linked against libsnmp.so.5 which does not exist during compile- or runtime. Now net-snmp was installed on that system some months ago but i got rid of it and i would really like to have hpoj work again without it. Reproducible: Always Steps to Reproduce: i guess this particular problem is system specific though hard to reproduce, but theoretically anyone uninstalling net-snmp (and killing snmp from USE) might run into it 1. install hpoj with USE=-snmp 2. see it linked against libsnmp.so.5 3. tux ~ # emerge info Portage 2.0.51-r12 (default-linux/x86/2004.2, gcc-3.4.3, glibc-2.3.4.20041102-r0, 2.6.10-gentoo-r4 i686) ================================================================= System uname: 2.6.10-gentoo-r4 i686 AMD Athlon(tm) XP 3000+ Gentoo Base System version 1.6.8 Python: dev-lang/python-2.3.4 [2.3.4 (#1, Dec 22 2004, 18:13:45)] ccache version 2.3 [enabled] dev-lang/python: 2.3.4 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.9.4, 1.8.5-r2, 1.6.3, 1.7.9 sys-devel/binutils: 2.15.92.0.2-r2 sys-devel/libtool: 1.5.10-r2 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -O3 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/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/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/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -O3 -pipe" DISTDIR="/usr/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks fixpackages sandbox sfperms" GENTOO_MIRRORS="http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo ftp://gd.tuwien.ac.at/opsys/linux/gentoo/ http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="3dnow 3dnowex X Xaw3d a52 aac aalib adns alsa apm arts audiofile avi berkdb bitmap-fonts cdparanoia cdr client crypt cups curl dmx dvd dvdr dvdreadencode f77 faad fam ffmpeg flac fluidsynth font-server foomaticdb freetype gdbm gif glut gphoto2 gpm gstreamer gtk gtk2 hal imagemagick imlib jack java jpeg jpeg2k kde ladcca libcaca libg++ libwww live lzo mad matroska mbox mikmod mmx mmx2 mng motif mozilla mozsvg mpeg mpeg2 ncurses network nls nptl offensive ogg oggvorbis openal opengl oss pam pdflib perl pic png portaudio ppds python qt quicktime readline real rtc samba scanner sdl server slang sndfilesoundtouch speex spell sse ssl stencil-buffer stream svg tcpd tga theora tiff truetype truetype-fonts type1-fonts usb userlocales v4l v4l2 vcd vorbis wmf x86 xine xinerama xml xml2 xmms xv xvid xvmc zlib linguas_de" Unset: LDFLAGS tux ~ #
Created attachment 48530 [details] Complete emerge log To me this log looks normal and i do not see any signs of it being linked to libsnmp.so.5 -- but the binaries end up linked to it every time...
Well - bug found. There was a stray libptal.so.0 on the system that the new binaries were linked to (which was linked against libsnmp). So the problem is not snmp related - but the binaries in the ebuild get linked to the libptal that is already installed - not against the libptal that is _going_ to be installed (which can lead to installing broken binaries on every upgrade/recompile).
fixed.
