I certainly understand the frustration in that I experience it identically in other areas.
>From your other email, I read > I'm looking for libraries with _MISSING_ SONAME's. The solution there is > to add DT_SONAME > with -Wl,soname,YOUR_SONAME > > It's been decades, literally, since I handled C linking on a daily basis. So, assuming that we did locate such missing entries, is this something that would need to be done at compile/link time or are those switches that can be applied via a spec file/rpmbuild? Are there existing mechanism for re-building a compiled .so without access to the source? On Sun, Jan 6, 2013 at 2:48 PM, Jeffrey Johnson <[email protected]> wrote: > > On Jan 6, 2013, at 3:34 PM, Mykel Alvis wrote: > > > > > I think it's OK to do this, but I'm going to do so directly to your > personal email so that I don't display piles of potentially litigious data > in a public forum. > > > > Please reply with readelf output publically: the output is not that large > if you > grep out only the "SONAME" (i.e. the Provides:) and the "NEEDED" (i.e the > Requires:) for a couple of libraries and executables. > > There are also specific options to display exactly DT_SONAME/DT_NEEDED > if you wish to read "man readelf": I deliberately gave you the easier to > understand > readelf -a ... | grep SONAME > as something that an average RPM packager faced with a similar problem > using > Google search might find useful, comprehensible, and perhaps easier to > remember. YMMV. > > Most users with RPM problems now use Google search first, you included. > > This leads to a preponderance of problem (but not solution) reports. > > For something like RPM w >15y of serachable information, searching can and > will find > just about every answer you want to hear, with many answers that > implictly/contextually > appropriate and generally foolish. If one is smart enough, one can > sometimes find the "best" > solution. But generally, the deluge of possibile answers and "No time!" > precludes "best" > or even "thoughtful". > > Yes I respond to requests out of "good will", formerly out of some > misplaced sense of duty > and obligation to assist with information on software I wrote and happen > to know quite well. > > The specific parts of your problem that have only to do with RPM are the > metadata in > *.rpm package headers. The parts of this problem that I cannot help > directly with are > what the packages are used for, how the software is to be built, how to > setup yum repositories, > and why yum on RHEL (more likely CentOS) is reporting a dependency > failure. The > other issues are implicitly related to the (non-)existence of metadata, as > well as coupled > into the root causes for your specific issue, and cannot be ignored (or > solved by RPM). > > 73 de Jeff > ______________________________________________________________________ > RPM Package Manager http://rpm5.org > User Communication List [email protected] >
