libelf being a dependency of ntp makes no sense. Why would the network time protocol daemon need to manipulate ELF object files? I am aware of bug# 33126 and in my not so humble opinion, there was something strange on the reporters system. Here is my ldd output with libelf installed and w/o libelf. In both cases the output is the same. Emerged with libelf installed: /usr/bin/tickadj libreadline.so.4 => /lib/libreadline.so.4 (0x4002e000) libc.so.6 => /lib/libc.so.6 (0x40059000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) /usr/bin/ntptrace libreadline.so.4 => /lib/libreadline.so.4 (0x4002e000) libc.so.6 => /lib/libc.so.6 (0x40059000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) /usr/bin/ntptimeset libreadline.so.4 => /lib/libreadline.so.4 (0x4002e000) libc.so.6 => /lib/libc.so.6 (0x40059000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) /usr/bin/ntptime libreadline.so.4 => /lib/libreadline.so.4 (0x4002e000) libc.so.6 => /lib/libc.so.6 (0x40059000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) /usr/bin/ntpq libreadline.so.4 => /lib/libreadline.so.4 (0x4002e000) libc.so.6 => /lib/libc.so.6 (0x40059000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) /usr/bin/ntpdc libreadline.so.4 => /lib/libreadline.so.4 (0x4002e000) libc.so.6 => /lib/libc.so.6 (0x40059000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) /usr/bin/ntpdate libcap.so.1 => /lib/libcap.so.1 (0x4002e000) libreadline.so.4 => /lib/libreadline.so.4 (0x40031000) libc.so.6 => /lib/libc.so.6 (0x4005c000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) /usr/bin/ntpd libm.so.6 => /lib/libm.so.6 (0x4002e000) libcap.so.1 => /lib/libcap.so.1 (0x4004f000) libreadline.so.4 => /lib/libreadline.so.4 (0x40052000) libc.so.6 => /lib/libc.so.6 (0x4007d000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) /usr/bin/ntp-wait not a dynamic executable /usr/bin/ntp-genkeys libreadline.so.4 => /lib/libreadline.so.4 (0x4002e000) libc.so.6 => /lib/libc.so.6 (0x40059000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Emerged without libelf installed:/usr/bin/tickadj libreadline.so.4 => /lib/libreadline.so.4 (0x4002e000) libc.so.6 => /lib/libc.so.6 (0x40059000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) /usr/bin/ntptrace libreadline.so.4 => /lib/libreadline.so.4 (0x4002e000) libc.so.6 => /lib/libc.so.6 (0x40059000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) /usr/bin/ntptimeset libreadline.so.4 => /lib/libreadline.so.4 (0x4002e000) libc.so.6 => /lib/libc.so.6 (0x40059000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) /usr/bin/ntptime libreadline.so.4 => /lib/libreadline.so.4 (0x4002e000) libc.so.6 => /lib/libc.so.6 (0x40059000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) /usr/bin/ntpq libreadline.so.4 => /lib/libreadline.so.4 (0x4002e000) libc.so.6 => /lib/libc.so.6 (0x40059000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) /usr/bin/ntpdc libreadline.so.4 => /lib/libreadline.so.4 (0x4002e000) libc.so.6 => /lib/libc.so.6 (0x40059000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) /usr/bin/ntpdate libcap.so.1 => /lib/libcap.so.1 (0x4002e000) libreadline.so.4 => /lib/libreadline.so.4 (0x40031000) libc.so.6 => /lib/libc.so.6 (0x4005c000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) /usr/bin/ntpd libm.so.6 => /lib/libm.so.6 (0x4002e000) libcap.so.1 => /lib/libcap.so.1 (0x4004f000) libreadline.so.4 => /lib/libreadline.so.4 (0x40052000) libc.so.6 => /lib/libc.so.6 (0x4007d000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) /usr/bin/ntp-wait not a dynamic executable /usr/bin/ntp-genkeys libreadline.so.4 => /lib/libreadline.so.4 (0x4002e000) libc.so.6 => /lib/libc.so.6 (0x40059000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Reproducible: Always Steps to Reproduce: 1. emerge -v ntp 2. ldd executible files 3. emerge unmerge libelf 4. modify ebuild to remove libelf from RDEPEND 6. emerge -v ntp 7. ldd executible files Actual Results: libelf not referenced in executible files Expected Results: libelf should not be a dependency for ntp Portage 2.0.50-r1 (default-x86-1.4, gcc-3.3.2, glibc-2.3.2-r9, 2.4.22-gentoo-r5) ================================================================= System uname: 2.4.22-gentoo-r5 i686 Intel(R) Pentium(R) 4 CPU 1.80GHz Gentoo Base System version 1.4.3.13 Autoconf: sys-devel/autoconf-2.58 Automake: sys-devel/automake-1.7.7 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=pentium4 -O2 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=pentium4 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache fixpackages sandbox" GENTOO_MIRRORS="http://gentoo.mirrors.pair.com/ http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X aalib acpi alsa arts artswrappersuid avi berkdb cdr crypt cups directfb dvd encode fbcon foomaticdb gdbm gif gpm gtk gtk2 imlib java javascript jpeg kde libg++ libwww mad mbox mikmod mmx motif mozilla moznocompose moznoirc moznomail mpeg ncurses nls oggvorbis opengl pam pda pdflib perl png ppds python qt quicktime readline sasl sdl slang spell sse ssl svga tcltk tcpd tiff truetype usb x86 xml2 xmms xv zlib"
there was no 'strangness on the reports system' remove libelf from your system and then try to compile the package with out, you'll find it will fail
hrm, i told bugzilla to re-assign, not close
It doesn't fail with libelf removed. In fact it compiles and works very well without it.
moved into just DEPEND
It shouldn't need to be a dependency at all, which is why I'm questioning it. None of my systems have needed libelf or elfutils to compile and run NTP.
the real answer is that configure.in throws -lelf into the linking process without any control over it if you have libelf on your machine then ntpdate will link against it ... if you dont have it on your machine, ntpdate wont link against it i'll add a sed to the src_unpack() to remove -lelf so no one will link against it ever again
Before you make the change, I would like to investigate a little further. I have discovered that dev-libs/libelf isn't building shared libraries on my system, which is why it hasn't been included in my output. dev-libs/elfutils does build the shared libraries and I do see the library in the ldd output with it installed. (This is one of those things that has my curiousity going with wondering why my systems don't need it, yet others apparently do)
My last comments; As far as I can tell from the code, it is pulling in libelf to use the nlist function which it then doesn't use on Linux systems. So it definitely appears to be an unneeded dependency for any Linux system.
4.2.0 will now try to link against liba_doe_a_deer_a_female_deer.so instead of libelf.so if you have it on your system, you better not remove it, cause ntpdate will fail to work :P
Could you _please_ update the revision number when you make such a change? Ebuilds changed "on the fly" are really annoying if one updates from a binary mirror.
ive been adding a lot of on-the-fly fixes for 4.2.0 rather than version bumping every single one, i was letting them accumulate before releasing -r1 otherwise you'd probably be at about -r4 or -r5 by now :P
Consider the following scenario (just happened here): 1. Mirror host emerges the old ntp-4.2.0 with the libelf dependency. The resulting binary will only run if libelf.so is present. 2. New ntp-4.2.0 appears that no longer depends on libelf. 3. Mirror host does _not_ recompile the binary (there is no new revision). 4. Now client host is updating, fetching the (old) binary from the mirror. However, there is no longer any libelf dependency in the ebuild and libelf is not present (or will be removed) on the client host. 5. The resulting ntp binary on the client host will not run because it misses libelf.so.
read comment #11 again
