| Summary: | Why is libelf a runtime dependency of ntp? | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Paul Varner (RETIRED) <fuzzyray> |
| Component: | New packages | Assignee: | SpanKY <vapier> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ulm |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Paul Varner (RETIRED)
2004-02-14 15:40:25 UTC
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 |